Should you index a new URL before redirecting an old one in a 301?

What raises the issue of prior indexing?

For a long time, a common practice was to first publish a new page, wait for it to be crawled and indexed, and only then set up the 301 redirection from the old URL. The underlying idea: to avoid losing signals by redirecting to a URL that Google may not yet know.

This approach was based on the premise that an unindexed URL could be seen as less legitimate or less stable by the engine. Some SEOs feared that Google would not handle the redirection correctly if the target had not been validated by prior crawling.

What does Mueller exactly say about the redirection process?

Mueller is clear: no prior indexing is required. Google discovers the new URL when it follows the 301 redirection. At this point, the engine transfers the signals from the old URL to the new one and starts treating it as the canonical destination.

In practical terms, you can create a new page, set up the 301 immediately, and Google will take care of everything during its next crawl. No intermediate step, no waiting. The transfer of PageRank and ranking signals occurs as soon as the redirection is detected.

What are the implications for site migrations?

This confirmation radically simplifies the management of SEO migrations and restructurings. There's no need to orchestrate a two-step deployment: publish the new URLs, wait for indexing, then activate the redirections.

You can now switch your entire redirection plan in a single operation. This reduces the window of risk during which outdated URLs remain active and speeds up the overall process. For large sites, this is a notable operational gain.

• Google recognizes a new URL as soon as it follows the 301 redirection, without prior crawling
• Ranking signals (PageRank, anchors, history) are transferred at the moment the redirection is detected
• Migrations can be executed in a single phase without waiting for the indexing of new URLs
• This approach reduces the time during which outdated URLs remain in production
• No difference in treatment between an indexed URL and a fresh URL as a 301 target

Is this statement consistent with real-world observations?

On paper, yes. Tests show that Google does indeed follow a 301 redirection to an unknown URL without issue. Server logs confirm that Googlebot crawls the new destination as soon as it encounters the redirected old URL.

But — and this is where it gets tricky — the speed of signal transfer is not instantaneous. In theory, Google should quickly switch PageRank and positioning. In practice, significant delays of several weeks, or even months, are often observed before the new URL achieves the performance of the old one. [To be verified] whether this delay is the same regardless of whether the target is indexed beforehand.

What nuances should be considered based on context?

Mueller speaks of a simple case: a 1-to-1 redirection, from old URL to new URL. In this scenario, there is no complication. But what about complex migrations involving content consolidation, taxonomy reorganization, or chained redirections?

If you redirect 10 old URLs to a single new one that aggregates their content, it's better that this new page is already crawled, indexed, and assessed by Google before receiving this flow of signals. Otherwise, the engine must first understand what this page is about before deciding whether it deserves the legacy of the old pages. Result: even more latency in transfer.

Similarly, if the new URL presents a strong structural or semantic difference compared to the old one — change of subject, different format, modified language — Google may view the redirection as illegitimate and dilute the signal. In these cases, prior indexing helps validate that the new page is relevant and stable before inheriting the authority of the old one.

In what cases does this rule not fully apply?

First case: sites under constrained crawl budget. If Googlebot only visits your old URLs once a month, redirecting to a non-indexed new URL extends the delay before the new page is discovered and assessed. Here, pre-indexing the target via a sitemap or internal links may expedite the process.

Second case: temporary redirections or A/B tests. If you are not 100% sure the new URL is the right one, it's better to let it index naturally and observe its performance before sacrificing the signal of the old one with an irreversible 301.

What should you do during a migration?

First step: map your old URLs and their new destinations. Ensure that every redirection points to a semantically equivalent or superior page in terms of content. Google does not tolerate 301s to generic pages or unrelated categories.

Then, deploy your new URLs and redirections in a single operation. No need to wait. But — and this is crucial — immediately add the new URLs to your XML sitemap and submit it via Search Console. This speeds up discovery, especially if your internal linking does not yet massively point to these pages.

What mistakes should you absolutely avoid?

First mistake: redirecting to a URL that returns a 404 or server error. This may seem obvious, but during large-scale migrations, deployment bugs can make target URLs inaccessible. Result: Google follows the 301, encounters an error, and considers the redirection broken. You lose the signal.

Second classic mistake: redirection chains. Old URL → 301 → intermediate URL → 301 → final URL. Google follows up to 5 hops, but each hop dilutes the signal and slows down crawling. If you're restructuring, point directly to the final destination, even if it is not yet indexed. It's always better than a chain.

Third pitfall: neglecting post-migration checks. A redirection may seem to work in HTTP but fail in HTTPS, or vice versa. Or a CDN may hide the redirection on the server side but serve it as 302 on the edge. Check the actual status codes returned by your infrastructure, not just what your CMS displays.

How can you verify that everything is working as intended?

Use Search Console to monitor coverage errors after migration. If old URLs continue to appear in the index several weeks after the 301s have been implemented, it indicates that Google is encountering a problem — undetected redirection, robots.txt blocking, or redirection chain.

Also check the "Performance" tab to compare traffic before and after. If the new URL has not regained the positions of the old one after 4-6 weeks, dig deeper: is the content too different, cannibalizing with other pages, or losing external backlinks that specifically pointed to the old URL and have not been updated?

• Map all 1-to-1 redirections before deployment
• Deploy new URLs and 301 redirections simultaneously
• Add new URLs to the XML sitemap and submit via Search Console
• Check the real HTTP codes (not just on the CMS side) for each redirection
• Eliminate any redirection chains — point directly to the final destination
• Monitor Search Console for 4-6 weeks post-migration to detect coverage or traffic anomalies