Website migration SEO keeps your rankings and traffic when you move to a new platform, domain, or URL structure. This is the checklist our team runs on every migration, refined over 50+ projects, so your new site is built to rank and to be cited by AI.
Not by itself. Rankings drop when a migration breaks something Google relies on, and it’s almost always something nobody checked. A page that ranked for five years quietly turns into a 404, and Google forgets it ever existed.
Expect some movement for about a month while Google recrawls your site and processes the redirects. After that, rankings should start to recover. On large websites, or when the domain, sitemap, or structure changes a lot, it can take up to three months. If rankings keep falling after the first month instead of recovering, one of the causes on this list is usually behind it.
Missing redirects. Old URLs return 404, or redirects chain through several hops before they land.
Lost metadata. Titles, descriptions, canonicals, and hreflang stay behind in the old CMS.
Content that needs JavaScript. Text and links appear only after scripts run, so crawlers see less than your visitors do.
Pages too big to index. Google stops reading at 2 MB of HTML, and the structured data at the end of the page goes missing.
Slower templates. The new pages load slower on mobile than the old ones, and Core Web Vitals slip.
Staging blocks on production. A noindex tag or Disallow: / from staging tells Google to stay away from your live site.
You can’t protect what you never measured. Before anyone touches the new site, take a full snapshot of the old one. It’s the spreadsheet you’ll come back to on launch day and for three months after.
Keeping the same domain? Then after launch you track the very same pages and metrics, so every change shows up side by side.
Crawl the old site. Every URL, including PDFs, old campaign pages, and orphan pages nothing links to anymore.
Record Google Search Console data. Clicks, impressions, average positions, and the queries behind each page.
Record Google Analytics data. Traffic and conversions per page, so you know which pages bring leads and need protecting first.
Pull backlinks per page in a tool like Ahrefs. A page other websites link to carries authority. It gets a redirect, however old it is.
Record performance in PageSpeed Insights for your main templates, on mobile and desktop, before anyone changes a line of code.
Decide what happens to every URL: keep, merge, or retire.
| If the URL has | Then |
|---|---|
| Traffic, rankings, or backlinks | Keep it, or 301 it to its new equivalent |
| Thin or duplicate content, but some links | Merge it into the closest relevant page, with a 301 |
| No traffic, no links, no business reason to stay | Retire it and return 410 |
Never redirect everything to the homepage. Google treats it like a missing page, and your visitors land somewhere they didn’t ask for.
You can. Every changed URL just adds a row to the redirect map. Keep the URLs that already work and change only the ones that need it. An unchanged URL is the cheapest SEO protection there is.
Moving to a new domain too? Add a Change of Address in Google Search Console on launch day, so Google moves your signals faster.
A redirect map lists every old URL next to its new home. It’s the single document that decides whether your rankings move with you. We build it from the inventory, test it on staging, and keep it until the old URLs stop getting traffic.
Start from the inventory. One row per old URL, with its clicks and backlinks next to it.
Match one to one. Point each URL to the most relevant new page, not the nearest category page.
Pick the status code from the table below.
Flatten the chains. Every old URL points straight to its final URL, in one hop.
Match the canonicals. The redirect target is the same URL the page’s canonical tag names.
Pick one domain variant. www or not, and HTTPS only. Every other variant redirects to it.
Test on staging, then move the same set to production. Crawl the full list of old URLs against staging, whether the redirects live in the code or come from the old CMS. Fix every miss before launch, and move every tested redirect to production unchanged.
Keep it live. After a domain or URL structure change, keep redirects for at least a year. Redirects that live in the code or the CMS can stay longer, and pages with backlinks benefit when they do.
| Code | When to use it |
|---|---|
| 301 Moved Permanently | The classic permanent redirect. The page moved for good, and its SEO value moves with it. |
| 308 Permanent Redirect | What we use. Next.js returns 308 for permanent redirects, and Google treats it exactly like a 301. |
| 302 / 307 Temporary | Temporary. Next.js returns 307 for temporary redirects. Use it only when the old URL comes back later, never for a migration. |
| 404 Not Found | The page doesn’t exist. It returns a real 404, not a 200 that only looks like an error page. |
| 410 Gone | You removed the page on purpose and want Google to drop it from the index. |
Our QA team checks all 28 items before every launch. Most of them take minutes. Any one of them, missed, can cost you months of traffic. The website migration checklist covers everything around SEO: content, integrations, and the launch itself.
It’s the most expensive mistake in a migration, and one of the most common. Staging is supposed to hide from Google. On launch day, every one of those blocks has to flip. Miss one, and your brand-new website tells search engines to stay away.
robots.txt stops crawlers from visiting a page. noindex keeps a page out of results, but only if Google can visit the page and read the tag. Block a page in robots.txt, and Google may never see its noindex.
Check the infrastructure, too. A firewall or bot protection, on Cloudflare for example, can block Googlebot or AI crawlers even when robots.txt lets them in.
Yes. Googlebot processes only the first 2 MB of uncompressed HTML on each page and ignores the rest, without an error. The page still returns 200 OK and can even show as indexed. You just lose whatever sits below the cutoff.
That’s usually structured data, because JSON-LD often lands right before </body>. Large inline scripts and styles, Base64 images, and product data embedded in the HTML push pages over the limit. External JavaScript and CSS files each get their own 2 MB.
Browser DevTools. In the Network tab, find the page’s HTML document and read its uncompressed size, not the transfer size.
Site-wide crawl. Sort every page by HTML size in a crawler like Screaming Frog. Review anything over 1 MB.
Google’s own copy. In Search Console, open URL Inspection › View crawled page and look for the closing </body> tag. If the code ends mid-word, Google cut it off. Don’t rely on the live test.
Everything right of the line is ignored. The page still returns 200 OK.
Google reads everything that matters, well before the limit.
Yes, as long as the content is in the HTML your server sends. Google renders JavaScript, but later and not always in full. Many AI crawlers don’t run it at all. So we test every template the simple way: with JavaScript turned off.
A headless CMS gives you full control over how pages render. With Strapi or Payload behind a Next.js frontend, your content comes from the server, ready for any crawler.
Render on the server. Key content comes from server-side rendering or static generation, not from a fetch in the browser.
Keep hidden content in the HTML. Text in tabs and accordions stays in the page, just visually collapsed.
Link with links. Navigation uses <a href>. A <button> with a click handler is a dead end for a crawler.
Redirect on the server. Use 301 or 308, never JavaScript or meta refresh redirects.
Don’t hide your best text. Keep nosnippet and max-snippet:0 off content you want quoted.
Core Web Vitals (CWV) are Google’s measures of how fast and stable your pages feel. A migration is your best chance to improve them, and your easiest way to make them worse. The only way to know which one happened is to measure the same pages, the same way, before and after.
Always check mobile. Desktop often passes while mobile fails, usually on responsiveness, slowed down by third-party scripts, tag managers, and chat widgets.
Measure before. Record your main templates, and your competitors’ matching pages, in PageSpeed Insights and Lighthouse before the build starts.
Measure after. Repeat the same tests on the same pages after launch, on mobile and desktop.
Compare. Look for real regressions in loading, responsiveness, and visual stability, not small score swings.
Confirm by hand. Check what you found in a real browser, with and without cache.
| Metric | Measures | Good |
|---|---|---|
| Largest Contentful Paint (LCP) | How fast the main content loads | 2.5 s or less |
| Interaction to Next Paint (INP) | How fast the page reacts to a tap or click | 200 ms or less |
| Cumulative Layout Shift (CLS) | How much the layout jumps while loading | 0.1 or less |
| Time to First Byte (TTFB) | How fast the server answers | 0.8 s or less |
Lab tests like Lighthouse run in a controlled setup. Field data comes from real visitors on real devices. Smaller websites often don’t have enough traffic for field data, so we add lab tests and real-user monitoring.
Passing Google’s thresholds is the floor, not the goal. For every query, you compete with specific pages, in Google’s results and in the sources AI tools pick their answers from. When the content is equally good, the faster page has the edge.
So we measure your competitors the same way we measure you:
Generative Engine Optimization (GEO) gets your content quoted in AI answers. Most of it is SEO: AI tools lean on search indexes, and pages that don’t rank rarely get cited. A migration is the right moment for the few extra steps, because you’re rebuilding the templates anyway.
Allow AI search and user-fetch bots, like OAI-SearchBot, ChatGPT-User, Claude-SearchBot, and PerplexityBot. Training bots, like GPTBot or Google-Extended, are your call. Then check that your firewall agrees.
Each key page opens with a clear two- or three-sentence answer. AI tools read the top of a page first, so a summary component in the CMS makes this a habit, not a rewrite.
Real headings, lists, and tables in the HTML. A headless CMS stores content in clean fields, so FAQs and comparison tables become reusable components, not page-builder blocks.
Organization with description, contact point, address, and profiles. Plus WebSite, BreadcrumbList, Article, FAQPage, and Person, all generated from Strapi or Payload content.
Your company, products, and people named the same way everywhere. A visible author and update date on every guide, and lastmod in your sitemap.
AI agents read pages to act on them. Serve a Markdown version when they ask for it, keep forms and buttons accessible, and add llms.txt as a cheap extra.
Launch day isn’t the finish line for SEO. The first 72 hours catch technical breaks. The next three months show whether Google moved your rankings to the new URLs. Content freeze, cutover, and the failback plan live in the website migration checklist. If traffic or indexing falls below your baseline in the first days, its switch-back-after-review plan kicks in.
The first 30 days are part of the migration project, long enough for Google to collect 28 days of Core Web Vitals field data. From day 60, monitoring continues as part of support or maintenance. Your project manager goes through the report with you at your regular weekly or monthly meeting, or sends it. Any unplanned drop gets escalated right away.
Both are Google Sheets. Make a copy, fill it in, and share it with your team. You don’t need to sign up.
All 28 checks in six blocks, with columns for owner, status, and notes.
An inventory tab for your old URLs and a redirect map with status codes, clicks, backlinks, and test results.
Every check on this page is here because a real project needed it. When a project teaches us something new, the checklist changes. Here’s what some of those projects got out of the move.
Not by itself. Rankings drop when something Google relies on breaks: missing redirects, a staging noindex left on production, lost metadata, or content that only appears after JavaScript runs. Check those before launch, and a migration can leave you faster and better ranked than before.
Usually about a month. Rankings move while Google recrawls your site and processes the redirects, then start to recover. On large websites, or when the domain, sitemap, or structure changes a lot, it can take up to three months. If rankings keep falling after the first month, look for a technical cause instead of waiting.
Crawl the old site and list every URL with its traffic and backlinks. Match each one to its most relevant new page, pick the status code, and remove chains. Then crawl the old URLs against staging and fix every miss before launch.
Use a permanent redirect for pages that moved for good: 301 or 308. Next.js returns 308 for permanent redirects, which is what we use, and Google treats it exactly like a 301. Save 302 and 307 for temporary moves. Return 410 for pages you removed on purpose.
Yes. Every changed URL adds a row to the redirect map. Keep the URLs that already work and change only the ones that need it.
Yes, if the content is in the HTML the server sends. Google renders JavaScript later and not always fully, and many AI crawlers don't run it at all. Render key content on the server and test every template with JavaScript turned off.
Keep your rankings first, because AI tools lean on search indexes. Then let AI search bots in, open each key page with a clear answer, structure content with real headings and tables, and generate complete schema from your CMS.
It's website migration SEO focused on what changes when you switch platforms: templates, URL patterns, metadata fields, and how pages render. When you move to a headless CMS, it also means setting up metadata and schema as content your editors can manage.
We’ll find out what your team needs, together. Book on Calendly.
Send us a message or schedule a call.
Discuss your needs in a 25 min free call.
Get a quote from us within 3 days.
You can also e-mail us at sales@notum.cz or book a meeting directly in our calendar.
