Table of Contents SEO: Jump Links in Long Articles

A table of contents is the short list of links at the top of a long article that lets a reader jump straight to the section they need. It is one of the easiest interface elements to add and one of the easiest to get subtly wrong. The useful question is not whether it looks organised, but who it serves: the reader skimming for one answer, the person navigating with a keyboard, and the search engine that parses your links and headings. A table of contents is not a ranking lever. Built well, it speeds up navigation; built badly, it hides content, collides with sticky headers and pushes the first paragraph below the fold.

This guide is written for blog editors who decide when a long piece needs one and for front-end developers who build the component. It starts with the editorial question of when a table of contents earns its place. It then separates what a fragment link actually does in the browser from what Google's documentation says about section links in search snippets, including what that documentation leaves out. After that it covers heading structure, keyboard and skip-link behaviour, sticky-header collisions, scroll animation, mobile layout and measurement. No search volume or competitor data is quoted.

When a table of contents is useful

Start with the reader rather than the template. A table of contents answers the question "what is in here, and where?" For some articles that question never comes up, and for others it is the first thing a returning visitor needs.

Reference pieces versus narrative pieces

Think of a configuration guide that a developer opens three times in one week, each time to reread a different step. That reader is not reading from top to bottom; they are navigating. A list of section links turns the page into a lookup tool. Compare that with an essay or an interview, where each section depends on the one before it. Jumping into the middle makes little sense there, and a prominent list of links invites exactly the skimming the author does not want.

There is no official word-count threshold. Google does not publish one. A workable editorial rule is to look at the number of H2 sections and the scroll length together. If the headings all fit on one screen, the list adds nothing. If a reader needs several screens to see every heading, the list becomes a map. Treat that as an editorial rule of thumb, not a documented requirement. For wider formatting decisions around the same pages, see the readable content formatting guide.

Questions to ask before adding one

• Will a meaningful share of readers come back to this page for a single section?
• Are the headings distinct enough that a one-line label tells the reader what they will find?
• Can the list stay short, ideally limited to second-level headings?
• Will the list sit below the introduction so the page still opens with the article rather than with navigation?

If most answers are no, skip it. A page that is easy to read from top to bottom does not need a shortcut.

This table is an editorial judgement, not something a search engine publishes. A fictional example makes the trade-off concrete. Imagine a documentation team that publishes a long setup guide and, a month later, notices from their own analytics that support tickets keep asking about the same middle step. Adding a short section list at the top gives that step a visible entry point. The example carries no figures and no real site; it only illustrates how a navigation aid serves a returning reader.

Fragment links and in-SERP jump-to links

Every table of contents rests on fragment links. Before worrying about search results, it helps to understand what the browser does with them, and then to be precise about the two different Google documents people tend to blur together: one about crawlable links, one about section links inside snippets.

What the browser does with a fragment

According to MDN's reference on the URL fragment (Opens in a new tab), the fragment is the final part of an address, introduced by the hash sign. It is not sent to the server; the browser handles it after the resource arrives. In an HTML document the browser scrolls to the element whose id attribute matches the fragment, so an address ending in #setup brings the element with the id setup into view. The practical rule follows directly: every entry in the list must point to an id that exists exactly once on the page.

The reference does not say what happens when nothing matches. Many browsers simply stay where they are without warning anyone, but that is general observation rather than something the page states, so treat it as behaviour to test. Silent failure is the reason broken section links survive for months. The remedy is a pre-publication check that confirms every link in the list has a matching target.

Crawlable links and fragments

Google's documentation on crawlable links (Opens in a new tab) states that Google can only crawl a link that is an anchor element with an href attribute. Links driven by onclick handlers or javascript: addresses appear in its list of approaches that are not recommended, though the page notes Google may still try to resolve them. It also describes good anchor text as descriptive, reasonably concise and relevant to both the page it sits on and the page it points to. The page does not discuss fragment identifiers, so it should not be used to claim anything about how fragments are treated in search. What you can take from it is a build rule: render the list as real links with real href values, not as buttons that run a script and scroll the window.

What Google says about section links in snippets

Search results sometimes include a link that takes the user to a specific part of a page. Google's snippet documentation (Opens in a new tab) calls this a "Read more" deep link, describing it as a link within a snippet that leads users to a specific section on that page. It lists three practices that increase the likelihood of such links:

