Why Old URLs Stay in Google After a 301/308 Redirect
Published August 2026 by Solarc Labs
A permanent redirect is a routing signal, not an instant index purge
When an old URL returns a permanent 301 or 308 to a new canonical destination, the routing decision is correct immediately for a user or crawler that requests the old address. Search indexes are separate systems. Google still has to discover or revisit the old URL, follow the redirect, evaluate the destination and update its stored canonical/index state. That is why an old URL or stale snippet can remain visible for a period even when the live server no longer serves duplicate HTML.
Site moves are processed URL by URL
Google Search Central describes site moves as a gradual recrawl and reindex process. A move is only fully processed after Googlebot has revisited the relevant old and new URLs. For a medium-sized site, Google says it can take a few weeks or more before new URLs consistently replace old ones. There is no fixed crawl frequency, so a clean redirect implementation can still coexist temporarily with stale search results.
The strongest cleanup pattern is boring and consistent
Keep the permanent redirect in place. Keep redirected legacy URLs out of canonical sitemaps. Put only the preferred new canonical URLs in the sitemap. Point internal links directly at the canonical destination rather than through the redirect. Use self-canonicals on the preferred pages. For the highest-priority URLs, Search Console URL Inspection can request re-indexing after the technical fix is live, but Google documents quotas and recommends reserving it for important pages.
Where IndexNow fits — and where it does not
IndexNow lets participating search engines receive a direct changed-URL notification when a URL is added, updated, moved or deleted. A successful HTTP response means the notification was received; it is not proof that the URL was crawled, removed, indexed or ranked. IndexNow is not the Google Indexing API. For Google, permanent redirects, canonical signals, crawlable internal links, sitemaps and Search Console remain the relevant migration controls.
A real Solarc migration lesson
Solarc uses dedicated product hosts for canonical product roots while historical non-root product-host HTML paths permanently redirect to the matching central solarclabs.com path. Public search can still surface some pre-isolation ShipStory URLs. We treat that as index-refresh debt, not evidence that the current production router should restore old pages or copy. The engineering rule is simple: fix the live routing once, preserve the canonical signals, notify eligible engines, then measure recrawl instead of creating replacement doorway pages.
Primary sources
Sources used for this article
Continue the job