ci: gate the API reference against duplicate-content across versions - #431
Open
eugenia-scandit wants to merge 1 commit into
Open
ci: gate the API reference against duplicate-content across versions#431eugenia-scandit wants to merge 1 commit into
eugenia-scandit wants to merge 1 commit into
Conversation
The API reference is published once per major.minor line, so the same symbol page exists at /6.28/data-capture-sdk/X, /7.6/data-capture-sdk/X and the unversioned /data-capture-sdk/X. None of them declares which is canonical, so Google treats them as independent pages and picks whichever it likes - usually the oldest, because it carries the most history and inbound links. That is how /6.28/.../aamva-barcode-result.html came to outrank current docs. The rule this checks, per versioned page: unversioned counterpart returns 200 -> canonical pointing at it unversioned counterpart returns 404 -> robots noindex The second branch is the one easy to get wrong. An API removed since that line has no current equivalent, so a canonical would point at a 404 and Google would ignore it; that page needs de-indexing, not redirecting. Both cases occur in practice - the first sampled run found 4 of one and 3 of the other. Nothing here is version-specific, which is the point: the canonical target is always the unversioned URL, which is by definition the current line. A release never changes what this expects and there is no version constant to maintain. URLs come from the versioned API links the built site already contains (2,049 distinct across /6.28/ and /7.6/), sampled deterministically so CI checks the same pages each run rather than drifting. Warns rather than fails. The API-reference HTML is generated outside this repository, so this gate can only observe it - it is merged now so the finding is visible and tracked, and takes --strict once the generator emits the tags. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The API reference is published once per major.minor line, so the same symbol page exists at /6.28/data-capture-sdk/X, /7.6/data-capture-sdk/X and the unversioned /data-capture-sdk/X. None of them declares which is canonical, so Google treats them as independent pages and picks whichever it likes - usually the oldest, because it carries the most history and inbound links. That is how /6.28/.../aamva-barcode-result.html came to outrank current docs.
The rule this checks, per versioned page:
unversioned counterpart returns 200 -> canonical pointing at it
unversioned counterpart returns 404 -> robots noindex
The second branch is the one easy to get wrong. An API removed since that line has no current equivalent, so a canonical would point at a 404 and Google would ignore it; that page needs de-indexing, not redirecting. Both cases occur in practice - the first sampled run found 4 of one and 3 of the other.
Nothing here is version-specific, which is the point: the canonical target is always the unversioned URL, which is by definition the current line. A release never changes what this expects and there is no version constant to maintain.
URLs come from the versioned API links the built site already contains (2,049 distinct across /6.28/ and /7.6/), sampled deterministically so CI checks the same pages each run rather than drifting.
Warns rather than fails. The API-reference HTML is generated outside this repository, so this gate can only observe it - it is merged now so the finding is visible and tracked, and takes --strict once the generator emits the tags.