To avoid losing SEO when you migrate a website, connect every old URL that search engines know about to its closest equivalent on the new site with a permanent (301) redirect, and declare the new structure consistently through canonical tags, hreflang and your sitemap. In practice, that means listing the old URLs and building a mapping table before the move, then watching indexing and 404 errors in Search Console afterwards. Google says that for small and medium-sized sites, most pages can take a few weeks to move over.
The checklist below draws mainly on Google Search Central’s guide to site moves with URL changes. Where it helps, we add what we did when we rebuilt antargetech.com in October 2026.
Inventory the old URLs and build a mapping table
Everything rests on knowing which old URLs actually receive traffic and links. Combining Google’s suggestions with Search Console reports, build the list from these sources:
- The old sitemap: your most important URLs are probably in it.
- Search Console: the Page indexing report shows the URLs Google knows about, and the Links report shows pages with internal and external links. Keep a list of the sites linking to you; you will ask them to update their links later.
- Analytics and server logs: the pages with the most traffic, and URLs visited at least once in a period you choose.
- Your CMS: a full export of URLs that host content.
- Images, PDFs, CSS and JavaScript files: these are URLs too and need to move like everything else.
Then decide what happens to each old URL. A simple table is enough:
| Old URL (example) | New URL | Decision |
|---|---|---|
/our-services.php?id=3 | /services/seo | 301 |
/blog/2019/old-post.html | /blog/old-post | 301 |
/campaign-2019 | none | 410 (content removed) |
Three rules apply. Each old URL should point to the new page that best matches its content; Google warns that redirecting many old URLs to one irrelevant destination such as the home page confuses users and may be treated as a soft 404. Content you are not moving should return a 404 or 410 on the new site. If you merged several pages into one, redirecting the old ones to the merged page is fine.
Google also recommends changing one thing at a time. If the domain, the CMS and the design are all changing, doing them in sequence makes it much easier to find the cause when something goes wrong.
In our own migration, old URLs were redirected with 301s to their new equivalents, including 12 old URLs that Google still knew about. That is why the inventory has to be built from Google’s point of view as well as from the current site: an address that no longer appears on your site can still turn up in search.
301 redirects: why not 302 or meta refresh?
According to Google’s documentation on redirects, permanent redirects (301 and 308) signal that the target should become the canonical URL. Temporary redirects (302, 303 and 307) do not send that signal, and the old URL can keep appearing in search results. A migration is permanent, so the right code is 301 (or 308). Google also states that 301 and other permanent redirects do not cause a loss of PageRank.
Meta refresh and JavaScript redirects only run once the page loads in a browser. Google treats an instant meta refresh as permanent and a delayed one as temporary, and it may never see a JavaScript redirect if rendering fails. Its recommendation is a permanent server-side redirect wherever possible.
A few practical rules:
- Avoid chains. Googlebot can follow up to 10 hops, but Google recommends redirecting straight to the final destination and, if that is not possible, keeping chains to three hops at most.
- Keep redirects for a long time. Google recommends as long as possible, generally at least one year.
- Test them. Use the URL Inspection tool in Search Console for individual URLs and the command line for many:
curl -sIL http://www.example.com/old-page | grep -iE "^(HTTP|location)"You should see a single 301 followed by a 200. More than one 301 line means there is a chain.
Content, titles and technical signals
Keep content and titles stable
During the move, keep page titles, descriptions and content as close to the originals as you can. If URLs and content change together and traffic drops, you will not be able to tell which change caused it. Improve the content once the move has settled.
Canonical tags
Google asks for every new URL to carry a self-referencing canonical tag. Its canonical URL documentation recommends absolute URLs in the tag and says not to use robots.txt for canonicalisation; a redirect is a strong signal, sitemap inclusion a weak one. Before launch, make sure no canonical tag still points to the old domain or a staging address.
hreflang
On multilingual sites, update hreflang annotations to the new URLs. Google’s hreflang documentation says each language version must list itself and all other versions, URLs must be fully qualified including the protocol, and annotations may be ignored if pages do not point back to each other. You can declare hreflang in HTML, in HTTP headers or in the sitemap.
We marked the Turkish and English equivalent of every page with hreflang in our sitemap. For WordPress, we cover the topic in our post on multilingual WordPress and hreflang and in the Dynamic Translator case study.
www, HTTPS and trailing slashes
Google treats URLs with and without a trailing slash as separate URLs, and its canonicalisation overview lists HTTP and HTTPS versions among the causes of duplicate content. Apply the same logic to www and non-www: pick one form, use only that form in internal links and the sitemap, and 301 the others to it. Between equivalent pages, Google prefers the HTTPS version as canonical.
On our site, the www host redirects to the bare domain with a 301 and all traffic is forced to HTTPS through Cloudflare.
Launch day: sitemap, Search Console and Bing
- Remove staging blocks. Google lists forgotten
noindexrules and robots.txt blocks that were only meant for development among the common migration mistakes. - Submit the sitemap. Submit a sitemap with the new URLs in Search Console. You can keep a sitemap of the old URLs for a while to monitor the transition; Google says redirect warnings for it are normal.
- Verify every variant. In Search Console, verify the www, non-www, HTTP and HTTPS versions of both the old and new sites, and make sure your verification file or tag exists on the new site.
- Do not forget Bing. You can import your site from Search Console into Bing Webmaster Tools; imported sites are verified automatically and their sitemaps come along.
- Update links. Point internal links, social media profiles and ad landing pages to the new URLs, and ask important linking sites to update their links.
We submitted our sitemap in Search Console and imported the site into Bing Webmaster Tools from Search Console.
After launch: watch 404s and indexing
For the first few weeks, the Page indexing report is your main tool. Old URLs showing up as “Page with redirect” is expected: Google does not index the redirecting URL, while the target can be indexed. What needs attention is a rise in “Not found (404)” or “Soft 404”: these point to a URL missing from your mapping or a redirect going to the wrong place.
Also check your server logs for URLs where Googlebot hits errors, and confirm in analytics that traffic to old URLs is falling while traffic to new ones rises. Google warns that it will crawl the new site more heavily than usual after a move, so make sure your server has capacity. Temporary ranking fluctuations are normal; Google says rankings settle as the site is recrawled.
Frequently asked questions
When should I use the Change of Address tool?
Only when the domain or subdomain changes, for example from example.com to example.net. According to Search Console Help, it is not needed for HTTP to HTTPS moves, switching between www and non-www on the same domain, or path changes within a site. For a domain change, Google recommends submitting it for every verified variant of the old domain. Our domain stayed the same, and moving from www to the bare domain is outside the tool’s scope.
When can I remove the redirects?
Google generally recommends keeping them for at least a year and suggests considering keeping them indefinitely for users. If you used the Change of Address tool, its effect lasts 180 days, so do not remove redirects before then.
When will traffic recover?
There is no fixed timeline. Google says a move is complete only once Googlebot has visited every URL on the old and new site at least once, and the pace depends on the number of URLs and your server’s speed.
Conclusion
In short: list every old URL, send each one to its closest equivalent with a single 301, update canonical tags, hreflang and the sitemap to the new URLs, and watch Search Console for a few weeks after launch. A migration is also a good moment to review AI crawler access and structured data, which we cover in our post on GEO.
If you are planning to move your site to a new platform, take a look at our web and mobile app development and SEO and digital visibility pages; we are happy to go through the migration plan with you.
