A website migration, or relaunch, is the new edition of an existing website, often with a new design, a new structure or a new system. Visibility in Google Search is most likely to be preserved if every previous address (URL) redirects permanently to the matching new page. On top of that come a test before the switch and a few weeks of monitoring in Search Console, Google’s free tool for website owners¹.

Nobody can guarantee rankings, not even after a clean migration. What can be influenced is that Google finds the new pages quickly and assigns them correctly.

The checklist at a glance

1. Collect all previous URLs: sitemap, content management system, Search Console.
2. Export the Search Console Performance report by page, as a baseline.
3. Define a new target that matches the content for every old URL.
4. Set up redirects as permanent and server-side (301 or 308), without chains.
5. Respond to pages without a successor with 404 or 410.
6. Protect the staging environment with a password and check redirects, titles and descriptions there.
7. Point internal links directly to the new URLs.
8. At go-live, remove the password protection, noindex and blocks from the staging environment.
9. Submit the old and the new sitemap in Search Console.
10. Check robots.txt, firewall and CDN: do not block Googlebot, OAI-SearchBot and PerplexityBot.
11. Update the company’s own links: Business Profile, LinkedIn, directories, signatures.
12. For a few weeks, compare indexing, performance and enquiries with the previous state.

The sections below explain each step with a source.

What puts visibility at risk during a website migration?

Above all, changed URLs without a matching redirect. Add to that a block from the staging environment that stays active after go-live, and content or page titles that get lost in the move.

Google treats a relaunch with changed addresses as a site move. This includes new URL paths, the switch from http to https and a new domain¹. Which steps are needed depends on the type of change:

Type of change	What is additionally needed
New design, all URLs stay the same	no redirects; check titles, content, internal links and indexability
New URL paths on the same domain	redirect every old URL to the matching new one1
Switch from http to https	redirects; the Change of Address tool is not intended for this2
New domain	redirects plus the Change of Address tool in Search Console2
Only new hosting, addresses stay	separate Google guide for moves without URL changes1

A lot can change even without new addresses. New templates bring new titles, headings and texts. In a pure redesign, the titles, headings and texts of the most important pages therefore belong on the checklist.

Before the migration: securing the inventory

Before any change, a complete list of the previous URLs and the Search Console performance data is needed. Without this list, there is no way to check later whether every important page has a new target.

As sources for old URLs, Google’s documentation names, among others, the sitemap, server logs, the CMS (the website’s content management system) and Search Console¹. The Search Console Performance report shows clicks and impressions per page and can be exported³.

Checklist inventory:

• Merge a list of all URLs from sitemap, CMS and Search Console, including PDFs and images that appear in search.
• Export the Performance report by page and store it as a baseline³. the Compagne recommends a period of at least three months.
• Mark the pages with the most clicks and all service pages, and check them first during the move.
• Record the title, meta description, main heading (H1) and status code for every page.
• Count the enquiries of recent months so that a comparison is possible after the migration.

How differently such basics are implemented is shown by a sample taken by the Compagne of 25 websites of B2B service providers in the Ingolstadt region, Germany (8 October 2026). In each case the homepage was checked:

• XML sitemap present: 20 of 25
• http redirects to https: 22 of 25
• meta description present: 15 of 25
• title with 30 to 60 characters: 9 of 25
• exactly one H1: 10 of 25

These points are a checking grid used by the Compagne. Google prescribes neither a title length nor exactly one H1⁴. The sample is small and not representative; the list of companies comes from OpenStreetMap (© OpenStreetMap contributors, ODbL).

Which pages of a website carry the most work is described in the article B2B SEO.

Planning redirects

Every old URL gets a matching new target. For this, Google recommends permanent, server-side redirects with the status code 301 or 308^1, 5.

Permanent redirects count as a strong signal that the new page should appear in search results. Temporary redirects (302, 307) are only a weak signal⁶.

Checklist redirects:

• Create a table: old URL, new URL, status code.
• Redirect every old page to the new page that matches its content. Avoid blanket redirects of many old URLs to the homepage¹.
• Avoid chains: go directly to the final target, ideally with no more than three redirects in a row¹.
• Respond to pages that no longer exist and have no successor with 404 or 410. Google treats both the same and removes the URL from the index^1, 6.
• Keep redirects in place for at least one year, from the users’ point of view ideally permanently¹.

