Which versions of your documentation should Google index?

How we researched this

We inspected eleven primary guidance pages from Google and Read the Docs on November 10, 2026. Sonar Pro and Sonar Deep Research supported source discovery and challenge; the original pages were inspected independently. This is a synthesis of documented mechanisms, followed by our proposed version-policy exercise. The example product, URL paths and decisions are fictional. We did not change a live documentation site, inspect customer Search Console properties, measure ranking changes or compare vendor performance. Access dates identify the evidence reviewed; undated vendor pages are not assigned inferred publication dates.

An older guide can still be the right answer

A customer searches for a configuration option that exists only in the product release they still use. Another customer searches for the same task without naming a release. Sending both people to the newest manual may look tidy in a report, but it does not necessarily help either person complete the task.

The useful starting question is whether the pages answer the same question. Their age, shared layout and matching headings do not settle that. An installation guide with a different authentication flow or incompatible configuration format may deserve a different decision from an unchanged overview copied into several release folders.

Google says it groups pages whose main content is identical or very similar, then chooses a representative URL using several signals. Ordinary duplication is not automatically a spam-policy violation. That is a narrower claim than saying every repeated paragraph harms a documentation site. Google's canonicalization explanation

Our recommendation is to classify reader intent before applying a site-wide rule. For a supported older release, ask a product specialist to identify the instructions that must remain distinguishable from current guidance. For a retired release, ask whether anyone still needs historical reference and how they should reach it.

Consider a fictional product called Atlas, with current release 4, supported release 3 and retired release 2. A fourth area contains a release-5 preview. These are planning categories, not a claim about how many releases a real team should maintain.

The goal for Atlas is explicit: a release-3 customer should be able to find release-3 instructions, while a new customer should be able to recognize the current guide. Whether the release-2 archive belongs in external search is a separate decision. Keeping that question separate prevents an SEO setting from silently becoming a support-policy change.

Which control matches the decision you are making?

The control descriptions below summarize the cited documentation; the review questions are our proposed checks.

Write the desired reader outcome in a sentence before choosing a setting. “Prefer this copy,” “keep this out of Google” and “prevent public access” are different requirements.

Google ranks redirects and canonical annotations as stronger canonicalization signals than sitemap inclusion. It advises against conflicting preferred URLs across signals and against using noindex simply to choose a canonical within one site. Canonical methods

The other rows draw on Google's guidance for noindex, robots.txt, URL moves and sitemaps. None of this table describes a mechanism for keeping confidential material private.

For Atlas, the requirement for release 3 might be “keep its distinct setup guide discoverable.” The requirement for a duplicate domain alias might be “prefer the primary domain.” Applying the same rule to both would erase the distinction between a product version and another address for the same page.

Make the decision visible to the person implementing it. Record the affected path, the intended audience and the reason. A setting labeled “hide” needs an explanation of what becomes hidden and from whom. Without that explanation, a reviewer can approve a configuration that does something quite different from the policy they intended.

Should every old page point its canonical to the latest version?

Not as a blanket policy. Google's canonical guidance is framed around duplicate or very similar pages. Applying it across materially different instructions requires a content decision, not just replacing a version number in a URL. Canonical methods

Use Atlas's setup guide to make the distinction concrete. Suppose release 3 requires a local configuration file, while release 4 uses an account setting. The two pages may share the title “Configure Atlas” but serve different installations. Our proposed policy keeps both as distinct candidates for discovery while clearly labeling the applicable release.

Now suppose the company overview is unchanged across releases. That is a better candidate for consolidation, provided the team verifies that the page does not contain version-specific navigation, examples or prerequisites that matter to the reader. Do not infer equivalence from a filename alone.

A review can ask:

• Would a reader following either page perform the same steps?
• Do prerequisites, defaults or supported environments differ?
• Does the older page explain behavior removed from the current release?
• Does the proposed destination contain the information promised by the old link?
• Is this an alias of the same page or a separate historical instruction?

These are our editorial checks, not a Google scoring formula. They are intended to produce a defensible explanation for the chosen relationship.

A self-referencing canonical can express a preferred address for a distinct page, but it cannot force Google to keep that page as a separate search result. That follows from Google's stated independence in canonical selection. Canonicalization

