Opens in a new tabSkip to content
Agent LighthouseAgent Lighthouse

    Searches the text of every published page. The evidence sources themselves are not in this index — search all of them on the trusted sources page.

    GitHub ↗
    Browse checks and page contents
    machine-discovery/feed-entry-identity-and-canonical-integrity

    Feed entries have stable identities that resolve to their canonical pages

    What it checks

    Validates that RSS/Atom entries carry stable, unique identifiers and that the URL each entry points at is the same URL the target page declares canonical — so an agent that cites a feed item cites a resolvable, non-deduplicated address.

    Why it matters

    RFC 4287 makes atom:id mandatory, exactly one per entry, ‘permanent, universally unique’ and unchanging ‘across different instantiations of the entry’; atom:updated is likewise mandatory and must mark the last significant modification. Ingestion pipelines dedupe and diff on these values. Falsifiable claim, in two parts. When ids are unstable — regenerated per build, or derived from a URL that includes tracking parameters — every poll re-emits the whole feed as new, and consumers either re-ingest duplicates or rate-limit the feed away.

    And when an entry’s <link> or atom:link href differs from the target page’s rel=canonical, an agent quoting the feed cites a URL that redirects or is consolidated away, which breaks attribution. Both are directly measurable without knowing anything about the consumer.

    Evidence

    • RFC 4287 — The Atom Syndication Format — IETF (spec, URL verified 2026-08-20)
    • Sec 4.1.2: atom:entry MUST contain exactly one atom:id and exactly one atom:updated. The id is a permanent, universally unique IRI that ‘must not change across different instantiations of the entry’. The updated time is the ‘most recent modification time that the publisher considers significant’. atom:entry MUST also contain atom:summary in two cases: when atom:content carries a src attribute, and is thus empty, and when content is Base64-encoded. MUST NOT contain more than one atom:summary.
    • Build and submit a sitemap — Google Search Central (vendor-doc, URL verified 2026-08-20)
    • Direct quote: ‘Google uses the <lastmod> value if it’s consistently and verifiably (for example by comparing to the last modification of the page) accurate.’ The value ‘should reflect the date and time of the last significant update to the page… an update to the copyright date is not [significant].’ priority and changefreq are ignored. The limit per sitemap file is 50MB uncompressed and 50,000 URLs.

    How it scores

    Tier per evidence policy: scored — grade B meets the A/B bar required for scored audits.

    Example failure

    A headless CMS emits <guid>https://example.com/blog/post?preview_id=8812</guid> and <link>https://example.com/blog/post?utm_source=rss</link> while the page declares rel=canonical https://example.com/blog/post. Every consumer stores the utm-tagged URL; an answer engine citing the article links to a URL that 301s, and analytics-driven URL rotation changes the guid on republish so the same article is ingested three times as three distinct documents.

    Sources