Why do indexed pages persist in site: search after a service has ended?

What does this statement from Google really mean?

The site: command is one of the most entrenched reflexes among SEOs. We type site:mydomain.com and expect to see the true state of the index. However, Google reminds us of an uncomfortable truth: what you see in site: is not a faithful mirror of the canonical index.

When a service closes or a migration occurs, hundreds (or even thousands) of pages may remain visible in site: while their canonical URL has already changed on Google's side. The engine has chosen the new URL as a reference, but the old one continues to display in the command results. It's counterintuitive, but it's the technical reality of this function.

Why doesn’t site: only show canonicals?

The site: command was never designed as a precise diagnostic tool. It returns a sample of indexed URLs, without guaranteeing they are canonical versions. Google may display variants, duplicates, old versions — everything that has been crawled and remains technically in the index, even if it's no longer the reference version.

Specifically, if you migrate a site from old.com to new.com, you may see the URLs of old.com in site:old.com for weeks, even though Google has already switched to new.com for the true ranking. The display in site: does not instantly follow canonical logic.

Should we completely ignore site: results?

No, but it should be put into perspective. The site: command remains useful for a quick macro view: how many pages Google sees approximately, whether there are unexpected sections, strange patterns. But never rely on site: to validate a migration, diagnose a canonicalization problem, or measure fine indexing.

For that, you have Search Console, coverage reports, organic traffic data. If your new URLs generate traffic and appear in performance reports, it means they are recognized as canonicals. The rest is just residual noise in the site: display.

• site: displays a sample of indexed URLs, not necessarily canonicals
• After a migration or closure, old URLs may remain visible for weeks
• Google often internally chooses the new URL as canonical, even if the old one still appears
• Search Console and organic traffic are the only reliable indicators for validating canonicalization
• Don’t panic if site: still shows dozens of pages from an old service — first check actual traffic

Is this statement consistent with real-world observations?

Yes, and it's even a relief that Google finally says it explicitly. For years, we've seen clean migrations — perfect 301 redirects, updated sitemaps, clean Search Console — with hundreds of old URLs lingering in site: for 2-3 months. This generated client-side anxiety, unnecessary alerts, and hours of diagnostics for nothing.

The reality: traffic had switched to the new URLs within days, the old URLs no longer appeared in SERPs for real queries. But site: continued to display the old inventory. Google confirms here that it is normal, that it is not a bug, and that there is no need to be alarmed.

What nuances should be added to this statement?

Be careful: Google says “there is no need to worry,” but that doesn’t mean “ignore all warning signals.” If old URLs remain in site: and you notice a drop in traffic, that’s a real problem. If they are still generating impressions in Search Console, it means Google did not correctly redirect them or that the redirects are not followed.

[To check]: The statement does not specify how long this residual display may last. In practice, we observe between 3 weeks and 3 months depending on the size of the site and the crawl frequency. But Google provides no quantified guarantees. If it lasts 6 months with old URLs still generating traffic, there is likely an issue with the redirects or misconfigured canonicals.

In what cases does this rule not apply?

If you see sensitive pages in site: that should have been removed (personal data, noindex pages, embargoed content), do not ignore them. The fact that they appear in site: means they are technically crawlable. Use the URL removal tool in Search Console to force immediate removal.

Similarly, if you find that 404 pages or outdated content continue to receive organic traffic (not just to appear in site:, but actually to rank and generate clicks), it’s abnormal. It indicates that Google has not yet switched to the new canonical URL, and you need to investigate the redirects, canonicals, or sitemap structure.

What should you check concretely after a migration or closure?

First, forget about site: as a validation metric. Go to Search Console, Performance section, and filter by URL. Look at which pages generate impressions and clicks over the last 28 days. If these are the new URLs, great. If they are still predominantly the old ones, you have a problem with redirects or canonicals.

Next, check the coverage report in Search Console. The old URLs should appear as “Redirected” or “Excluded by noindex tag.” If they remain “Valid,” it means Google did not detect the redirect or it is not functioning properly. Test some URLs manually with curl or a tool like Screaming Frog to confirm the HTTP status code.

What mistakes should be avoided when encountering this type of situation?

Do not request massive reindexing via Search Console to “force” the removal of old URLs. It doesn't work that way. Reindexing does not remove URLs from the index, it just requests a recrawl. If the redirect is in place, Google will eventually understand it on its own. Forcing the crawl can even slow down the process by saturating your crawl budget.

Avoid panicking and modifying redirects midway. If you have implemented 301s, leave them in place for at least 6 months, ideally 1 year. Changing redirects or switching to 302 thinking it would “accelerate” the process creates more confusion than anything else.

How can you monitor that everything is going smoothly?

Set up a weekly monitoring of organic traffic by groups of URLs (old vs new). If traffic on the old URLs gradually decreases and that on the new ones increases, it’s a good sign. Conversely, if the traffic stalls on the old ones after 4-6 weeks, dig deeper: broken redirects, conflicting canonicals, sitemaps still pointing to old URLs.

Also, use Google Analytics (or your tracking tool) to identify organic landing pages. If users still arrive on old.com/page instead of new.com/page, it’s a real problem, not just a display artifact in site:. In this case, check that redirects are properly set up on the server, tested with a real Google user-agent.

• Validate 301 redirects with curl or Screaming Frog, not just in the browser
• Check in Search Console > Performance that new URLs generate clicks
• Verify the coverage report: old URLs should be “Redirected”
• Update the XML sitemap to reference only the new URLs
• Monitor organic traffic by group of URLs for at least 3 months
• Do not request massive reindexing or modify redirects midway