Avoid treating a successful deployment as proof that the policy worked. It can demonstrate that the intended annotation was emitted. The search engine's subsequent selection is an observation to collect separately.

Why can a hidden version still appear in search?

Google says robots.txt governs crawler access. A blocked URL can still appear in results based on information found elsewhere, even though Google cannot fetch its content. Search absence and crawl blocking are therefore different outcomes. Robots.txt guidance

A noindex rule is delivered in page metadata or an HTTP response header. Google must be able to fetch the resource to discover that rule. Blocking the same path in robots.txt can prevent that discovery; putting noindex inside robots.txt is not supported. Removal is not instantaneous because the page must be crawled again. Noindex guidance

For Atlas's public release-2 archive, assume the team wants direct links to keep working but does not want the archive in Google. That intent leads to a review of index exclusion, not merely removal from the version menu. The implementation should be checked on the archive pages themselves.

Read the Docs supplies a useful example of why the label matters. Its version documentation says hidden versions disappear from the flyout, receive a disallow rule in the default robots.txt and remain accessible through direct links. It describes private versions separately. Deactivating a version has another consequence: its artifacts are deleted and requests return 404. Read the Docs version states

The platform's robots reference also warns that the file is not a guarantee against indexing. It serves that file from the project's default version. Google's explanation adds the important point that a known URL can remain in results even when crawler access rules are obeyed. Read the Docs robots reference Google crawler guidance

For a documentation owner, the practical next step is to inspect the actual response and rules. Do not make a potentially destructive version-state change merely because its label sounds like the search outcome you want.

What should you check when a host generates the SEO settings?

Configuration is an input. The delivered page is the thing a reader and crawler encounter. Record both so that a platform setting can be connected to a specific output.

Read the Docs says its canonical URL considers the project's default version and canonical domain. It passes that URL into the build as READTHEDOCS_CANONICAL_URL for the documentation tool to use. That documented integration does not establish the final annotation in every theme or custom build. Read the Docs canonical URLs

For Atlas, review one current guide, one changed older guide, one unchanged duplicate and one archive page. Check the actual URL, HTTP response, canonical annotation and any indexing rule. Include the primary domain and an alias if both serve the documentation. A homepage-only check would miss the policy distinctions in this example.

Keep a small evidence record:

This is a proposed audit record, not a report of tests on a hosted project. Keep it small enough that a maintainer will update it when the default release changes.

Also separate the public site's own search settings from external search policy. A reader can arrive through a bookmark, a support link, the site's search bar or Google. Decide which paths the archive should support, then test those paths individually. A Google indexing decision should not stand in for an assessment of the internal search experience.

A practical decision table for current, older and preview docs

The following choices belong to the fictional Atlas example. They are a starting point for discussion, not defaults that every product should copy.

The point is not the chosen release numbers. It is that each row starts with a reader need and ends with an observable condition. The same table might produce different decisions for a product with long support contracts, public historical research or a single continuously updated service.

Add exceptions at the page level when necessary. A retired product's migration guide may remain useful even when routine configuration pages are no longer intended for discovery. Conversely, an unchanged legal or company page need not acquire a new searchable identity merely because the site copied it into another directory.

Before implementing the policy, have the product owner confirm which releases are supported and have the documentation owner check content equivalence. Ask the person responsible for search to translate those decisions into the site's supported controls. These responsibilities may belong to one person on a small team; the questions still need separate answers.

Do not call the policy successful because the number of indexed pages falls. If the removed pages were the only useful answers for supported customers, a smaller index can be the wrong result. Evaluate the chosen outcomes rather than optimizing the count alone.

When is a redirect better than keeping an archive?

A redirect is a reasonable candidate when the old address has a genuine replacement and the old document no longer needs to be served there. It is a poor substitute for deciding whether an older instruction still matters.

Google's site-move guidance recommends mapping old URLs to their corresponding destinations. It warns that sending many unrelated old URLs to a single homepage can confuse users and may be treated as a soft 404. It also allows several old pages to redirect to a new page that actually consolidates their content. Google site-move guidance

For Atlas, imagine a release-3 troubleshooting article is moved to a maintained support guide that still explains the release-3 error. That is a different case from redirecting a release-3 command reference to release 4 simply because release 4 is newer.

