Skip to content
Sulayman Bowles / Project Delta

Google Read More Deep Links Need Stable Sections

Google can link a snippet directly to a section. The page must preserve that section as a real, visible destination instead of rewriting the fragment on load.

A Google read more deep links guide covering visible sections, fragment IDs, JavaScript scroll behavior, history changes, static HTML, and testing.

01 / Contract

The result targets a section, not a second page

Google defines a read more deep link as a link inside a Search snippet that leads to a specific section of the page. The destination is normally represented by the canonical page URL plus a fragment such as #validation. The section remains part of the same document and should have meaning when a user lands there without reading the preceding paragraphs.

Google describes best practices that increase likelihood, not an eligibility guarantee. A well-built anchor can improve direct navigation for people and still never receive the result treatment. Treat the feature as a progressive benefit of good document structure rather than a promised rich result.

02 / Visibility

Keep the destination immediately visible

Google advises that the destination content be immediately visible rather than hidden behind a collapsed disclosure, tab, modal, or interaction. A heading and its answer should exist in the document flow when the URL loads. If a disclosure is necessary for usability, consider whether the fragment can target a visible overview that links to the optional detail.

Do not render the section only after scrolling, clicking, or resolving a client API. The built HTML should contain the heading, identifier, and substantive text. This helps users, crawlers that do not execute JavaScript, and browsers restoring a fragment before the application finishes.

Figure 01 / section-anchor contractA durable anchor coordinates URL, document, application, and accessibility behavior.
LayerRequired stateFailure
URLStable encoded fragmentRewritten or removed hash
HTMLUnique matching idMissing or duplicate target
VisibilitySection immediately shownCollapsed or delayed content
ScrollBrowser lands at targetForced scroll to top
FocusContext remains understandableDisorienting handoff

03 / JavaScript

Do not erase the fragment during application startup

Google explicitly warns against forcing scroll position to the top on load and against History API or hash changes that remove the incoming fragment. Common SPA initialization code normalizes the URL, restores a saved position, or calls scrollTo(0, 0) before route state settles. Those behaviors can break the destination even though the section identifier is correct.

Test a cold navigation to the full fragment URL, a reload, back and forward navigation, and a client-side transition from another route. Preserve the canonical document URL without treating fragments as separate indexable pages. The fragment is a navigation state; it generally does not belong in the canonical element.

04 / Layout

Account for sticky headers and readable context

Use scroll-margin-top on target headings when a sticky masthead would cover them. Give identifiers stable semantic names rather than array indexes that change during edits. Avoid reusing an ID and preserve backward-compatible anchors when headings are renamed if external links may already exist.

The destination should expose the heading, the direct answer, and enough boundary text to avoid a misleading excerpt. A fragment that lands in the middle of an unexplained table or code block may technically work and still be a poor result. Design the section as a coherent entry point.

05 / Validation

Validate the anchor, then measure ordinary Search behavior

Crawl the route inventory and fail on duplicate section IDs, missing fragment targets, hidden destinations, or scripts that remove the hash. Browser-test representative URLs at desktop, mobile, 200% zoom, JavaScript disabled, and with reduced motion. Confirm the title, canonical, section heading, focus order, and final URL.

Search Console does not provide a guaranteed standalone report for every read more deep link. Annotate the implementation date and observe page clicks, impressions, queries, and user behavior without claiming that a traffic change came from the feature. Manual examples can confirm appearance, but they remain sampled and volatile.

Continue through the evidence systemThe article links to narrower Project Delta references for implementation detail and claim boundaries.
  1. 01
    React SEO Without a Server-Side Rendering Migration

    A React SEO without SSR guide using build-time HTML, crawlable routing, metadata, status handling, hydration, and rendered-page verification.

  2. 02
    JavaScript Rendering Audit Checklist

    A JavaScript rendering audit checklist comparing raw HTML, rendered DOM, status codes, metadata, links, visible content, failures, and crawler-safe fallbacks.

  3. 03
    Build Extractable Answer Passages Without Flattening the Page

    Extractable answer passages organize direct definitions, scoped explanations, evidence, and caveats so readers and retrieval systems can interpret a page.

Primary referencesOfficial and standards sources that bound the article’s claims, with the public review date preserved.
  1. 01
    Google: Snippets and read more deep links

    The definition of read more deep links and Google’s guidance on visible content, scroll control, History API use, and fragment preservation.

    Checked 2026-07-20
  2. 02
    Google: JavaScript SEO basics

    Crawlable link, History API, rendered-content, canonical, and initial HTML guidance for JavaScript applications.

    Checked 2026-07-20
  3. 03
    HTML Standard: Navigating to a fragment

    The browser navigation model for matching URL fragments to document elements and scrolling the destination into view.

    Checked 2026-07-20