Practice ·
A website move begins with a list of old URLs
A new website can load perfectly while its old entrances disappear. Bookmarks, external links and search engines continue to use previous URLs. A migration therefore starts before publication, with a map of where someone should arrive from every meaningful old address.
Define what is actually moving
Changing a server while preserving URLs, moving from HTTP to HTTPS, changing domains and redesigning the page structure require different work. Calling all of them a “move” hides the difference: if only files change, availability is central; if URLs change, each old page needs a route to its new counterpart.
Record the current domain, protocol, language versions, sections, canonical URLs and sitemap. Separately identify pages that bring enquiries, have external links or matter to returning visitors.
The URL map is the core document
Collect old addresses from the previous sitemap, analytics, search tools, content links and server logs where available. Give each one a decision: keep it, redirect it to an equivalent page, replace outdated content or return an honest 404/410 when no replacement exists.
Sending every vanished page to the home page is a poor shortcut. Someone seeking a specific object or service will not find the answer there. It also fails to tell a crawler where the equivalent material now lives.
A redirect should preserve meaning
When a URL changes permanently, a server-side permanent redirect points from the old address to its meaningful replacement. A language page goes to the appropriate language, an object record to that object and an article to its new location.
Shorten chains such as “old HTTP → old HTTPS → new URL” where practical. Above all, inspect the final response: it should load, contain the intended material and identify itself as the canonical page. A 301 status alone does not make a move successful.
Test the published site, not only its configuration
After release, run through the URL map automatically and manually inspect critical pages. Record the response status, `Location` header, final status, page title and canonical address for each old URL. Check internal links, language, images, forms and contact actions separately.
Update the sitemap to list the new canonical pages rather than redirecting URLs. Do not block old URLs from crawling before search engines have seen their redirects.
A 404 report needs investigation, not panic
During one c-b-gk.com update, Google Search Console listed three old URLs: two forms of `/ru` and a former EYE STAR table address. The working home page was at `/`, and the object record had moved into Apocrypha. Targeted 301 redirects were added and their responses checked on the live domain.
This does not mean every 404 needs “fixing”. A mistyped link, a nonexistent product or a removed page without an equivalent may correctly return 404. The question is whether a visitor expected real content and whether that content has a new home.
Monitoring continues after launch
Search reports describe earlier crawls and do not update instantly. Compare the crawl date with the fix date, check actual server responses and request validation only after the change is live.
Watch for unexpected 404s, redirects with unsuitable destinations, a drop in enquiries along important journeys and broken forms. For a substantial move, give someone ownership of the URL map and of decisions about new exceptions.
Migration belongs in the design of the new site
If development starts with a new structure, old URLs cannot wait until launch day. A content map and a URL map help decide which pages to combine, rewrite or retain. The new architecture then preserves paths to valuable existing material.
Within the Method, I treat migration as part of building and handing over a website: design the structure, map the URLs, implement redirects and verify real journeys after publication. It matters especially when a redesign or platform change must preserve the audience's existing connection to the site.
Start with the website's purpose
If you are planning a website or rethinking one, we can begin with its role in your business, its structure and the visitor's path to an enquiry.