Google deep links into a section, and 55 of 245 headings had an id

What Google documents about a read more deep link

Two Google pages describe a searcher landing part way down a document, they describe it differently, and the difference is the whole problem for a site owner deciding whether any of this needs work.

The first is Google's snippet documentation, which carries Last updated 2026-04-20 UTC and holds a section headed best practices for read more deep links in Google Search. It defines the thing in one sentence: a read more deep link is a link within a snippet that leads users to a specific section on that page. It then gives three practices to increase the likelihood that such links appear. Make sure content is immediately visible on the page to a human, and not hidden behind an expandable section or tabbed interface. Avoid using JavaScript to control the user's scroll position on page load, and it gives forcing the scroll position to the top of the page as its example. And if you make history API calls or window.location.hash modifications on page load, do not remove the hash fragment from the URL, because that breaks deep linking behavior.

Read those three again and notice what is not among them. None of the three says to give the section an identifier. Two of the three are about not undoing something after the page loads, and the third is about whether the text is visible without a click. The hash fragment is named explicitly, which tells you the mechanism runs through the URL fragment, and the page stops there.

The second is Google's featured snippets documentation, which carries Last updated 2025-12-10 UTC and answers a related question in the opposite direction. Clicking a featured snippet, it says, takes the user directly to the section of the page that appeared in the featured snippet, and scrolling to that position happens automatically, without any additional annotation by the site. It also states the fallback: if a browser does not support the underlying technology, or if Google's systems cannot confidently determine exactly where within a page to direct a click, the click takes the user to the top of the source page.

So one Google page says the site needs no annotation, and another Google page says a hash fragment is load bearing. Both statements can be true of different features, and neither page says which mechanism a read more deep link uses. That is not a criticism of the documentation so much as a description of what a reader can and cannot conclude from it, and it is the reason the rest of this post counts what is on the pages rather than asserting what Google does with it. The reference page on getting cited by Google AI Overviews collects the controls that are documented in one place.

How many of 245 headings carried an id

The count was run on 21 August 2026 with htmlparser2, which is the parser this project already depends on, walking the stored raw.html of each of the five captures and recording, for every h1 to h6 element, whether it carried a non-empty id attribute and, if not, how many levels of markup separated it from the nearest ancestor that did. The five pages are astro.build, gymshark.com, the MDN reference page for HTML, webflow.com and the English Wikipedia article on web crawlers. A sixth capture in the same set, allbirds.com, is excluded throughout because it answered the baseline fetch with HTTP 429 and stores no usable document, which is the same exclusion the count of what JavaScript added to these pages made for the same reason.

The set holds 245 heading elements, which is the same total that earlier count of heading structure reported, and 55 of them carry an id of their own. That is 22.4 percent, and the average hides the shape completely, because the per page split runs from one extreme to the other. The Wikipedia article carries an id on 27 of its 28 headings. The MDN reference page carries one on 8 of 10. astro.build carries one on 18 of 31, and the split inside that page is itself informative: all 14 of its h3 elements have an id and 4 of its 16 h2 elements do. Then gymshark.com carries an id on 2 of 137 headings, and webflow.com carries one on 0 of 39.

The two ends of that range are two different kinds of document. The Wikipedia article and the MDN page are reference documents whose publishing systems generate a stable fragment for every section, because their own tables of contents are built out of those fragments. The two commercial homepages are assembled from design system components where a heading is a styled text node inside a section wrapper, and nothing in that pipeline has a reason to name it. Neither is a fault in itself. It becomes a fact worth knowing only once something outside the site starts pointing at sections rather than pages, which is what the Google documentation in the previous section describes.

One caveat on the total before the next section refines it. A heading with no id of its own is not automatically unreachable, because a fragment can resolve to any element, and a heading sitting inside a section that carries an id is still somewhere a link can land near. That is why the hero table has three columns rather than two, and why the next section measures the distance rather than reporting a binary. Our methodology page describes what a capture stores, and the earlier count of JSON-LD in the same five files describes the same corpus from a different angle.

