Historical correction (checked 2026-09-01): This post was first published in 2011 and described a WordPress plugin called jQuery Table of Contents. Today, I cannot verify a current listing under that exact name in the official WordPress.org Plugin Directory or its official plugin API search results. That does not prove the plugin never existed or tell us whether it was later renamed. The old download advice, theme selectors, and interface description should not be treated as a current installation guide. Do not obtain an old package from an untrusted mirror.

Table of Contents

Building a WordPress Table of Contents Today

A table of contents is fundamentally a list of links to heading anchors on the same page; it does not require jQuery. For a small number of important long posts, I now favor native WordPress Heading blocks, HTML anchors, and a List block. For site-wide automation, I would evaluate a currently maintained plugin or build a site-specific block. A TOC can aid navigation, but this guide makes no search-ranking promise.

What Remains of the 2011 Note

The old plugin asked for a “content selector” and the heading tags to collect. This site's theme at the time used #content .contenttext; the recorded plugin default was .single .entry, with h2 or h3 used for the TOC. These details remain only as historical evidence. The selectors depended entirely on that theme's DOM and could break when the theme or template changed. Turning every heading into a “back to top” link is also not a design to reproduce without review.

The original screenshots came from dead legacy URLs and showed an obsolete interface, so they are not republished here. There is insufficient evidence to describe the old plugin's present maintenance, security, or compatibility.

Get the Heading Structure Right First

A TOC cannot repair a confused document outline. The WordPress Heading block documentation advises using headings in order for readability and accessibility. Most templates output the post title as h1, so body sections normally begin with h2 and use h3 for subsections. Check the actual front end because themes and templates can differ.

Use the editor's Document Overview or Outline to check that:

headings express structure rather than merely making text larger;
the outline does not jump from h2 to h4 without a reason;
each heading describes its section instead of repeating labels such as “Notes”; and
translations retain the same hierarchy even when their wording changes.

Choose an Approach

Approach	Best fit	Main cost
Native HTML anchors and a List block	A few long posts needing precise control	The list must be updated when headings change
Experimental WordPress TOC block	The block exists on staging and future changes are acceptable	It is officially experimental and cannot be assumed on every site
Currently maintained TOC plugin	Many legacy posts need consistent automation	Ongoing review of updates, output, performance, and removal
Custom dynamic block or plugin	Special templates or strict engineering requirements	Development, testing, security maintenance, and migration work

For only a few long articles, the first route is usually the easiest to understand, back up, and migrate.

Route 1: Native Anchors and a List

Create Stable Anchors

Select a Heading block and expand Advanced in the settings sidebar.
Enter a stable HTML anchor such as install, configure, or verify.
Every anchor must be unique within the page. The WordPress Page Jumps guide also says anchors are case-sensitive, must begin with a letter, cannot contain spaces, and may use hyphens, underscores, colons, and periods.
Add a List block near the beginning and link every entry to its matching #anchor.

For example:

