A before, launch-day and post-launch SEO checklist covering URL inventory, redirect mapping, content preservation, canonicals, sitemaps and monitoring.
Record the current site before changing it
Export every known URL from the existing sitemap, analytics, Search Console, backlink tools and a site crawl. For each URL, record its status code, canonical, title, primary heading, organic landing-page activity and meaningful inbound links. This becomes the migration inventory and the evidence used after launch.
Do not judge a page only by its appearance. An old page may look weak while still earning links or matching an important query. Decide whether to preserve, improve, merge or retire it using evidence rather than redesign preference.
Decide which URLs genuinely need to change
Keeping a successful URL is usually safer than changing it for style. If the information architecture requires a new path, map the old URL to the closest equivalent new page. Avoid sending many unrelated pages to the homepage; that removes context for users and search engines.
Maintain a one-to-one redirect sheet with old URL, new URL, reason, owner and test status. The sheet should also mark pages that will intentionally return 404 or 410 because no useful replacement exists.
Preserve the content that explains each page
A redesign often shortens copy to make layouts cleaner. Before removing headings, examples, FAQs or supporting detail, identify which information makes the page useful and which search intent it serves. Improve weak writing, but do not replace specific information with slogans.
Ensure the primary content, navigation and internal links are present in rendered HTML. Important information should not depend on an interaction that a crawler or user may never trigger.
Test the staging site as a search system
Keep staging blocked from public indexing, then crawl it as if it were production. Check status codes, titles, descriptions, headings, canonicals, robots directives, image alternatives, pagination, structured data and internal links. Compare the result with the migration inventory.
Test templates as groups, not only the homepage. A single metadata or canonical bug in a dynamic template can affect every service, article or product URL generated from it.
Use a launch-day test set
Prepare a short set of URLs that represents every outcome: unchanged pages, redirected pages, removed pages, dynamic routes, canonical hosts, HTTP-to-HTTPS requests, robots.txt and sitemap.xml. Check this set immediately after DNS or deployment changes.
Every permanent redirect should reach the final 200 page without a loop or unnecessary chain. Canonicals, navigation links and sitemap entries should point directly to that same final URL.
Submit clean discovery signals
Publish a sitemap containing only canonical, indexable URLs that return 200. Reference it from robots.txt and submit it in the Search Console property that matches the canonical hostname. Inspect representative URLs from each template rather than requesting every page individually.
If the domain or protocol changed, keep the old redirects active long enough for users, links and search systems to reach the new destinations reliably.
Monitor outcomes, not only crawl errors
After launch, compare indexed pages, impressions, clicks, landing pages and server logs with the pre-launch baseline. Investigate unexpected 404s, redirect errors, canonical changes and important pages that remain discovered or crawled but not indexed.
Some volatility is normal, so record the launch date and annotate major fixes. The goal is not to promise unchanged rankings. It is to preserve valuable signals, detect mistakes quickly and give improved pages a technically sound path to be evaluated.
[ Put the thinking to work ]
