migration checklist

Have the SEO team review the new site's Figma designs and wireframes before development starts. Check that every template has crawlable navigation, one clear H1, room for body copy and internal links, and that key content isn't hidden behind tabs or accordions. Fixing structure at the design stage costs far less than reworking built pages.

Run a full crawl of the staging site before launch and fix what it surfaces: broken links, redirect chains, missing or duplicate titles and meta descriptions, orphan pages, and stray noindex tags. This is the last point where issues are cheap to fix, so treat a clean crawl as a launch gate.

Map every old URL to its closest equivalent on the new site and implement server side 301 redirects; permanent redirects pass PageRank, so a complete map is one of the biggest levers for minimizing traffic loss. Redirect each page to a relevant target, not the homepage (Google can treat that as a soft 404), avoid chains longer than 3 hops, and keep the redirects live for at least a year so signals have time to transfer.

Carry over or rewrite a unique title tag and meta description for every page; don't let the new CMS regenerate them from page names. Keep titles around 60 characters with the page's main keyword near the front, and write descriptions of roughly 150 to 160 characters that summarize the page. Lost or duplicated meta tags are one of the most common causes of post-migration ranking dips.

Organize the new site into logical subfolders (for example /blog/, /services/, /products/) so each section can be crawled and measured cleanly. Wherever possible keep URLs identical to the old site: every URL that doesn't change is a redirect you don't need, which directly reduces migration risk.

Test every key template on PageSpeed Insights and pass the Core Web Vitals assessment before launch: LCP 2.5 seconds or less, INP 200 milliseconds or less, CLS 0.1 or less. Use the report's Diagnostics section, where Google names each problem and the suggested fix, and monitor real-user field data over time with the CrUX dashboard rather than relying on one-off lab tests.

Test with PageSpeed Insights Core Web Vitals overview on web.dev

Install GA4 on the new site and verify the property in Google Search Console before launch so you have baseline data from day one. After go-live, watch the Search Console performance and indexing reports closely; some fluctuation is normal in any migration, and early monitoring is how you keep the dip small and short.

The new site should meet the same on-page and technical standards as any site: meta tags, heading hierarchy, semantic HTML, structured data, and clean URLs. Work through the full SEO checklist alongside the migration-specific items on this page.

See our SEO best practices checklist

AI answer engines such as AI Overviews, ChatGPT, and Perplexity have their own readiness requirements: crawler access, content in the raw HTML response, and extraction-friendly formats. A rebuild is the natural moment to design these in, so run the AI SEO checklist against the new site before launch.

See our AI SEO checklist

Build the new templates to WCAG standards: sufficient color contrast, keyboard navigation, labeled form fields, and ARIA roles where native HTML isn't enough. Run the Lighthouse accessibility audit on each template and fix what it flags. Accessibility overlaps heavily with SEO (semantic markup, alt text) and is much easier to build in than to retrofit.

W3C accessibility tips for developing Lighthouse accessibility scoring

Make sure primary content and internal links are present in the raw HTML response, not injected by JavaScript after render. Search engines handle JavaScript inconsistently and most AI crawlers don't execute it at all, so anything that exists only in the rendered page may never be seen. Spot-check single pages by comparing raw and rendered HTML, and use a crawler's rendering report to audit the whole site.

Sitebulb on response vs render Case studies on server side rendering

Rebuild the trust layer on the new site: an about page, a contact page with a real phone number and work email, author pages with credentials, team and leadership pages, and legal pages (privacy, terms) in the footer. Google's quality rater guidelines treat trust as the most important part of E-E-A-T, and these are exactly the pages that get dropped from scope during a redesign.

Google's guidance on helpful, people-first content

Keep the staging or UAT site out of Google's index with a noindex robots meta tag (or password protection), and remove the tag the moment the site goes live. A leaked staging site creates duplicate content, and a forgotten noindex on production is one of the most damaging migration mistakes, so make its removal an explicit launch-day step someone owns.

Name new URLs with the page's main keyword in the slug, hyphens between words, and lowercase letters only, and keep slugs short by trimming titles to the core phrase (good: /seo-migration-checklist, bad: /post123 or /SEO-Migration-Checklist). Clean slugs are readable and shareable, and lowercase-only naming avoids the duplicate URL versions that mixed case creates.

As content moves into new templates, keep each page's target keyword in the copy: once in the H1, within the first 100 words, and in the first H2 where it fits naturally, never stuffed. Redesigns often cut pages down to thin marketing copy, so verify that the keyword-carrying text actually survives the move.

Semrush guide to SEO writing

Prepare the new site's robots.txt before launch: allow crawling of everything you want indexed, make sure a staging-era Disallow: / rule doesn't ship to production, and reference the XML sitemap location. Also confirm AI crawlers aren't blocked if AI visibility matters to the business.

Check AI crawler access

Keep the server's average response time to Googlebot under 200 milliseconds. Check it in Google Search Console under Settings, then Crawl Stats, and click Average response time to see the trend chart. Sustained values above 200ms waste crawl budget and point to server or hosting problems worth fixing before launch.

Scan the new site at securityheaders.com before launch to capture a baseline grade (the scanner rates from F to A+), implement the headers it flags as missing, then re-scan to confirm the improvement. Pair the header check with a crawler-based security audit, for example in Sitebulb, to catch mixed content and insecure resources across the whole site.

Security headers scanner

