Corporate website migration: preserve key pages and verify the result

A corporate website migration starts with an inventory of existing pages, forms, and integrations. If URLs change, each important old page needs a relevant new destination or a deliberate decision to remove it. After launch, check server responses, forms, redirects, and search reports—not just the homepage.

No procedure guarantees that positions and traffic will not fluctuate. Google warnsthat a transfer with a URL change requires time to crawl and process signals. This plan helps reduce technical errors and determine in advance what to do if something doesn't work after launch.

Short answer: first remove the state of the old site and make a table old URL → new URL. Then prepare a new site on a test circuit, test redirects and functions, keep the rollback option in place, and only then switch traffic.

Download the working URL map: RU — XLSX · EN — XLSX. The workbook contains a sheet for your own map and separate illustrative examples. Each URL has fields for the decision, expected and observed server responses, final URL, canonical, owner and check result.

Define the transfer type

Scenario	What's changing	Main risk
Change hosting without changing URL	Server and environment	Forms, Integrations, DNS and Performance
Changing CMS while maintaining URL	Code, templates, admin panel	Loss of content, metadata, structured data and functionality
Redesign with URL change	Pages and addresses	Missed redirects, inconsistent new pages, internal links
Domain change	Domain and usually infrastructure	All of the above plus updating external services and notifying search engines

If the URLs don't change, don't create redirects for the sake of migrating. Focus on consistency between content and function. If both the CMS and the structure change, separate the technical move and content changes where possible: this makes it easier to find the reason for the subsequent drawdown.

Collect initial data before development

Extract URLs from sitemap, CMS, search analytics and server log. One sitemap may not contain old URLs with external links or actually visited pages. For each URL, save the page type, current server response, canonical, title, number of organic clicks, and destination address after migration.

Separately list forms, entry points into CRM, telephony, payment, personal accounts, analytical events and third-party scripts. Capture work scenarios before switching. This will allow, after release, to compare the result with the original state, and not with the team’s memory.

Back up your files and database and check that it can be restored in a separate environment. A copy without recovery verification is not a reliable rollback plan.

Map URLs and redirects

There are only a few required fields in the table:

Old URL	New URL	Action	Responsible owner
/services/old-name	/services/new-name	Permanent redirect	SEO and developer
/blog/topic-a	/blog/topic-a	Save address	Editor
/catalog/old-item	/catalog/new-item	Redirect for an equivalent product	Directory owner
/promo/expired	—	Check if there is a replacement; if not available, leave the correct answer 404/410	Section owner

Google recommends permanent server redirects for addresses that have actually moved, and advises leading directly to the final URL, without long chains. Don't send all your old pages to the home page; it rarely answers the same question. When deleting without a relevant replacement, you need an honest status of the missing page.

Also check internal links, canonical addresses, hreflang for language versions and sitemap. All of them should point to the final accessible addresses, and not to intermediate redirects.

How to fill in the URL map template

Enter your site's URLs on the URL map sheet. Use complete URLs, including the protocol and domain, for real checks; the relative paths on the Examples sheet describe illustrative scenarios only. The initial Not checked results mean that no checks have been completed.

Start with the plan: old and new URLs, the decision and its reason, and expected responses. A CMS change alone does not require a redirect when the URL stays the same. For a moved page, agree a permanent redirect to a relevant replacement. For removed content with no replacement, agree a 404 or 410 response separately. The workbook's 404 example does not set a rule for every removal.

After configuration, open the old URL and record its observed response, final address and destination page response. Check that the new page contains the agreed content and that its canonical points to the intended final URL. A 200 response matching the plan does not by itself establish that content has been preserved or that the page appears in search.

Record the date, owner and evidence, such as an anonymised crawl report or a note of the workflow checked. Mark Passed once you have checked the decision, responses, final URL and content. For a mismatch, use Needs correction and state the specific reason. Use Not applicable with an explanation for an individual check that does not apply to the selected decision.

Resolve rows with no decision before deployment. Then repeat the checks on the public domain and retain a separate results copy: a successful test-environment check does not establish that the public site is configured correctly.

Prepare and test your new site before switching

The test circuit is needed for acceptance, but should not become a search copy of the main site. Restrict access to it and make sure that restrictions used in the test do not accidentally transfer to published pages. Google specifically reminds remove noindex from the new site at the time of launch, if it was needed before publication.

Check not random pages, but types of templates: home, service, category, card, article, form, search and language version. For each type, compare the content and metadata to the agreed upon plan. Blind transfer of old title and description is not necessary if they were corrected within the project; It is important not to lose the target intent of the page.

Check	Acceptance result
Server URLs and responses	Pages are opened at the final addresses, old routes lead to the necessary new ones
Forms and CRM	The test application reached the desired recipient with the source and consent
Content and images	Texts, files and images are available on all page types
SEO templates	Your own canonical, meaningful title and H1, correct internal links
Indexing	There is no randomness on public pages noindex and bypass locks
Analytics	Events are not duplicated and arrive at the correct counter
Mobile scenario	Menus, forms and key actions work on the phone

For a new corporate website structure, it is useful to agree in advance required sections and user routes. If a contractor is still being selected, use performer evaluation checklist.

How to launch with rollback option

Assign a switchover time, infrastructure owner, and monitoring window. Before starting, save a current copy and list of changes to DNS, proxy, certificate and environment variables. The rollback plan should answer three questions: at what failure do we return to the previous version, who makes the decision, and how long does the rollback take.

After switching, go through a short list of priority URLs manually and through automatic checking. Make sure that 301/308 lead to final addresses, there are no 404 on key pages and there are no chains. Google uses permanent redirect as a signal to select a new canonical URL; The redirect itself does not replace the quality of the new page.

What to watch after moving

In the first days, check server errors, forms, robot visit logs, and pages that old addresses lead to. Then compare search impressions and clicks across groups of pages over a comparable period before launch. Separately monitor the pages that previously brought applications.

Signal	First check
The number 404 has increased sharply	Find source links and missing URLs in migration map
New pages do not appear in search	Check the server response, noindex, robots, canonical, sitemap and internal links
There are impressions, but clicks have fallen	Compare queries, title and page type; do not change all metadata at once
There are clicks, but no applications	Check forms, telephony, events and script on mobile

Google notes that crawling may take time and advises Use crawlable links and up-to-date sitemap data. Submitting a sitemap helps discovery, but does not guarantee a time frame for indexing or traffic recovery.

Checklist before project acceptance

• There is a table of old and new URLs, including previously visited pages outside the sitemap.
• The backup copy was restored on the test circuit.
• Redirects lead to relevant pages without unnecessary intermediate addresses.
• Tested forms, integrations, analytics and mobile scenarios.
• Test indexing restrictions have been removed on public pages.
• Sitemap, canonical and internal links point to the final URLs.
• Those responsible for the launch, rollback and post-launch monitoring have been appointed.

If your current site is already receiving submissions, start the project with site audit and an agreed transfer card. This gives the team a verifiable starting point for development and acceptance.

Sources

• Google Search Central: Site Migration with URL Change
• Google Search Central: Redirects and Google Search
• Google Search Central: Diagnosing Crawl Errors