1. Make sure the content is immediately visible to a human, and not hidden behind an expandable section or a tabbed interface.
2. Avoid using JavaScript to control the user's scroll position on page load.
3. If the history API or hash changes happen on page load, do not remove the hash fragment from the URL, because that breaks deep linking behaviour.

Two things are absent from that page. It does not say that adding a table of contents produces these links, and it does not say that a site owner can choose where they appear. The wording is about raising the likelihood, and the decision stays with Google. A sentence such as "add a table of contents and Google will show jump links" is therefore a claim beyond the evidence. The defensible version is smaller: a table of contents helps people move around, and the three practices above avoid breaking a feature you cannot control.

Where deep links typically break

Reading the three practices as a template review gives a concrete checklist. Content wrapped in accordions or tabs may not be visible when the page loads. Scripts that reposition the viewport on load can override the browser's own jump to the fragment. Single-page routing code can strip everything after the hash. And a fixed bar or cookie notice can sit on top of the target. The last of these is not in the snippet documentation, but it matters to readers and returns in the accessibility section below.

A side benefit that has nothing to do with search

Because a fragment address identifies a section, it is also a shareable pointer. A colleague who wants to send a client to the fourth section can append the id and send the link. Some templates add a small link icon beside each heading to make that easy. It is a convenience for people, not a ranking tactic.

Alignment with the heading hierarchy

A table of contents is a mirror of the headings. If the headings are inconsistent, the list will be inconsistent in the same way, only more visibly. The principles for building the outline itself are covered in the guide to heading structure for SEO and accessibility; the points below concern only where the list and the headings meet.

Generate the list from the real headings

A hand-written list drifts. An editor renames a heading, and the list keeps the old wording. The more robust approach is to build the list from the headings in the published body: collect each second-level heading, optionally each third-level heading, and create one link per heading. That requires each heading to carry an id. When an author has not supplied one, the template can derive it from the heading text, but derived ids need care. Accented characters, spaces and punctuation should be normalised, and two headings with identical wording must receive different ids, otherwise two links lead to the same place.

Keep the ids stable

Once an article is live, its ids can turn into external references. A reader shares a link, another writer cites a section. If the template regenerates ids from the heading text every time it renders, fixing a typo in a heading silently breaks every link that used the old id. Decide on a policy and write it down: either store the id when the heading is first created and never regenerate it, or keep a small record of previous ids that still resolve. Either way, a heading edit should not change the address of the section.

On a bilingual site the ids can differ between language versions, because each version is a separate page with its own headings. There is no requirement to share ids across languages. If a language switcher is supposed to land on the matching section, you need a mapping; otherwise sending the reader to the top of the translated page is simpler and honest.

Which levels to include

For most articles, second-level headings are enough. Adding third-level headings turns a quick map into a wall of text. For a very long reference page, a nested list can make sense, but set a ceiling: if the list takes up more than about a third of the first screen, trim it. That limit is a design suggestion, not a documented threshold. Skipping levels, such as moving from a second-level heading directly to a fourth-level one, produces odd indentation in the list and an unclear outline for screen-reader users.

Labels that make sense out of context

List entries are read out of context, so the heading text has to carry meaning by itself. "Introduction" or "More" says little. "Why the target scrolls under the sticky header" tells the reader exactly what the section covers. This also matches Google's description of good link text: descriptive, concise and relevant. There is no need to repeat a keyword in each heading; clear wording serves readers and search better than forced phrases. When deciding how many sections an article really needs, the discussion in ideal word count for SEO content is a useful companion.

Accessibility: keyboard and skip links

A table of contents is navigation, so it has to work for people who do not use a mouse. The W3C's Understanding documents for WCAG 2.2 connect several success criteria to this component. Each statement below is based on the page named in the link.

Bypass mechanisms

The Understanding document for Bypass Blocks (Opens in a new tab) covers success criterion 2.4.1, level A: a mechanism must exist to bypass blocks of content that repeat across pages. Among the sufficient techniques it lists a link at the top of the page to the main content (G1) and links at the top of the page to each content area (G124). It also lists headings at the start of each section (H69). The document adds that most browsers offer keyboard shortcuts to move focus to the top of the page, so a skip link can be redundant in some layouts.