Ship a favicon that meets Google's guidelines: a square icon of at least 48 x 48 pixels, referenced from the homepage with a link rel="icon" tag, and crawlable (not blocked by robots.txt). Google shows it next to your result in search, so a missing favicon after relaunch is lost brand recognition.

Google's favicon guidelines

Serve images in modern formats (WebP with fallbacks, or AVIF for better compression), compress most images to under 100KB, declare width and height attributes to prevent layout shift, and lazy-load below-the-fold images with srcset for responsive delivery. Re-encoding the image library is one of the cheapest page speed wins a rebuild offers.

Google Images best practices

Qualify outbound links you don't want to endorse with rel="nofollow", using rel="sponsored" for paid placements and rel="ugc" for user-generated content. Templates rebuilt from scratch often drop these attributes, so audit external links on the new site rather than assuming they carried over.

Serve a branded, helpful 404 page that returns a true HTTP 404 status at the requested, unchanged URL. Don't redirect dead URLs to the homepage, and never serve a 200 OK with page-not-found content (a soft 404). During a migration especially, real 404s keep broken backlinks discoverable so they can be redirected to the right pages.

Google on soft 404 errors Google help: create custom 404 pages

Give every page exactly one H1 stating the page topic, H2s for main sections, and H3s nested under their parent H2, never skipping levels. Choose heading tags semantically and control their size with CSS instead of picking tags for how they look. Quick audit: read only the headings top to bottom; if they don't form a coherent outline, fix the levels.

If the blog moves to a new template, build in the trust and navigation elements: author bylines linked to author pages, published and last-updated dates, a table of contents, breadcrumbs, visible cited sources, and sharing buttons. Size hero images around 450px tall on desktop and 225px on mobile so the opening copy stays above the fold.

Blog design best practices NN/g on tables of contents

Carry over or create a press presence: a dedicated press page or an in-the-news block on the homepage that links to third-party coverage about the company, not just self-published releases. Journalists review this page when researching a company, per Nielsen Norman Group, and it's an easy trust signal to lose in a redesign.

NN/g on press and newsroom pages Example press page: Groww

Treat the footer as a categorized index of the site: list the key pages grouped under labeled category columns rather than leaving just a copyright line and social icons. A well-structured footer restores the internal links that page-level redesigns often strip out; footers on mature sites like G2 are useful layout models.

Audit that alt attributes survived the content move for all main images, and write alt text that accurately describes what's in the image, paired with descriptive filenames (blue-ceramic-coffee-mug.jpg, not an auto-generated string). Alt text is both an accessibility requirement and how images rank in Google Images, and CMS migrations frequently drop image metadata.

Google's guide to writing alt text

Add breadcrumb navigation to inner pages showing the path from the homepage (Home, then section, then page), and mark it up with BreadcrumbList structured data so the trail can appear in search results. Breadcrumbs restore orientation and internal linking on deep pages, which matters even more after a restructure.

NN/g on breadcrumbs

Run a full crawl of the production site immediately after go-live and compare it against the staging crawl. Verify redirects resolve in one hop, confirm no noindex tags or robots.txt blocks carried over from staging, and catch any broken internal links or missing meta tags before Google recrawls at scale.

Every page on the new site should carry a self-referencing canonical tag pointing to its own final URL, and no canonical should reference the old domain or old URL structure. Spot-check each template after go-live: a canonical still pointing at the old site tells Google to index the pages you just migrated away from.

Generate an XML sitemap of the new URLs and submit it in Search Console right after launch. Keep a sitemap of the old URLs submitted temporarily too: watching indexed counts fall on the old sitemap while they rise on the new one is the clearest way to track how far the migration has processed.

Monitor Search Console's page indexing report weekly after launch. Spikes in Not found (404), Redirect error, or Duplicate without user-selected canonical each point at a specific migration fix. Indexing will fluctuate for a few weeks; what you want is a steadily rising indexed count on the new URLs.

Build templates with semantic elements so search engines and AI parsers can read meaning from the markup itself: one main, header, and footer per page, the H1 inside a header within main, each H2 topic in its own section nested in an article, time for dates, figure and figcaption for images, and proper table markup. Keep pages under 900 DOM nodes with clean, uncluttered HTML.

Semantic HTML5 markup inspector HTML5 semantic elements reference

Reapply structured data on the new site; schema rarely survives a re-platform on its own. Match types to content (Organization and WebSite on the homepage, Article or BlogPosting on posts, FAQPage, Product, or Event where relevant) and validate with Google's Rich Results Test after launch so rich result eligibility carries over.

Add the full social tag set to every page: og:title, og:description, og:url set to the canonical URL, og:type, og:site_name, and an og:image at 1200 x 630 pixels, plus the matching twitter:card, twitter:title, twitter:description, and twitter:image tags, with twitter:card set to summary_large_image. Most values mirror the page's existing meta tags, so implementation is mostly copy-through; without them, social shares fall back to whatever the platform scrapes.

Ahrefs guide to Open Graph tags

Publish a human-readable HTML sitemap page that links to the site's important pages, grouped by section. It gives users and crawlers a fallback discovery path and means every key page keeps at least one internal link after the restructure.

After go-live, test every address variation of the domain (http vs https, www vs non-www) and confirm each one 301-redirects to the single preferred version in one hop. Variations that resolve separately split link signals across duplicate copies of the same site.

Route all form submissions to one dedicated thank-you URL by answering the form POST with a 303 See Other redirect instead of rendering confirmation content directly. Refreshing the page then never re-submits the form, and the single stable URL becomes a clean conversion goal in analytics.

MDN on the 303 status code