How far the nearest identified ancestor sits, and what rendering changed

Of the 190 headings with no id of their own, only 7 have an identified ancestor within three levels of markup. For 157 of them the nearest one is between 4 and 15 levels up, and for 26 there is none anywhere between the heading and the root of the document. All 26 of those are on webflow.com.

Distance matters because a URL fragment scrolls the identified element into view, not the heading inside it. An id on the element two levels above a heading puts a reader at the top of the block containing that heading. An id fifteen levels above it, which is the maximum observed here, puts a reader at the top of a layout container that may hold most of the page, which is functionally the same as landing at the top. Counting those as reachable would be generous to the point of being wrong, so the honest reading of this set is that 55 headings out of 245 are addressed by something that names them, another 7 are close enough that the distinction is academic, and the remaining 183 are not.

Running the same count over the stored rendered DOM rather than the raw HTTP response changes the picture in one direction only, and only on one page. The rendered totals are 247 headings and 56 with an id, so JavaScript created two headings on gymshark.com and gave one of them an id. The interesting movement is on webflow.com, where the 26 headings with nothing identified above them fall to 7, because the client side code adds identifiers the server never sent. That page's rendered DOM carries 137 non-empty id attributes against 72 in the raw response, and 44 distinct id values exist only after JavaScript has run. A browser therefore sees a page with more anchors in it than the document does. A crawler that does not execute JavaScript sees the raw number, and the difference between what those two clients receive is exactly the gap prose parity exists to measure. It is the same shape as the finding that text delivered only inside a hydration payload scored the same as no text at all: the content is there for one class of client and absent for another.

The practical consequence for anyone building on a component framework is that ids generated during hydration are not ids in the document. If deep linking matters to you, the id has to be in the server response, which for most stacks is a template change rather than a script change. The React guide covers where that boundary sits on a client rendered stack, and the reasoning generalises to any framework that assembles the page after delivery.

Two ways a URL can point at part of a page

The gap between Google's two documentation pages is explained by there being two different mechanisms, and a site owner's exposure depends entirely on which one is in play.

The first is the document fragment, which has been in the web platform since the beginning. A URL ending in a hash and a name resolves to the element in that document carrying the matching id, and the browser scrolls it into view. MDN's page on text fragments states the limitation of that mechanism plainly while introducing the alternative: the issue with linking to specific document fragments is that the author of the linked page needs to put an anchor in place to actually link to, and not all documents have such anchors. That sentence is a fair description of 190 of the 245 headings counted above.

The second is the text fragment, which the same page describes as letting you link to a specific portion of text in a web page without requiring the page author to add an ID, and which it says lets you create deep links to content that you do not control and may not have IDs associated. Under that mechanism the URL carries the words to find rather than the name of an element, the client searches the rendered document for a match, and no cooperation from the site is needed at all. That is consistent with what Google's featured snippets page says about scrolling happening without any additional annotation by the site.

Nothing in Google's snippet documentation says which of the two a read more deep link uses. What it does say is that removing the hash fragment from the URL on page load breaks deep linking behavior, and both mechanisms live in the hash fragment, so that warning applies either way. What follows for a site owner is a decision under uncertainty rather than a fix: if your sections carry ids, both mechanisms can work; if they do not, you are relying entirely on the one that needs no cooperation, and no vendor page read for this post promises that one. Answer engines are a broader surface than Google Search, and answer engine optimisation as a discipline has the same problem in a harder form, because most engines document nothing at all about how a citation resolves to a position within a document.

23 empty ids, 59 duplicates, and 162 anchors that all resolved

Counting ids at all turned up three things about the set that are worth reporting separately from the heading question, because two of them are defects by the specification's own rule and the third is the opposite of a defect.

MDN's reference for the id attribute states that the attribute defines an identifier that must be unique within the entire document, and that its value must not contain ASCII whitespace characters. The five stored raw documents hold 2,174 id attributes between them. Of those, 23 are the empty string, and all 23 are on webflow.com. An empty id cannot be the target of a fragment and cannot be selected by an identifier, so it is an attribute that does nothing except exist, and in the rendered DOM the count of empty ids on that page rises to 29 with a further 4 appearing on gymshark.com.