Use the promised task as the review unit. Open the old link description, identify what someone expected to learn, and check the proposed destination against that expectation. If the destination requires a different product release, decide whether a warning and a choice of paths would serve the reader better than an automatic move.

A migration guide can be a useful destination when it genuinely answers the old link's purpose. It is not automatically equivalent to every retired page. Retaining an archive, returning a deliberate removal response and providing a real replacement are different options with different reader consequences.

Document the decision before changing routes. Record the pages that must remain accessible, any intentional removals and the expected destination for each redirect. For a larger URL move, use the broader documentation preservation checklist. The narrower concern here is avoiding a search cleanup that quietly changes which product instructions a reader receives.

How do you verify the policy without mistaking a check for a result?

Use two records: what the site currently serves and what Google last reported. They can disagree without either record being fabricated, because they describe different observations.

Search Console's URL Inspection documentation distinguishes indexed information from a live test. The live test can assess aspects of current indexability, but it cannot predict Google's canonical choice. The indexed report contains the Google-selected canonical and may describe an earlier crawled state. Even a positive indexed status is not a guarantee of appearing for a particular search. URL Inspection

For an owned site, our proposed procedure is:

1. Freeze the policy record for the release under review. Keep the intended outcomes separate from observed results.
2. Select pages covering each policy case, including a deep page and an alias where relevant. Record why each page was chosen.
3. Inspect the served status, destination, content version, indexing rule and canonical annotation. Check the applicable crawler rule and sitemap entry.
4. Save the inspection time and deployed revision. A later result should not be compared with an unidentified build.
5. Inspect Google's indexed information where available, recording its crawl date and selected canonical. Record a live test separately if one is run.
6. Classify a mismatch as a site-output problem, a policy disagreement, an older observation or an unresolved indexing outcome. Assign the next investigation accordingly.

This procedure has not been executed as a benchmark for this report. It is designed to make follow-up work specific. “Google has not yet reflected this change” and “our page still emits the wrong annotation” require different responses.

A sitemap can help Google discover important URLs, but inclusion does not guarantee crawling or indexing. Use it as evidence of the site's declared inventory, not proof that the inventory is present in Search. Sitemap guidance

Avoid repeatedly changing the policy while waiting for observations. Otherwise, a later selected URL may be attributed to the wrong version of the configuration.

What should you measure after the change?

Start with the policy's intended outcomes, then use traffic data as supporting evidence. A drop in archive impressions might be expected after a deliberate exclusion. The same drop on a supported version might warrant investigation. Neither observation, on its own, proves that readers found better answers.

Google says most Search Console performance data is assigned to the canonical URL rather than a duplicate. It also omits anonymized queries and does not expose every other query row. A page-level report therefore needs interpretation before it becomes evidence about a specific version's audience. Search Console data groupings

For Atlas, keep three views separate:

• Technical observations: delivered rules and reported canonical choices.
• Discovery observations: available impressions, clicks and visible version-specific queries over a stated period.
• Reader observations: whether a person with the stated product release reaches applicable instructions and completes the intended task.

These are proposed evaluation categories, not new platform analytics features. If reader testing is not available, say that the evidence concerns discovery and configuration only. Do not substitute an increase in total clicks for proof that supported customers found the correct manual.

For a small manual, begin with a handful of clearly defined tasks: configure release 3, install release 4 and locate the retained release-2 reference. Have reviewers record which version they reached and why it was appropriate. This is a task check, not an estimate of how all visitors behave.

When comparing periods, record the dates, site changes and any product launch that could affect demand. If you cannot isolate the cause of a movement, report the association rather than claiming the indexing policy created it.

The useful final record is a set of explained decisions: which guides should remain discoverable, which copies are equivalent, which archives remain accessible and what the latest observations show. That gives the next release owner something better than “always index everything” or “always point to latest.” It gives them a policy they can inspect, challenge and maintain.

Limitations

Google guidance does not establish how another search engine handles the same directives. Host documentation describes intended settings, not a test of every generated page. No source here establishes a universal number of versions to index, a guaranteed recrawl deadline or a percentage traffic improvement. The proposed review sample is designed to expose different policy cases, not estimate a population failure rate.