An in-article list of section links resembles the G124 idea at the scale of one article. That is an interpretation, because the document does not name an article-level table of contents as a technique. The site-wide skip link to the main content belongs in the page template, separate from the article component. A keyboard user who can skip the header and then jump between sections has a much shorter path through the page.

Markup that machines and people can use

Wrapping the list in a navigation landmark with a short accessible name, for instance "On this page", helps screen-reader users locate it. The Understanding document treats grouping related links in a nav element as an advisory technique. Building the list as a real list is also sensible, since many screen readers announce how many items a list holds; that last point is general practice rather than something the cited page states. Give the component a visible heading so sighted users know what it is.

Focus and sticky headers

Following a link from the list moves the viewport to the target heading. If the site has a fixed header, the heading can end up underneath it. The Understanding document for Focus Not Obscured (Minimum) (Opens in a new tab), criterion 2.4.11 at level AA, requires that a focused component is not entirely hidden by author-created content. It names sticky headers, sticky footers and non-modal dialogs as common causes, and lists CSS scroll-padding as a sufficient technique (C43) that keeps focused content clear of fixed bars.

The document discusses focus, not fragment targets. Whether the same offset behaves identically for a jump to a heading is something to verify in a real browser on your own pages. If the header is the problem, a second approach is to make it smaller or non-sticky on article pages.

Smooth scrolling and reduced motion

Animated scrolling after a click feels polished, but it is motion. MDN's scroll-behavior documentation (Opens in a new tab) explains that the smooth value animates scrolling triggered by navigation, the default is auto, which scrolls instantly, and user agents are allowed to ignore the property. Its example shows that clicking an in-page link animates the scroll when the property is set.

For people sensitive to motion, WCAG's Animation from Interactions (Opens in a new tab) criterion, 2.3.3 at level AAA, asks that motion animation triggered by interaction can be disabled unless it is essential. The page names parallax scrolling as a typical source of vestibular reactions and lists the prefers-reduced-motion media query as a sufficient technique (C39). Level AAA is outside the usual AA target, so this is not mandatory for most projects, but honouring the preference costs little when you add smooth scrolling.

Touch target size

On a phone, each entry is a thumb target. Success criterion 2.5.8 in the Target Size (Minimum) document (Opens in a new tab), level AA, asks for pointer targets of at least 24 by 24 CSS pixels, with exceptions for spacing, an equivalent control, inline targets within a sentence, user-agent controls and essential presentation. It states the requirement is independent of zoom. Inline links inside a paragraph are exempt, but a stacked list of links is not an inline case, so give rows enough vertical padding rather than relying on an exception.

A five-minute keyboard test

1. Put the mouse aside and tab from the top of the page until you reach the list.
2. Check that every entry shows a visible focus indicator.
3. Press Enter on a few entries and confirm the heading is not hidden by a fixed bar.
4. Press Tab once more and note where focus goes after the jump.
5. Switch on the operating system option to reduce motion and confirm the animation stops.

Mobile layout and measurement

On a wide screen a section list can sit in a sidebar. On a phone there is no sidebar, and a long list pushes the opening paragraph far down. Everything in this section about layout is design practice, not a documented requirement.

Layout options compared

A note on collapsing. Google's snippet documentation advises against hiding content behind expandable sections, in the context of content that should be visible for deep links. A section list is a navigation aid rather than the article itself, so a collapsed list does not collide head-on with that advice. Still, the article's own headings and paragraphs should never sit inside a collapsed component. That is an inference, since the page does not mention tables of contents.

Protect the first screen

On small screens, place the list after the title and the introduction, so the reader first learns what the article is about. When there are many sections, start the list collapsed behind a clearly labelled control such as "On this page". The control should be a real button, operable by keyboard, and should expose whether the list is open. Make sure opening and closing it does not shift the layout while the page loads, because sudden movement frustrates readers who have already started to read.

Think about length on small screens

If the list has become tall enough to feel like a chore, the article may be trying to do too much. Fewer, clearer sections are easier to navigate on any device, and some long pieces are better split into two articles. A list is a convenience; it does not replace a clear structure.

What to measure

Measuring ranking alone will mislead you, because Google's documentation makes no claim about a table of contents and ranking. Look at behaviour and technical health instead:

