Google “Read More” Deep Links: Preserve Section Anchors and Hash Fragments
Keep target answers visible, preserve hash fragments, and stop page-load scripts from overriding section anchors used by readers and Google snippets.
Published August 9, 2026: Google documents “Read more” deep links as snippet links that take a searcher directly to a specific section of a page. Its best practices focus on a simple promise: the linked answer should be immediately visible, and page-load JavaScript must not break the hash-fragment destination.
This is not a new schema type or a guaranteed Search feature. It is a reason to make section anchors reliable for every visitor. A robust implementation improves table-of-contents links, shared citations, browser navigation, accessibility, and any search result that chooses to link into the page.
What Google recommends
Google says the target content should be immediately visible to a human rather than hidden behind an expandable section or tab. It advises against JavaScript that forces the scroll position to the top on page load. If code changes browser history or window.location.hash, it must preserve the fragment that identifies the destination.
These actions increase the likelihood of deep-link behavior; they do not guarantee that Google will show a “Read more” link. The page still needs useful sections, crawlable content, stable URLs, and a snippet that Google considers appropriate.
Build stable section anchors
Give each meaningful heading a unique, human-readable ID such as id="measure-the-funnel". Keep it stable when copy changes, because external links, citations, browser bookmarks, and table-of-contents entries may depend on it. Avoid IDs generated from a transient database number or from the current order of sections.
The target should exist in the server-delivered or reliably rendered content and should not require a click to reveal the main answer. Sticky headers can cover a correctly targeted heading, so apply an appropriate scroll-margin-top to anchored sections.
| Test | Expected result | Common failure |
|---|---|---|
| Paste full URL with hash | Target answer is visible | Script scrolls to top |
| Open in new tab | Fragment remains in address bar | Router removes hash |
| Back and Forward | Browser returns to the section | History state is replaced |
| Mobile sticky header | Heading is not covered | Target lands under navigation |
| Consent variants | Same destination in every state | Late banner or ad shifts layout |
Audit JavaScript and layout shift
Search the application for scrollTo, scrollIntoView, pushState, replaceState, and assignments to location.hash. Check routers, analytics snippets, consent tools, personalization, ad code, and third-party embeds. The bug may appear only after hydration or after a late component changes page height.
Run the full hash URL with JavaScript enabled and disabled. Throttle the network, test a cold cache, and observe the page through the point at which fonts, images, ads, and embeds finish loading. A target that appears correctly for one second and then jumps away still fails the reader.
Do not confuse this with back button hijacking. Both involve browser history, but one can be an accidental deep-link bug while the other is deceptive navigation manipulation. Test and classify the observed behavior before assigning intent.
Make anchors part of editorial QA
- Choose section headings that state the reader’s question or task.
- Add stable IDs and update the table of contents.
- Link to important answers from related articles using the fragment.
- Test direct load, reload, Back, Forward, and copy-link behavior.
- Verify mobile, consent, ad, and logged-in states.
- Preserve IDs when revising the article; redirect or alias them when a section is retired.
The citation-ready passage test complements this work: the anchor makes a section reachable, while the passage makes the answer understandable outside the rest of the article.
Ask a question or join the discussion