If you have a long article that people scroll through looking for one section, a table of contents with jump links is a small fix that helps a lot. This guide is for marketing leads and content owners who publish long posts and want to add one without installing a plugin. By the end you'll have a working list of jump links near the top of your article, each one landing on the right section, and a clear idea of what a table of contents can and can't do for SEO.
You need one long article you can edit, access to your editor's HTML or anchor settings, and about thirty minutes for the first one. The steps below work the same way whether your posts live in a CMS, a static site, or a plain HTML file.
What a table of contents and jump links actually are
A table of contents is a list of links to the sections of the same document. It lets a reader see what the article covers and go straight to the part they came for. It is not a site menu or a sitemap, and it only points inside the one page.
A jump link, which some people call an anchor link or a fragment link (you'll see "anchor links blog" searches for exactly this), is a regular hyperlink that points to a spot on the same page. The address ends in # followed by a name. After the page loads, the browser looks for the element with that name and scrolls to it. The part after the # is handled by the browser, so it isn't sent to the server as part of the page request. If you've wondered how anchor links on a blog post fit into table of contents SEO, the short version is that they're a navigation tool first, and we'll get to the search side in the last step.
The destination is any element that carries an id. So the whole mechanism is two pieces that have to match exactly: a link with href="#some-name" and an element with id="some-name". The words a reader sees on the link don't have to match the ID at all. A link can say "Calculate your budget" and point to #calculate-budget, and that works fine.
Here's the smallest working version, so you can see all the parts at once.
<p>On this page</p>
<ul>
<li><a href="#estimate-costs">Estimate your costs</a></li>
<li><a href="#compare-options">Compare your options</a></li>
<li><a href="#choose-a-plan">Choose a plan</a></li>
</ul>
<h2 id="estimate-costs">Estimate your costs</h2>
<p>Section content...</p>
<h2 id="compare-options">Compare your options</h2>
<p>Section content...</p>
<h2 id="choose-a-plan">Choose a plan</h2>
<p>Section content...</p>
That example only shows how the links connect. It isn't a lesson on which heading levels to pick, which is a separate topic that we cover in our piece on semantic HTML and heading hierarchy.
Choose the sections readers need to jump to
Start with the finished article, or one that's close to finished, and read it the way a visitor with one question would. Write down the sections that answer a separate question or belong to a different stage of the task. Keep them in the order they appear on the page.
Put the table of contents near the start, right after the opening paragraphs, so readers see it before they've scrolled through everything. A short label such as "On this page" or "Contents" above the list is enough.
Use names a reader could understand without the rest of the article around them. "Estimate your costs" tells someone what they'll find. "Section 1" and "More" don't. You can include subsections when they're really useful, but you don't have to list every small heading. Some articles need six entries and some need twelve, and nobody has published a rule for the right number or for how long an article has to be before it earns one. So let the reader's need decide, not a number.
You'll know this step is done when someone can scan your list and guess where each answer is without opening any of the sections.
The most common way this goes wrong is copying every minor heading into a long list, or using labels so general that two entries look the same. If you find yourself with a list that runs longer than the first screen of the article, cut it back to the sections people would actually jump to.
Good long-form content navigation starts with a good structure, so it helps to start from a draft that already has clear sections. DeepSmith's Content Studio produces a brand-grounded article with research, internal and external links, and publish-ready metadata, so you'd be choosing your destinations from a nearly finished piece instead of building the structure first. Picking the entries and matching the fragments is still an editorial check that you do yourself.
Give each section a unique, stable ID
Now give every destination on your list an ID. Keep each one short and descriptive, and make it something you could type from memory. A common habit is lowercase words separated by hyphens, like estimate-costs. That's only a convention, though. It has no special SEO meaning, and it just makes IDs easy to read and reuse.
How you enter the ID depends on your editor. Many editors have an "anchor" or "HTML ID" setting on a heading block. If yours does, type the ID without the #. If you edit HTML directly, add the id attribute to the heading, as in the example above. If you publish from Markdown, be careful here. Some systems add IDs to headings automatically, but they don't all do it the same way, and they handle two headings with the same text differently. So don't guess what the ID will be. Look at the rendered page and check. If your system keeps raw HTML in Markdown, writing the heading with an explicit id is the safer route.
It helps to keep a simple list with three columns: the label in the table of contents, the ID, and the section it points to. It's easy to lose track of these once you have ten or more.
You'll know you're done when each destination has exactly one ID and no ID shows up twice anywhere on the page. The HTML rules say an ID must be unique in the document and can't contain spaces. Choosing plain lowercase letters and hyphens also means you won't need special handling when someone styles the page with CSS or scripts it.
Here are the usual ways people go wrong at this step:
- Reusing an ID on two sections.
- Adding a space inside the ID.
- Typing the
#into the ID field, so the ID becomes#estimate-costsand the link never finds it. - Changing an ID later without changing the links that point to it.
That last one matters more than it seems. Once somebody has shared a link that ends in #estimate-costs, that link is a direct route to your section. If you rename the ID, the link still opens the page but no longer lands on the section.
Build the table of contents with real links
Next, write the list itself near the top of the article. Each item needs to be a real hyperlink, and the href should be # followed by the exact ID of its section. So href="#estimate-costs" points to id="estimate-costs". Keep the visible text short and specific to where it leads.
You don't need a plugin or any JavaScript for this, and you don't need schema markup either, though you can add schema markup without a developer if you want it for other reasons. A normal link with a matching ID is all the browser needs. If your editor lets you add links to text, you can type the list, select each entry, and set its link to the fragment. If your editor has an HTML view, you can paste the list from the example.
This is also a place where the basics of crawlable links apply. Google recommends normal <a> links with an href, and it recommends anchor text that actually describes where the link goes. That's good practice for readers and for crawlers, but it isn't a promise that Google will show your table of contents entries anywhere in search results.
You'll know this step is done when the rendered table of contents shows separate, clickable links, and every fragment matches an ID that exists in the article.
Where people go wrong is usually one of these: typing the list as plain text with no links, adding links with no href, using labels like "click here," pointing every entry at the same section, or linking to a different article by accident when they meant a section of this one. An ordinary internal link to another page and a jump link within the page look similar in an editor, so check the address of each one.
Common mistake: A label that says "Compare your options" won't fix a mismatched destination. If the link ends in
#compare-options, the heading needs the IDcompare-options. The visible words and the ID can be different, but the part after the#and the ID have to be exactly the same.
Preview the page and click every link
If you have an editing checklist for drafts, add the jump-link click test to it. Before you publish, open the preview and click each entry in the table of contents. Watch the address bar. When a jump link works, the address gains the fragment you chose, and the page scrolls to the section. Then copy one of those addresses, open it in a fresh tab, and check that you land on the section without touching the table of contents. That's how a reader who got your link from a message or a bookmark would arrive.
Check the published version as well. An editor preview doesn't always behave the same way as the live page, and some editors clean up or rewrite markup when a post goes out. If your custom IDs disappear on publish, fix the published output and test again. Don't assume the anchor control in one CMS exists, or works the same, in another one.
If you use DeepSmith, this is a good moment to use the review step. The Produced Content area lets you preview the live article and edit the body and metadata before you publish it, so you can click through your jump links there and fix any that are off. DeepSmith doesn't build the table of contents or assign anchor IDs for you, so the matching stays your job. The review step is just a convenient place to do it.
You'll know you're done when every entry lands on its named section, both in the preview and on the live page, and a direct fragment link works in a new tab.
The mistakes here are easy to make. People assume a link works because it looks blue in the editor. They rely on IDs that a system generated automatically without looking at the published output. Or they test only the first entry and trust the rest. Click all of them, including the last one.
Keep the destination visible under a sticky header
A lot of sites have a header that stays fixed at the top of the screen as you scroll. When a jump link scrolls to a heading, that header can sit right on top of it, so the reader lands on the right spot and sees nothing. It's a very common surprise, and it usually shows up only after you've published.
Test on a desktop screen and on a phone, because a narrow screen often has a taller header. If you can edit your site's CSS, the scroll-margin-top property leaves some space above a targeted element when the browser scrolls to it. Here's an example.
article [id] {
scroll-margin-top: 5rem;
}
The 5rem value is only an example. Your header might be shorter or taller, so change the number to fit your actual header and check the result on the live page. If you can't edit CSS in your setup, write down what you saw, such as which pages and which screen sizes, and pass it to whoever manages the site template. It's better to hand over a clear note than to promise that a plugin-free fix exists in every editor.
You'll know it's done when, after each jump, the section's heading is visible and not hidden behind the header, including on a narrow screen.
The usual slip is testing only on a wide desktop preview, or using a fixed offset without looking at the real header. Also be careful about copying browser-support warnings from an old article. Check the current situation for your own audience rather than repeating them.
Test with the keyboard and keep the links current
Some readers move around a page with the Tab key and Enter instead of a mouse. Try it yourself. Tab through the table of contents, press Enter on a few entries, and confirm that the section comes into view and that you can keep going from there. Read the link labels one at a time without the surrounding text, too, and see whether each one still makes sense on its own.
The reason a table of contents is often recommended for accessibility is a practical one. It gives people an overview of the page and lets them go straight to a section. That's useful, but adding one doesn't make a whole page accessible, so don't describe it that way in your notes or reports.
After the first version is live, the work is keeping it right. If you already audit your internal links now and then, you can check the jump links in the same pass. Whenever you edit the article, treat the table of contents as part of the edit. If you merge two sections, remove one, or rename one, update the list at the same time. If a heading's wording changes but the section is the same section, keep its old ID so that older shared links still work. Our content refresh checklist is a good place to add a line for this, so it gets checked each time you update a post.
You'll know you're done when every entry works without a mouse, no link points to a missing section, and the list matches what's actually on the published page.
People go wrong here by treating a mouse click as the only test, or by deleting a section and leaving both its table of contents entry and any shared link pointing at nothing.
Publish, then set the right expectations for search
Once the article is live, confirm that the public page still shows the table of contents and that the destinations still exist. If the page is indexed, look at how it appears in search results from time to time, and see whether Google chooses to show any links into your sections. Whatever you see, judge the change mostly by whether readers can get around the article more easily.
Now for the SEO part, because this is where a lot of advice on table of contents SEO goes further than the evidence. Years ago, Google's Search Central blog described extra links under a result that jump to sections of a long page, and it suggested using descriptive named anchors plus a table of contents that links to them. That's useful history, and it's a good reason to write clear labels. Google's current documentation on sitelinks is about something a bit different. It describes sitelinks as links its systems choose automatically to show under a result, and it says they appear when the systems decide they're useful. A site owner can't switch them on.
So the honest way to think about it is this. A table of contents makes a long page easier to use right away, even if Google never shows a section link in search. It gives search systems clear, explicit links to the sections of your page, which can only help them understand it. It isn't a switch for a special search result, and nobody has published a measured lift in rankings, click-through, or time on page from adding one. It also isn't a guarantee of featured snippets or AI citations. Keep the labels descriptive and written for people, and don't repeat keywords in them to try to get a search benefit.
If you're already working on how your pages get read by AI answer engines, this connects with the rest of your page structure. Clear sections and answer-first writing help there, and we go into that in our piece on answer-first content. Our guide to formatting for extraction covers the layout side. A table of contents fits with those habits, but it doesn't replace them.
You'll know you're done when the live page works, and everyone on your team understands that a table of contents is a navigation improvement and not a way to force a search feature.
The trap at this step is promising sitelinks as if they were an automatic result, mixing up sitelinks to other pages on your site with jumps inside one article, or calling the project a failure because Google didn't show anything special for one query. A better measure is whether a reader who wanted one section got there in a couple of seconds.
What to do next
Pick one existing long article, ideally one that already gets some visits, and add a short table of contents to it this week. List the sections people are most likely to want, add the IDs, link them, and click through every entry on the live page. Once you've done it for one article, you'll have a routine that takes much less time for the next one, and you can slowly work through your other long posts, starting with the ones people already read most.
If your bigger goal is to publish more long articles without adding to the manual work around each one, you can try DeepSmith free for seven days and see the researched, brand-grounded articles that arrive ready for you to review before you add your navigation.