An example from the Compagne’s own restructuring in October 2026: the previous service pages were merged into a single practice page. Because their content lives on there, the new page is the target that matches the content. The English pages moved in the same way.

Old URL	New URL	Status
/leistungen/gestaltung/	/atelier/	301
/leistungen/sichtbarkeit/	/atelier/	301
/en/services/…	/en/practice/	301
http://www.thecompagne.com/…	https://thecompagne.com/…	301, in a single step

The last row shows a small detail with an effect: www and http are redirected to the main address in a single step, not first to https and then to the domain without www. This way no chain is created.

Testing before go-live

Until the switch, the new website runs in a staging environment. There, redirects, titles, descriptions and indexability can be checked before Google gets to see the pages.

A noindex rule only works if Google is allowed to fetch the page. If the staging environment’s robots.txt also blocks the page, Google does not see the rule, and the page can still appear in search⁷. Password protection, on the other hand, locks out everyone without a password, search engines included.

Checklist testing:

• Protect the staging environment with a password.
• Check the redirect table in full, with a script or crawler when there are many URLs. Every old URL must lead via 301 or 308 to a target with status 200.
• Every page has its own descriptive title. There is no fixed length, but Google truncates titles that are too long⁴.
• Every important page has its own meta description. Google only sometimes uses it for the snippet, the text below the title in the search result, and mostly builds the snippet from the page content⁸.
• The page’s main title stands out clearly, for example as the first H1⁴.
• Every new page points to itself via rel="canonical"¹.
• Internal links point directly to the new URLs, without detours via redirects¹.
• Test contact forms and phone numbers, on smartphones too.

On the day of go-live

On the day of the switch, the new website goes online without blocks, and the redirects become active. Then come the sitemaps and an individual check of the most important pages.

A sitemap helps Google find URLs, but guarantees neither crawling nor indexing¹⁰. For a site move, Google recommends submitting the old and the new sitemap¹.

Checklist go-live:

• Remove password protection, noindex and blocks in the staging environment’s robots.txt.
• Activate the redirects and open a sample of the most important old URLs in the browser.
• Submit the new and the old sitemap in Search Console. The Sitemaps report then shows how the old URLs disappear and the new ones are indexed¹.
• Test the most important pages with the URL Inspection tool. The live test shows whether Google can fetch the page and, in principle, index it. Indexing can be requested, subject to a daily limit and without a guarantee¹¹.
• Only for a new domain: use the Change of Address tool once the redirects are active².
• Prepare the server for more load. Google temporarily crawls a moved website more heavily¹.
• Update links to old addresses that the company maintains itself: the website link in the Google Business Profile, the LinkedIn page, entries in industry directories and the email signatures.

In the weeks afterwards

For medium-sized websites, it takes a few weeks or longer for the new URLs to appear in place of the old ones. Ranking fluctuations are normal during this period¹.

Checklist follow-up:

• In the Page indexing report, assess the reasons for pages not being indexed. “Page with redirect” is to be expected after a move; unexpected 404 errors or noindex are not¹².
• In the Sitemaps report, track how many URLs of the new sitemap are indexed¹.
• Compare the Performance report by page with the earlier export³.
• Check reported 404 errors and add missing redirects.
• Keep counting enquiries. the Compagne advises briefly asking with every enquiry how the contact came about.

What matters is that the right version of every relevant page is in the index. For fewer than 500 pages, a Google search with site: and the site’s own domain is often enough for this check¹².

What does a technical migration check examine?

A crawler fetches the pages of a website, follows the internal links and lists technical errors. the Compagne uses its own crawler for this. Two reports, before and after go-live, can be placed side by side.

For a website migration, these checkpoints count most:

• the status codes of every page and broken links, each with the page that links to them
• redirects and redirect chains on the way to the page
• noindex on pages where it is probably not intended
• missing or duplicate titles and meta descriptions
• the number of H1 headings per page
• robots.txt and XML sitemap
• the redirect from http to https

The limits: the crawler cannot log in and therefore does not check a password-protected staging environment. In its default setting it fetches at most 50 pages, and it only finds pages that are linked internally. Whether every old URL points to the right new target is settled by comparing against the redirect table.

What does a website migration change for AI answers?

