curl -sS -D - -o /dev/null "$OLD_URL"

Follow redirects and inspect response headers along the way

curl -sS -L -D - -o /dev/null "$OLD_URL"

Output the final status and final URL for recording results

curl -sS -L -o /dev/null
-w 'status=%{http_code} final=%{url_effective}\n' "$OLD_URL"

Acceptance records should capture the initial response, target URL, final response, and page content. The technical owner should confirm the rule type for permanent moves according to the actual deployment environment. A browser appearing to redirect successfully is not enough to reach a conclusion.

Treat unnecessary redirect chains, redirects back to old URLs, redirects to test domains, and missing destination pages as launch blockers. Take particular care not to check only homepage rules while overlooking article and product detail pages.

## 5. How Should Page Content and Canonical URLs Be Verified Together?

A URL opening successfully is only the minimum requirement. Select representative pages from every page template and check that the title, main heading, body content, image alt text, internal links, and inquiry buttons are complete, so that imports do not leave behind empty page shells.

Include canonical URLs in your checks of preferred addresses, but do not treat them as a substitute for resolving every migration problem. During acceptance, record the canonical URL declared by each page and confirm that it matches the production page specified in the project plan. Pay particular attention to declarations that still point to an old domain, a preview domain, or an unrelated page.

Multilingual websites require additional checks of the relationships between language versions. A Chinese-language product page should not link to the English homepage because of a bulk replacement. Test language switching, footer links, and recommended links within the body by actually clicking them.

Also compare core information before and after migration. Pricing conditions, service scope, supporting evidence for case studies, and contact information must not be inadvertently removed when templates are replaced. For pages that sales relies on, involve the business owner in acceptance rather than having developers check only technical responses.

## 6. What Should You Check in a Sitemap? Reconcile It with the Production Page List First

First compile a list of production pages intended to be public and discoverable through search, then compare it with the generated sitemap. Do not consider the check complete simply because an XML file has been generated.

Focus on the following:

- Do the URLs in the sitemap belong to the production domain and environment?
- Have the new paths after migration been included as planned?
- Does the sitemap contain URLs that have been deleted, still redirect, or are not yet ready to be public?
- Do the pages listed in the sitemap match their declared canonical URLs?
- Are entire groups missing, such as multilingual directories, paginated article listings, or product categories?
- Is responsibility for updating and republishing the sitemap clearly assigned?

When the number of sitemap entries changes, investigate why: was content deliberately consolidated, or were there import omissions or incorrect filtering conditions? Save copies of the files before and after migration for item-by-item comparison.

The sitemap is only one part of migration acceptance. After submission, you still need to check access to individual pages, their content, and subsequent status changes. Submission is not a basis for promising indexing, rankings, or traffic outcomes.

## 7. What Should You Check in Search Console Before and After Launch?

