Imagine that the new site is live and looks better: it is easier to read and use on a phone. Visits fall after the change. The appearance of the pages alone does not explain what happened.
One check is the list of old URLs. They may still appear in Google, bookmarks or links on other sites. If they changed, check where they lead now. This article covers that work, not every possible cause of falling traffic.
Check what changed beyond the appearance
If the site never appeared in search, start with my site does not appear on Google. In a rebuild, also compare the old and new URLs, content and settings. Matching dates do not establish the cause of a decline.
A page can change its URL while keeping the same purpose. A redirect connects the old address to the new one and helps visitors and search engines find the right destination.
The URL inventory and tests need a deadline and an owner. Ask for them to appear in the plan and quote. Opening only the home page does not verify that work.
The inventory comes first: you cannot map what you have not listed
Google’s documentation on site moves with URL changes starts here, and its first instruction is the one that changes the size of the job: start with your important URLs. There are four sources for the list, and none of them gives it whole.
- The old sitemap, often at
/sitemap.xml: provides a list of URLs, but does not replace data about how they are used. - The platform’s or the server’s list of pages: the content management system enumerates what it published, and the server logs hold what was actually requested.
- Search Console: the indexing report says what Google is holding, and the links report says which pages other sites have cited.
- Analytics: helps identify pages people use. Combine it with inbound links and each page’s importance to the business.
Prioritise pages with traffic and external links without automatically deleting the rest. A page can matter to the business even without recorded visits, and the available measurement may be incomplete.
Also include images, videos, PDF files and other resources that need to remain accessible. Do not limit the list to text pages.
Old address to new address, one by one
With the list in hand, you decide, for each old address, which new page corresponds to it. It is not an elegant document: it is two columns and one line per address.
Sending everything to the home page can leave visitors without the content they wanted. Check whether each destination corresponds to the old URL.
Google warns that irrelevant destinations may be treated as soft 404 errors.
The same page opens the exception that matters in an honest rebuild: if you have consolidated onto one new page the content of several old ones, you can redirect those old ones to the consolidated page. The test is whether the destination answers the question that made the person click.
Pages with no equivalent should answer 404 or 410, which is what Google asks for deleted content. A page that answers «all fine» and says there is nothing there is the documentation’s soft 404: success code, error content.
Permanent or temporary, and why getting it wrong here is silent
Once each line has a destination, the server has to be told what kind of move this is. Google’s documentation on redirects sums it up in two lines:
Choose the redirect type according to how long the move is intended to last.
Codes 301 and 308 indicate a permanent move. Codes 302, 303 and 307 are temporary. Google does not use the latter alone as a signal to select the destination as canonical; other signals may affect that choice.
A visitor may reach the right page with either type. The test should therefore check the returned status code, not just whether the page opens.
In its migration guidance, Google says permanent redirects do not cause PageRank loss. That does not guarantee unchanged rankings or traffic. Prefer server-side redirects; use JavaScript only when Google’s listed alternatives are unavailable.
What else changes address besides the pages
The redirects are the skeleton. Around them, four things move at the same time:
- The sitemap lists the new URLs and is submitted in Search Console. The old sitemap can help monitor the transition; it need not remain permanently.
- The internal links have to point at the new pages, not at the old ones waiting for the redirect to save them. A chain is a cost, not a fix: Google follows up to ten hops, but advises redirecting straight to the destination, because every hop adds waiting.
- Canonical tags should refer to the correct URLs. Also check for indexing blocks, such as
noindex, left from the build. - Search Console has a Change of Address tool for moves between domains or subdomains. It requires verified ownership of both sites in the same account. Do not use it solely for path changes, HTTP to HTTPS, www to non-www, or hosting changes without changed URLs. Variants and subdomains need separate attention.
The honest timeline
Moving to new URLs takes time. Google gives a rough indication of a few weeks for most pages on small or medium sites, varying with scale and server performance. That is not a guaranteed deadline for your site.
Traffic may fluctuate during the move. The cited guidance does not promise recovery of a particular amount of traffic. Compare the before-and-after data and investigate unexpected changes.
Plan to maintain redirects for at least a year, following Google’s general guidance. The 180 days concern the Change of Address tool’s actions. Keep control of the old domain and a service that responds at its URLs; that service can run on the new hosting.
Before changing URLs, check whether you need to
Keeping existing URLs avoids mapping them to new addresses. It can be a good choice when they still fit. Changes to content, settings and hosting still need testing.
Google’s guidance helps separate those decisions:
Avoid combining a domain move with a major reorganisation of content and URLs. Separating the changes makes each one’s effects easier to assess.
Google has separate guidance for hosting changes without URL changes. Availability and functional tests are still needed.
Keeping is not always the answer: addresses stuffed with parameters, paths that no longer describe anything, a domain that changed name along with the company. Then you move, with an inventory, a map and a deadline. What you do not do is move out of habit.
Before the move, confirm administrative access to the domain, DNS and hosting. Save the DNS records used for email and preserve the required ones, including MX and the authentication records specified by the provider. Test sending and receiving after the move. If access is unclear, start with who owns your website.
If you are preparing a rebuild, include URLs in the plan from the start. If you have already launched and visits fell, investigate before assigning a cause. To review the list and migration plan, book a 15 minute call.
Sources
- Inventory of old addresses, the mapping, the irrelevant destination, redirect chains, sitemaps, canonicals and timings: Google Search Central, «Site moves with URL changes».
- Redirect types, what each one shows in results, and the recommendation to do them server side: Google Search Central, «Redirects and Google Search».
- Change of Address tool, the cases where it is not used, the 180 day period and keeping the architecture: Search Console, «Change of Address tool».
- A move with no user-visible address changes: Google Search Central, «Changing your hosting».
- HTTP status codes and error responses: Google, «How HTTP status codes affect Google’s crawlers».
- Email DNS records: Cloudflare, «Set up email records».
Sources checked on 10 September 2026 in the English original. The article summarises the guidance and links to the documentation.