There are no additional requirements for AI Overviews and AI Mode in Google Search. A page must be indexed and eligible to appear with a snippet. Googlebot must be allowed to fetch it, and this should also be permitted in the CDN and hosting settings¹³.

For ChatGPT, the crawler responsible is OAI-SearchBot. According to OpenAI, websites that block it in robots.txt do not appear in ChatGPT’s search answers. GPTBot, by contrast, collects content for training AI models¹⁴. At Perplexity, PerplexityBot is responsible for showing and linking websites in search results; according to Perplexity it is not used for training AI models⁹.

In the Compagne’s sample, 24 of 25 websites had a robots.txt. None of the 25 websites blocked OAI-SearchBot. GPTBot, PerplexityBot, ClaudeBot and CCBot were each blocked by one website. This check does not capture blocks via firewall or CDN. After the migration, the new robots.txt and the hosting and CDN settings therefore belong on the checklist.

the Compagne sees visibility in AI answers largely as the result of good SEO with clear, evidenced content. How texts end up in AI answers is described in the article GEO optimisation.

When does SEO belong in migration planning?

SEO belongs in the planning as soon as pages, menu and URLs are being defined. Later changes to them cost time, because redirects and internal links have to be updated.

The inventory and the redirect table are therefore created in parallel with the concept. New service pages are based on the terms customers search with. The templates for titles and headings go through the review before the design is signed off.

What does the effort of a website migration depend on?

Less on the size of the company than on five questions. In the Compagne’s assessment, they determine the scope of a migration most strongly:

• How many URLs are there? Every address with search traffic needs a verified target.
• What changes? A new design with the same addresses is smaller than new paths or a new domain (see the table above).
• Is new content being created? New service pages need research, copy and coordination.
• How many languages? Every language doubles the checks and redirects.
• Which integrations? Forms, shop, booking or interfaces must keep working after the move.

the Compagne only gives prices after a conversation, because these points vary greatly from website to website.

the Compagne combines Design and Visibility in one practice, so that SEO is part of the planning from the start. Where a website stands before its migration is shown by the visibility audit: it checks technology, content, Google Business Profile and AI answers, and ranks the measures by urgency and effort. Agencies that carry out a migration for their own clients and need reinforcement will find the process under For agencies. The starting point is an initial conversation.

Updated on 21 October 2026: added a short version of the checklist, an example redirect table, the Perplexity crawler, a section on effort and two questions on status codes.

Sources

1. Google Search Central: Site moves with URL changes: https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes (accessed 2026-10-08)
2. Search Console Help: Change of Address tool: https://support.google.com/webmasters/answer/9370220?hl=en (accessed 2026-10-08)
3. Search Console Help: Performance report (Search results): https://support.google.com/webmasters/answer/7576553?hl=en (accessed 2026-10-08)
4. Google Search Central: Influencing your title links in search results: https://developers.google.com/search/docs/appearance/title-link (accessed 2026-10-08)
5. Google Search Central: Redirects and Google Search: https://developers.google.com/search/docs/crawling-indexing/301-redirects (accessed 2026-10-08)
6. Google Search Central: How HTTP status codes, and network and DNS errors affect Google Search: https://developers.google.com/search/docs/crawling-indexing/http-network-errors (accessed 2026-10-08)
7. Google Search Central: Block Search indexing with noindex: https://developers.google.com/search/docs/crawling-indexing/block-indexing (accessed 2026-10-08)
8. Google Search Central: Control your snippets in search results: https://developers.google.com/search/docs/appearance/snippet (accessed 2026-10-08)
9. Perplexity: Perplexity Crawlers: https://docs.perplexity.ai/docs/resources/perplexity-crawlers.md (accessed 2026-10-21)
10. Google Search Central: What is a sitemap: https://developers.google.com/search/docs/crawling-indexing/sitemaps/overview (accessed 2026-10-08)
11. Search Console Help: URL Inspection tool: https://support.google.com/webmasters/answer/9012289?hl=en (accessed 2026-10-08)
12. Search Console Help: Page indexing report: https://support.google.com/webmasters/answer/7440203?hl=en (accessed 2026-10-08)
13. Google Search Central: AI features and your website: https://developers.google.com/search/docs/appearance/ai-features (accessed 2026-10-08)
14. OpenAI: Overview of OpenAI Crawlers: https://developers.openai.com/api/docs/bots (accessed 2026-10-08)