![7. What Should You Check in Search Console Before and After Launch?](https://we0-frontend.oss-cn-beijing.aliyuncs.com/growth-covers/3ae5ab5b-404e-4812-9473-4305e47b4bb6.png)

Before launch, confirm that the team can access the relevant site properties and that responsible staff will not lose their permissions when the old vendor exits. Record important landing pages, queries, clicks, and impressions before migration, along with the observation dates, to establish a baseline for later comparison.

After launch, check and record the following in order:

1. **Properties and permissions**: Are you viewing the site involved in this migration, and do the responsible people still have access?
2. **Representative URLs**: Check crawling, indexing status, and canonical URL information for key pages, distinguishing historical records from subsequent changes.
3. **Sitemaps**: Verify what was submitted, its processing status, and related notices. If something is wrong, return to the actual file to investigate.
4. **Page issues**: Organize issues by directory and template rather than focusing only on totals.
5. **Performance**: Compare queries, clicks, and impressions across old pages and their corresponding new pages, not just the homepage.

If the domain is also changing, separately confirm whether change-of-address procedures apply to your migration. Do not confuse switching website builders on the same domain with migrating across domains.

When you find a problem, put the page URL, the message displayed, the observation time, and retest results into the same issue ticket. Do not delete pages or repeatedly modify rules based on a single screenshot.

## 8. How Should Launch-Day Acceptance and Rollback Be Organized?

Divide launch into preparation, cutover, retesting, and monitoring stages. During preparation, freeze important content changes, back up page data and configuration, and confirm that necessary access to the old site can be retained.

After cutover, test key business workflows first: entering through an old URL, reading product information, submitting a form, receiving notifications, and following up through sales. Run SEO checks and lead-generation checks together to avoid a situation in which pages are accessible but no one receives inquiries.

Agree on launch-blocking conditions in advance, such as inaccessible key product pages, large numbers of old entry points lacking their planned destinations, production pages still subject to test-environment restrictions, or a broken inquiry workflow. If these occur, the owner should decide whether to fix the issue or roll back, rather than debating standards during launch.

Rollback also needs operating instructions: who can execute it, which configurations must be restored, and how successful restoration will be confirmed. Do not discover on migration day that the old site has already been deleted or that access to the original vendor's account has expired.

## 9. How Can You Troubleshoot Post-Migration Performance Changes Without Losing Track?

Investigate reproducible technical and content issues before discussing broader search performance. A useful sequence is to check whether pages are accessible, old entry points lead to the correct destinations, content is complete, internal links have been updated, and the sitemap matches page declarations.

When comparing data, examine the old and new URLs for the same business page together. Looking only at the new URL's history can obscure pre-migration data, while looking only at sitewide totals can hide losses in an important directory.

Also record concurrent changes to advertising, content edits or deletions, seasonal campaigns, and analytics configuration so that not every change is attributed to switching platforms. Fix one clearly defined group of issues at a time and record retest results to reduce the risk of losing track of causes when multiple changes overlap.

There is no universal recovery timeline that applies to every website. Migration acceptance can include an internal review schedule, but that schedule should not be presented as a promise about search engine processing.

## 10. How Should You Ask About Migration Capabilities When Choosing an AI Website Builder?

Generating pages and carrying over an existing site are two different acceptance tasks. The [we0 official website](https://we0.ai/zh) describes workflows for expressing requirements in natural language, building with multiple agents, making visual adjustments, and deploying to a domain. Businesses can use this information to evaluate the building approach, but should still separately request demonstrations of old-path preservation, redirect configuration, and post-migration testing methods. They should not assume these tasks will happen automatically.

As a reference for another type of product, the [Readdy official website](https://readdy.ai/zh) describes code export, domain hosting, and SEO- and GEO-related tools. During procurement, ask further questions: Who maintains deployment configuration after export? Who manages path rules? Who investigates issues? Feature names cannot replace a written statement of project responsibilities.

An [Alibaba Cloud Developer Community article introducing Wan Xiaozhi](https://developer.aliyun.com/article/1773673) discusses conversational website building and deployment workflows, but the page notes that the content is user-contributed. It can help teams understand website-building scenarios, but should not be treated as a vendor commitment to the migration deliverables for this project.

Ask candidate platforms or implementation providers to demonstrate their approach using a small set of real old pages before deciding on procurement and launch plans. The demonstration should cover different templates and exception scenarios, not merely generate a new homepage.

## FAQ

### Do I still need a migration checklist if I am changing website builders but keeping the same domain?

Yes. Check that paths, body content, page declarations, internal links, and inquiry workflows remain consistent. An unchanged domain does not mean every deployment outcome will automatically match the original plan.

### Can I redirect all old pages to the homepage?

This is not recommended as the default approach. First determine whether each old page has a relevant new page to receive its visitors. If no replacement content exists, explicitly document how the page will be handled rather than using the homepage to conceal missing content.

### Is the migration complete once the sitemap has been submitted?

No. You should also test old entry points, check key pages, verify business workflows, and continue recording status changes in Search Console. Submission cannot replace actual access testing.

## Related Tools

- **URL mapping table**: Manage old paths, new paths, treatments, and owners.
- **curl**: Inspect response headers, redirect sequences, and final URLs.
- **Google Search Console**: Organize records of site status and search performance checks.
- **Browser developer tools**: Retest page loading, links, and form requests.

## Related Links

- [we0: Website building, page adjustment, and deployment workflows](https://we0.ai/zh)
- [Readdy: Introduction to website building, code export, and operational tools](https://readdy.ai/zh)
- [Alibaba Cloud Developer Community: Introduction to Wan Xiaozhi AI website-building scenarios](https://developer.aliyun.com/article/1773673)

## Summary

When switching website builders, acceptance should cover not only the new website but the complete path from old entry points to new content and then to an inquiry. Start by creating a URL mapping table, then test redirects, page content, sitemaps, and business workflows, and finally use Search Console for ongoing investigation. Confirm platform capabilities through demonstrations with real pages, and document migration responsibilities and rollback conditions before launch.