Duplicates are the larger group. Twenty two non-empty id values appear more than once across the set, accounting for 59 extra copies. They cluster in three places and each cluster has a different cause. astro.build repeats three values ten times each, and all three are icon sprite identifiers of the form used by an icon library, which is a generated collision rather than an authoring mistake. gymshark.com repeats sixteen values twice each, and they are dropdown option identifiers built from a component instance key, so the same widget appears twice on the page. webflow.com repeats three values, one of them twelve times, one of them an SVG mask identifier five times. Wikipedia and MDN have none at all, which is what you would expect from documents whose fragments are part of the product. A duplicate id is not a rendering failure, but a fragment pointing at one of them reaches the first occurrence only, and the other copies are unreachable by definition.

The third finding runs the other way and deserves as much space. Across the same five documents there are 1,957 anchor elements, and 204 of them carry an href that is only a fragment, a figure that matches the earlier count of anchors and hrefs in this corpus exactly. Thirty four of those 204 are a bare hash with no target, which is the standard placeholder for a control that JavaScript will take over. The remaining 170 name a target, they resolve to 162 distinct names, and every single one of those 162 matches an element id present in the same document. Not one in page anchor on any of the five pages is broken. So this is not a story about sites shipping links to nowhere. It is a story about sites shipping addresses for the places they link to themselves, and no addresses for anything else. The same asymmetry showed up when alt text on 466 captured images was counted, and it is the general shape of markup that exists to serve the site's own features rather than an outside reader. If you build on a visual editor, the Framer guide covers where these attributes come from in that pipeline, and structured data is the other place the same components decide what a machine can see. The count of schema marks and dates in these captures found the same pattern in a different attribute set.

What this scanner does not read, and what to check yourself

The measurement above was written for this post with a standalone script. None of it happens during a scan, and the reason is worth stating precisely rather than in general terms, because a vague admission is the kind that quietly stops being true.

Lantad's HTML extractor is a single sink in core/src/extract.ts, driven by htmlparser2, and it reads exactly six attributes off the elements it walks: type, lang, name, content, rel and href. The word id does not appear anywhere in that file. So no part of a scan records whether a heading has an identifier, no sub-score moves when one is missing, no defect is raised, and no row in a report mentions it. A site could ship 39 headings with no address between them, as one of these five pages does, and take an A grade from us with nothing said. That is not a bug to be filed against the extractor either, because adding a signal means deciding what it is worth, and we would be pricing a behaviour that no vendor documentation we have read commits to. The honest position, taken elsewhere on the crawlers we model and the ones we do not, is to describe what is observable and refuse to score what is not.

What a reader can do without any tool is short, and it is the sort of check that takes ten minutes. Open your own page, view source rather than the inspector so you are looking at what the server sent, and search the source for the opening tag of a heading. If the ids you find in the inspector are absent from the source, they are being added during hydration and a crawler that does not run JavaScript never sees them. Then take one section you would want a search result to land on, construct the URL with the hash and that id, and load it in a new tab. If it lands at the top of the page, there is nothing there to land on. Our scan of what GPTBot sees will show you the crawler view of the document for the first half of that check even though it will say nothing about the second half.

Two limits on everything above, both of which matter more than the numbers. Five pages captured in one afternoon are a count and not a rate, and four of the five are homepages or reference pages rather than the article templates where a deep link would most likely appear, so nothing here estimates how common this is on the web. And no experiment in this post connects an id to a citation, a click or a ranking: it measures what is in the markup, against what Google's documentation says the markup does, and stops there. The studies we do have collected on retrieval and citation behaviour sit on the research page, and the per stack guides for Next.js and Shopify cover where server rendered markup is produced on those platforms. The related question of what a crawler that never scrolls or clicks can reach at all is covered in what happens to scroll loaded content.