• Click-through on list entries, and which sections attract the most clicks.
• Scroll depth and time on page for visitors who use the list, compared with those who do not.
• Usage split between phone and desktop visitors.
• Layout shift and the time it takes for the opening content to appear.
• Search Console impressions and queries for the page before and after the change, read cautiously and without claiming cause.

Record the clicks as events, and respect the visitor's consent choices when you do. Change one thing at a time: add or remove the list while holding other template changes still, otherwise you cannot tell which change moved the numbers.

Fictional example: reading the click data

Fictional example: an editorial team adds a section list, limited to second-level headings and collapsed on phones, to a handful of long tutorials. After a few weeks they look at which entries are clicked most and notice that one mid-article section draws far more clicks than its position suggests. They conclude the section answers a common question and decide to mention it briefly in the introduction. The example contains no numbers and describes no real site; it shows how click data can inform an editorial decision rather than prove a search benefit.

Common mistakes

• Treating the list as a ranking tactic: Google's documentation does not say it improves rankings or guarantees section links.
• Using script-driven links: an onclick handler instead of a real href is the pattern Google lists as not recommended.
• Duplicate ids: two headings with the same id send two entries to one place.
• Regenerating ids on every edit: external links to a section quietly break.
• Ignoring the sticky header: the target heading lands under the bar and focus can be hidden.
• Hiding the article in tabs or accordions: this works against the practices Google lists for deep links.
• An oversized list: readers tire before reaching the first paragraph.
• Forcing smooth scroll on everyone: motion-sensitive visitors should be able to opt out.

Pre-publication checklist

1. Is the article long enough, and likely enough to be skimmed, to justify a list?
2. Is the list generated from the real second-level headings?
3. Is every entry an anchor element with an href?
4. Does every target id exist exactly once and stay stable when the heading text changes?
5. Do heading levels follow in order, with no jump from level two to level four?
6. Is the list inside a navigation landmark with a visible heading and real list markup?
7. Does the fixed header avoid covering the target, and is the scroll offset set?
8. Are rows large enough to tap, and is the focus indicator visible?
9. Does smooth scrolling respect the reduced-motion preference?
10. Is the article body free of collapsed or tabbed content?
11. Are clicks and layout shift being measured?

This checklist does not replace a full accessibility review. Its job is to catch the usual table-of-contents problems before a page goes live.

Frequently asked questions

Does a table of contents help SEO?

Google's documentation does not say that a table of contents improves rankings. It helps readers move around a long page, and built with real links it keeps those links crawlable. Any benefit is indirect and should not be promised as a result.

Will a table of contents produce jump-to links in search results?

There is no guarantee. Google's snippet documentation lists practices that increase the likelihood of section links: keep content immediately visible, avoid controlling scroll position with JavaScript on load, and keep the hash fragment in the URL. Whether a link appears is Google's decision.

What markup should the links use?

Use anchor elements with href values and give each target heading a unique id. Google states it can only crawl a link that is an anchor element with an href attribute, and it lists onclick and javascript: patterns as not recommended.

What if a sticky header covers the heading after the jump?

WCAG 2.2 criterion 2.4.11 asks that a focused component is not entirely hidden by author-created content, and CSS scroll-padding is a listed sufficient technique. Test the actual jump in a real browser to confirm the heading remains visible.

Is it acceptable to start the list collapsed on mobile?

Generally yes, since the list is navigation rather than the article. Do not place the article text itself inside a collapsed component, which can work against deep links. The toggle must be keyboard operable and announce its state.

Should I use smooth scrolling?

You can, as long as you honour the prefers-reduced-motion preference, which W3C lists as a sufficient technique in its animation criterion. Remember that user agents may ignore the scroll-behavior property.

Conclusion

A table of contents earns its place on long, reference-style articles that readers revisit, and it costs more than it gives on short or narrative pages. Its foundation is plain: real headings, stable ids and links that are genuine anchor elements. Around that foundation sit keyboard access, a sticky-header offset, respect for reduced motion and tap targets large enough for a thumb. On the search side, keep expectations modest. Google's documentation describes practices that raise the likelihood of section links in snippets; they do not promise them, and they do not claim a ranking effect.

If you would rather have long articles drafted with a clear structure and sourced claims, you can look at the SEO content writing service at Akua Adforce; scope and terms are described on the product page. The recommendations here are general technical guidance and do not guarantee any ranking, crawl or indexing outcome.