- [Installation](#install)
- [Configuration](#configure)
- [Verification](#verify)

For multilingual posts, language-neutral stable anchors can be useful—for example, retaining install in every translation. English is not mandatory; what matters is that each translated page's href matches an actual, unique id on that page.

Verify on the Front End

Preview the published template, not just the editor. Click every item, reload a URL containing #anchor, and test browser Back and Forward. If a sticky header covers the target, add a rule in a child theme or site styles and adjust it to the real header height:

.entry-content :is(h2, h3, h4)[id] {
  scroll-margin-top: 6rem;
}

Route 2: Treat the Core TOC Block Cautiously

The WordPress developer reference currently documents core/table-of-contents. It summarizes headings, adds HTML anchors, and is rendered dynamically on the server. However, the official reference explicitly labels the block experimental and says it may change or be removed without notice.

First confirm in the block inserter on staging that it is actually available. Then test the maximum heading level, ordered or unordered output, paginated content, existing anchors, and theme styling. If it is absent, do not paste experimental code from the web into production; use native anchors or assess a current plugin. Even when the block is available, keep a fallback plan for converting it to an ordinary list.

Route 3: Evaluate a Current TOC Plugin

Before Installation

Obtain candidates only through WordPress administration or the official WordPress.org Plugin Directory, not an old file host or mirror. Back up first and record the WordPress, PHP, theme, and related-plugin versions on staging. Installation count, rating, last-updated date, and compatibility claims can change, so recheck them on installation day rather than relying on this article's screenshots or rankings.

Acceptance Checklist

It scopes itself to the correct article content instead of relying on a hard-coded selector from an old theme.
It preserves existing heading IDs and creates stable, unique anchors for duplicate headings.
It handles h2/h3 hierarchy, Chinese and Japanese headings, repeated names, and paginated posts.
Its TOC remains understandable on narrow screens, by keyboard, and with common assistive technology; if it collapses, test focus and expanded state.
Basic anchor links work without JavaScript, and front-end assets load only where the TOC is needed.
It does not lock content into hard-to-remove shortcodes, private blocks, or hidden data.
It is tested with caching, deferred loading, minification, and the theme's sticky header.

Migrating from an Older Method

Inventory old shortcodes, blocks, post fields, automatic insertion locations, and custom CSS. Disable the old automatic insertion so two TOCs do not appear together. Sample long posts, short posts, posts without headings, and translations. Confirm that content and existing anchors remain intact after deactivation or removal before cleaning up old settings and styles. If a safe rollback is not possible, do not switch production yet.

Route 4: Minimum Requirements for Custom Development

Put a custom content feature in a plugin or site-specific plugin rather than binding it to a replaceable theme. Dynamic rendering can avoid saving generated TOC HTML permanently into every post, but the contract still needs to define post types and heading levels, preservation of existing IDs, suffixes for duplicates, cache invalidation after edits, pagination, and dynamic-block handling.

Following the WordPress Security APIs guide and Escaping Data guide, validate and sanitize settings and escape output as late as practical for its context. Do not rewrite arbitrary HTML with one simplistic regular expression, and do not change heading IDs already used by inbound links without a tested migration. I intentionally do not offer a “copy and paste” PHP snippet here: themes, blocks, and rendering pipelines differ, and an unintegrated example could damage content.

Common Failures

The TOC is empty: Confirm that the text uses Heading blocks, not large Paragraph blocks; then check the content scope and included levels.
The jump lands in the wrong place: Check duplicate IDs, letter case, cached markup, and whether a sticky header covers the target.
It works in the editor but not the front end: Isolate theme, cache/minification, and plugin conflicts on staging instead of disabling everything at once on production.
A translation jumps incorrectly: Match each translated page's TOC links to its actual anchors; do not assume automatic transliteration is stable.
Two TOCs appear: Check whether the theme, a block, and a plugin are all set to insert one automatically.

Pre-Publication Check

Click every TOC item on desktop and a narrow viewport, and directly open at least one URL with a fragment identifier.
Navigate the TOC by keyboard alone; for a collapsible TOC, also check the control's name, focus, and state.
Cover duplicate headings, non-Latin headings, posts without headings, paginated posts, and nested blocks.
Change one heading and confirm the intended behavior of the TOC, cache, and existing inbound anchors.
Pause the automatic TOC method, confirm the article remains readable, and document rollback.
Do not turn “navigable” into an SEO, traffic, or revenue guarantee.

Verification Scope and Uncertainty

On 2026-09-01, I checked WordPress.org documentation, developer references, the official Plugin Directory, and the official plugin API. The exact name “jQuery Table of Contents” did not appear in that API search result. This supports only the narrower conclusion that I cannot currently verify an official listing under that name; it does not establish the historical package's origin or final fate. The experimental core block and third-party plugins can also change after this review, so check the actual site again before deployment.

Historical Update: WordPress Tables of Contents Without the Old jQuery Plugin