AMP Easy Table of Contents - WordPress Plugin

AMP Easy Table of Contents Guide: How to Keep Easy Table of Contents on AMP Pages

AMP Easy Table of Contents is not intended to rebuild an article's table of contents from scratch. It is a compatibility add-on for an existing Easy Table of Contents setup: it helps the current heading list appear in the AMP version of the same post. That boundary defines how the plugin should be used. Most familiar settings belong to the core tool, while the add-on is responsible for AMP-compatible output.

This guide covers preparing a WordPress site, installing the plugin combination, selecting headings, placing the list, using the shortcode, working through a realistic long-form guide example, checking links and AMP validation, and diagnosing common failures. The goal is not to add another decorative page element, but to make a long post equally easy to navigate on its standard and AMP URLs.

A table of contents here means a list of links to actual sections within one article. It does not replace site navigation, create new content, or guarantee better search visibility. Its practical purpose is more modest: reduce scrolling, reveal the article's structure, and take visitors to the section they need without manual searching.

The reliable workflow is simple: first create a clean heading hierarchy, then get one correct table of contents on the standard page, then enable compatibility and compare the AMP version. This order matters more than any cosmetic setting. It shows exactly where a problem first appears.

What This Compatibility Add-On Solves in Long Articles

A long article usually presents two separate challenges. Readers may struggle to understand its structure quickly and jump to the chapter they need. In addition, the standard page and its AMP version may be processed under different rules, so a block that appears in the main template does not always carry over to AMP without extra compatibility support. Easy Table of Contents addresses the first issue: it reads the post's headings and builds a list of anchor links. AMP Easy Table of Contents addresses the second: it recognizes the existing table-of-contents configuration and makes it suitable for AMP output.

In practice, this is most visible in a knowledge-base article with several substantial chapters. A visitor opens the article, sees the list, selects the relevant item, and jumps to it. If the visitor lands on the AMP URL, they do not have to deal with a different, incomplete, or broken map of the content. For an editorial team, this means the structure is defined through headings and one set of core-plugin settings instead of being maintained manually in two separate templates.

This does not mean that every table of contents, regardless of where it comes from, automatically becomes AMP-compatible. The product page specifically describes integration with Easy Table of Contents. If the list is generated by a theme, a Gutenberg block, a page builder, or another plugin, review the documentation for that original mechanism first. Installing an extra module in the hope that it will fix someone else's output usually just creates duplicates.

Where AMP Easy Table of Contents Stops

The core Easy Table of Contents plugin controls the editorial decisions: which post types display the list, which heading levels to use, how many headings are needed before the block appears, whether to show hierarchy, whether to exclude individual items, and whether to insert the list automatically or through [ez-toc]. Its directory listing also describes a widget use case and several shortcode options. The AMP add-on does not replace these capabilities with an independent configuration system.

This division is useful when troubleshooting. If the table of contents is missing from both the standard and AMP versions, look at headings, post type, threshold, and the core insertion method. If the standard page is correct but the AMP page differs, narrow the investigation to the AMP tool, the add-on, component versions, cache, and template-specific behavior. Do not configure the same effect in two places at once: two generation points are more likely to produce two lists than a more reliable outcome.

Who This Plugin Combination Is Actually For

It is a good fit for a blog with detailed tutorials, a knowledge base, an industry publication, a solution catalog, or an editorial site where articles regularly use meaningful H2 and H3 headings. It makes particular sense when Easy Table of Contents is already in use and AMP pages remain part of the visitor journey. In that case, the module solves a specific gap between two versions of the same content.

It is less useful when the site does not generate AMP pages, posts are short and lack a developed structure, or the table of contents must be fully manual and unique for every article. Use caution when a page builder renders visible headings outside standard WordPress content. First make sure the core plugin can actually detect those headings on the published page, then test AMP.

A good table of contents reveals the architecture of the text. If it contains utility blocks, repeated words, and random labels, fix the article structure before changing the container background.

How It Works: From an Article Heading to an AMP Link

The plugin combination is easiest to understand as a four-step sequence. It starts with actual semantic headings in the article. Easy Table of Contents then selects allowed levels, creates entries, and connects them to anchors. WordPress next generates either the standard or AMP version of the post. On the AMP branch, the add-on helps the existing table of contents pass through compatible processing and preserve its navigation behavior.

This perspective clears up a common misconception that a table-of-contents link exists on its own. In reality, it depends on the heading, its final identifier, where the block is rendered, and the rules governing the page version. If a heading disappears, is duplicated, changes after caching, or is rendered outside the expected content area, visitors may see an empty list, an incorrect jump target, or two identical containers.

Input Data: Real H2, H3, and H4 Headings

A well-structured guide usually has one H1 as the page title, major H2 sections, supporting H3 sections, and occasional nested H4 headings. The plugin does not evaluate font size or infer the meaning of a line. A phrase styled only with bold text or color is not a structural element and may not appear in the table of contents.

Before enabling the list, open the editor and inspect the actual block levels. For every H2, ask: is this a distinct chapter a reader may want to jump to? For every H3, ask: does it explain the preceding H2 rather than repeat it? This quick review often delivers more value than dozens of appearance settings.

Selection Rules: Depth, Threshold, and Exclusions

After reading the content, the core plugin applies rules: which levels to include, how many headings are required, and what to exclude globally or in a specific post. The official directory shows shortcode settings for excluding text, selecting levels, and assigning a custom class to the container. These tools are not there for complexity's sake. They help ensure that the list contains only real navigation landmarks.

Do not use exclusions to hide a weak hierarchy. If you need to hide every second item, the article probably contains too many pseudo-headings. An exclusion is justified when a heading is needed to format an author block, contact area, advertisement, or utility card, but should not be part of the article route.

Output Methods: Automatic, Manual, and Widget-Based

Automatic insertion works well for similar content types: enable the appropriate post type, define the placement rule, and editors do not have to remember to add a list to every new post. The [ez-toc] shortcode is useful when the table of contents must appear after a specific introduction, before a series of steps, or inside a special template. The widget and sticky variants are theme-level use cases, so they require separate checks for selectors, narrow screens, and the AMP version.

For safe AMP use, choose one method. When using automatic insertion, do not add the same shortcode to the content. When placing it manually, disable automatic output for that use case. Two active insertion points do not improve compatibility; they create two independent candidates for AMP rendering.

The Observable Outcome

You can describe the correct outcome without technical jargon: both the standard and AMP URLs of the article contain one list with the same meaningful items, each link leads to the corresponding section, no second copy appears after an update, and the styling does not interfere with reading. Pixel-perfect matching across different templates is unnecessary. Comparable functionality is what matters.

Do not test only the first link. Click an item from the middle of the list, a nested item when using H3, and then open a shorter article of the same type. One test then covers level selection, the display threshold, and behavior across different content lengths.

What to Check Before Installation: AMP URL, List Source, and Rollback

Preparation does not require a full-site audit, but it can save hours of troubleshooting. You need a reliable test article, a clear way to open its AMP version, access to official component updates, and a minimal rollback point. When these conditions are in place, every change can be tied to an outcome rather than a guess.

Confirm the Actual AMP Setup

AMP on a WordPress site can use different modes and URL structures. The official AMP plugin documentation describes Standard, Transitional, and Reader modes, along with paired URLs. On one site, the AMP page may be a variation of the same theme; on another, it may be a separate rendering path. Do not guess the URL from someone else's example. Open a published page and identify the exact route used by the installed AMP tool.

For testing, choose a long published article with several real headings. It should not contain unfinished experiments, temporary blocks, or ambiguous page-builder rules. Before installation, note the current standard-page output. After activation, compare its AMP URL with the same content.

Find the Single Source of the Table of Contents

Review the plugin list, theme settings, and the editor for the test article. You need to determine whether the theme, an SEO plugin, a Gutenberg block, a page builder, or another link generator is building a table of contents at the same time. A page may show only one visible block while its markup already contains two mechanisms. Pay special attention to the single-post template: some themes create their own navigation that resembles Easy Table of Contents.

If another tool already generates the list, do not switch the entire site in one move. Create a test post, leave only one generator active, and confirm that it produces a clean structure. The Easy Table of Contents directory mentions migration of settings from certain alternatives, but any migration still requires checking the actual public result.

Set Up a Safe Rollback Point

Create a normal backup, or at least record the active plugins, key table-of-contents settings, and the URL of the test article. After making a change, compare the pages first and clear the cache afterward. If you need to roll back, deactivate the new module, clear the cache only after that, and repeat the test. Do not edit plugin files for a quick fix: the change will disappear during an update, and the history of the underlying issue will be lost.

Installing the Plugin Combination and Running a First Test with Fewer Variables

The installation sequence should move from the source to compatibility. First, the core Easy Table of Contents plugin must be active because it creates the original list. Next, the AMP tool must be working because it generates the AMP version. Only then should AMP Easy Table of Contents be enabled. If you reverse the order, you cannot reliably tell what is missing: the core plugin, the AMP branch, or the compatibility module.

First Confirm Easy Table of Contents on the Standard Page

In the WordPress admin area, go to Plugins → Installed Plugins, confirm that the core plugin is active, and open Settings → Table of Contents. The official documentation recommends starting with the main decision: select the post types for which support should be enabled. It makes sense to change other settings only after the first visible result appears.

If the standard table of contents is missing, stop there. Add several genuine H2 headings to the test article, save it, and open it in a new window. Do not activate the AMP add-on in the hope that it will create the list in place of the core plugin: that is not its role.

Activate AMP Easy Table of Contents

Obtain the module file from the developer's official source or an authorized site channel. After installation through Plugins → Add New → Upload Plugin, or through the accepted plugin manager, activate it. The official product page describes its behavior as recognizing an already configured Easy Table of Contents setup and automatically creating an AMP-compatible outcome without a separate complex set of options.

After activation, do not change styling, heading depth, insertion method, and scrolling behavior at the same time. Compare the test article first. That gives you a clear answer as to whether the existing structure carried over to AMP.

Run a Short Paired Test

1. Open the standard published article in a new private browsing window.
2. Confirm that it contains one list and that its items match the headings.
3. Open the actual AMP URL for the same article.
4. Compare the number of items, nesting, and jumps from the beginning, middle, and end of the list.
5. Clear the page cache using the approved method and repeat the AMP check.

Once both versions match in their meaningful structure, you can work on usability and design. If the AMP version does not match, do not compensate by adding manual HTML in the editor. First determine whether the add-on is active, whether the wrong URL is being used, or whether the cache is displaying an earlier state.

Core Table-of-Contents Settings That Affect the AMP Output

There is little value in looking for a separate AMP Easy Table of Contents panel with every familiar setting. Configuration takes place in Easy Table of Contents because it creates the input for compatible rendering. Treat the settings as a sequence of decisions rather than a collection of checkboxes.

Post Types and Display Method

Start by deciding where the list is genuinely useful. For a knowledge base, that may mean posts, guide pages, or a dedicated documentation post type. For archives, short news items, contact pages, and landing pages, a table of contents is often unnecessary. Enabling every available type can produce unpredictable blocks where headings serve only a formatting purpose.

Automatic insertion is a good fit for a series of similar materials. A shortcode works when an editor must place the list in a specific location. If you choose the manual approach, make it an editorial rule: otherwise, some posts will contain an automatic table of contents, others a shortcode, and some both.

Display Threshold and Heading Depth

The display threshold should reflect the size of the article. In a short post, a list merely repeats two headings and pushes the content farther down. In a substantial guide with several thematic sections, it can save a great deal of scrolling. Test the rule on short, medium-length, and long content. The goal is not to find a magic number, but to make the block appear where it is actually useful.

For most guides, H2 and H3 are sufficient. Add H4 only when it carries independent navigation value. On an AMP page, a deeply nested tree quickly becomes a long staircase of small phrases. Readers should see a map, not a technical inventory of every document tag.

Hierarchy, Numbering, and the Container Label

Hierarchical mode shows each H3 as subordinate to the preceding H2. It is justified in a step-by-step guide where a large chapter contains several related actions. In linear content, a flat list is often easier to scan. Numbering can help with formally numbered chapters, but it may duplicate numbers already present in the headings. Enable it only after reviewing the actual page.

A label such as Contents or In This Article helps readers understand what the block is for. However, it should not unexpectedly become an item in its own table of contents. After changing the label's tag or wording, inspect the final page. If the container title appears in the list, revisit the configuration instead of accepting an unnecessary link.

Collapsing, Smooth Scrolling, and URL Fragments

Collapsing is useful when the list is so long that it overwhelms the beginning of the article, provided the block title and expansion control are clear. On a short page, a hidden list adds an unnecessary action. Smooth scrolling may improve the feel of a jump, but the main test remains the same: the visitor must arrive at the intended chapter rather than simply see an animation.

Change settings related to the fragment after # in the URL only after a paired test. An anchor link normally uses that fragment, and the browser should handle it consistently on both the standard and AMP pages. A visually cleaner URL is not worth losing a verifiable jump target.

Exclusions and the Advanced Selector

For a one-off task, start with built-in tools. The plugin directory includes examples such as [ez-toc exclude='Test'] and [ez-toc heading_levels='2,3']. In a real article, replace the example with the exact utility text or choose a heading-level restriction. Before saving, make sure you have not removed a useful chapter with a similar word.

Support materials also mention the ez_toc_exclude_by_selector filter for excluding headings by selector. This is an option for an experienced administrator when the issue is caused by a stable theme structure. Do not paste unverified PHP from a random source. First confirm that the unwanted headings genuinely have a consistent parent selector, apply the smallest reversible change through a safe site mechanism, and test both the standard and AMP versions.

How to Prepare Headings So the List Helps Readers

AMP Easy Table of Contents does not correct editorial structure, but that structure directly determines the quality of the outcome. Headings serve readers, editors, the core plugin, and AMP output at the same time. Working with them is therefore not cosmetic cleanup before publication; it is configuration of the product's input data.

One H2 Should Answer One Question

Each major chapter should address a separate question: why the plugin combination is needed, what to check before installation, where the settings are located, how to test AMP, or what to do when an error occurs. When one section tries to hold three topics, it produces long paragraphs without landmarks and then artificial H3 headings. It is better to separate the ideas in the editor. The table of contents immediately reveals whether the real stages are distinct enough.

A useful test is to read only the future list items. If they let you reconstruct the flow of the guide, the outline is sound. If you see labels such as Additional Information, Important, and Miscellaneous, visitors cannot tell where a link will take them. These labels are especially inconvenient in AMP, where the list often acts as a compact map of the entire page.

Do Not Substitute Visual Styling for Structure

WordPress makes it easy to make a line large or bold. For a table of contents, what matters is a real heading block. Do not style an ordinary paragraph as H2 just to make it larger. Likewise, do not turn image captions, feature cards, and calls to action into standalone headings: they will enter the navigation and create a misleading route.

If you use a page builder, inspect the published HTML structure, not just the attractive editor view. The core plugin directory notes that custom post types are supported as long as content is rendered through the_content(). If a heading is visible in the builder but missing from the table of contents, that is a diagnostic clue about the rendering method. A second link generator is not the answer.

Give Links Self-Explanatory Names

A list item should make sense without the surrounding paragraph. Instead of Configuration, use Selecting Heading Levels and a Display Threshold. Instead of Testing, use Comparing the Standard and AMP Pages. At the same time, there is no need to put the plugin name in every chapter. A long repeated prefix makes the table of contents heavier and makes it harder to choose an item.

Keep the grammar consistent. If the first items describe actions, continue with actions. If they are phrased as questions, do not mix them with isolated nouns. This editorial discipline also reduces the temptation to add unnecessary levels merely for stylistic variety.

Check for Duplicates and Utility Headings

Two identical headings in one post are inconvenient for both readers and anchor behavior. Clarify the context instead: not Configuration twice, but Configuring Levels and Configuring Link Behavior. Duplicates may appear in FAQs, repeated cards, recommended-content sections, and page-builder template sections.

A utility block with a heading that does not belong in the route is better moved outside the main content, reduced to a suitable element, or excluded using a built-in method. Do not remove a useful heading simply to keep the list clean. First decide whether it is part of the visitor journey, then choose the appropriate level or exclusion.

Where to Place the Table of Contents: Automatic Insertion, Shortcode, or Theme

The position of the table of contents affects how it is used, but for AMP compatibility, one consistent and controlled source matters more. Choose the placement method first, confirm stable rendering, and only then refine the appearance. Otherwise, an attractive block may hide a technical problem.

Automatic Insertion for Editorial Series

Automatic output works well for tutorials, reviews, knowledge-base articles, and other recurring content types. The editor creates the structure, while the plugin decides whether there are enough headings to display the list. This reduces the risk of forgetting navigation in a new post. For AMP, it is an advantage because the source markup is generated in the same way.

The downside is that a single rule does not always suit an unusual page. A long notice, form, special introductory block, or page-builder component can make the selected position unsuitable. Do not fix one article by adding a second instance. Disable automatic output for that particular case, or deliberately move that category to a manual method.

A Shortcode at an Exact Position

The [ez-toc] shortcode is useful when the list must appear after two or three introductory paragraphs, before the practical portion of an article, or inside a special template. Easy Table of Contents support confirms this placement method. It does not override the general rules for levels and exclusions; it only defines where the container appears.

Before adding the shortcode, disable automatic insertion for the same use case. Save the article and confirm that the standard page contains one list. Only then open AMP. If the standard version has one instance while AMP shows two containers, do not hide one with CSS. Look for the second source in the AMP template, settings, or cached copy.

A Sticky Widget Is a Separate Task

The core plugin can render a table of contents as a widget, including one that stays visible while scrolling. This can be useful on a wide documentation page, but the plugin description specifically notes that the correct selector depends on the theme. Do not copy a selector from another site or expect identical behavior in every template.

First confirm the primary content block. If the project genuinely needs an additional widget, test it independently at several viewport widths. On a mobile device, sticky navigation may cover text, and the AMP branch may use another template. One clean list near the beginning is often more useful than an eye-catching but conflicting sidebar element.

A Small Reversible CSS Adjustment

Once the list is already correct on both the standard and AMP pages, a small CSS adjustment to its appearance is acceptable. This is not an add-on setting and not a fix for validation. It is based on the public Easy Table of Contents container visible in the final markup and mentioned in support materials. Add the rule through the theme's built-in Additional CSS area or a child theme, not through plugin files.

#ez-toc-container { border-radius: 10px; padding: 1rem 1.25rem; background: #f4f7fb; }
#ez-toc-container a { text-decoration-thickness: 1px; }

This is a custom adjustment for a soft background and spacing. To verify it, open the test article in both versions, confirm sufficient contrast, and make sure links remain noticeable on a narrow screen. To roll it back, remove the two rules and clear the cache. If the AMP page does not receive theme styles, do not expand the CSS blindly: first review the rules of the specific AMP tool.

Practical Example: A Long Guide in Standard and AMP Versions

Imagine a service company's knowledge base. It publishes a detailed guide to preparing equipment: an introduction, requirements, steps, a checklist, answers to questions, and support contact details. The article is long, and visitors often arrive from search at a specific task rather than at the beginning. The goal is to give them one list of real chapters and preserve that list on the AMP URL without manually duplicating the article.

Prepare a Test Article

Create a draft with one H1, six thematic H2 headings, and several subordinate H3 headings. Do not use headings for short card labels, decorative quotes, or the final contact section. If a utility section needs a visual label but should not enter the list, format it with an appropriate element or exclude it deliberately.

Before activating the add-on, open the standard version. Confirm that the theme has not added a second table of contents. Enable support for the required post type in the core plugin and choose either automatic insertion or one shortcode. If the output is wrong at this stage, it is too early to test AMP: the problem is still in the base structure.

Configure the Source Rules

1. In Settings → Table of Contents, enable only the knowledge-base post type or instructional posts.
2. Keep H2 and H3 if they form a clear two-level map.
3. Choose a threshold that prevents short notes from receiving an unnecessary block.
4. Enable hierarchy only when subsections are genuinely subordinate.
5. Save the selected single insertion method with Save Changes.

Now read the resulting list as a visitor would. It should not include a form heading, promotional phrase, or the title of a related item. If there is an extra entry, find it in the source content. Correcting the semantics is usually more reliable than applying a broad global exclusion that could affect another article.

Enable Compatibility and Compare the Output

When the standard version consistently shows one list, activate AMP Easy Table of Contents. Open the test article again. Do not judge by the appearance of the WordPress admin area: the module's purpose is observed on the published AMP page. Compare entries in order. Styling around the block may differ because of the AMP template, but the sections themselves should reflect the selected structure.

Click a top-level item, a nested item, and a link after a full page reload. The target heading should not be hidden under a fixed header or remain far outside the reading area. If the header covers it, this is usually a matter of theme or AMP-template geometry, not a reason to change the entire list.

Check the Cached Output

Cache can create the impression that a configuration change did not work. The first view may serve old AMP HTML, while the next one serves the updated version. After the initial success, clear the cache for the specific page, then open the AMP URL in a private window or a different browser profile. If a CDN is used, apply the approved refresh for that particular URL. Do not make several changes before clearing the cache: otherwise, you cannot tell which version you are viewing.

A successful outcome is not simply a visually appealing container. It is one list on the published AMP page that matches the current headings, has working links after the cache is cleared, and does not trigger an issue in the AMP validation tool you use.

Checking the Outcome: Structure, Anchors, Validation, and Reading Experience

Testing should not consist of a single click. A table of contents may display but contain incorrect items; the items may be correct but fail to lead to their sections; links may work on the standard page and break only in AMP. After any meaningful change, run a short but layered test.

Compare the Standard and AMP URLs

Open both versions of the same article side by side. First compare the number of items, then chapter titles and nesting, and then the location of the block. Do not require a pixel-perfect match: templates may differ. What you need is the same navigation behavior. If one heading differs, look for it in the source content. If the difference affects every article, check the global heading-level and post-type rules.

If the standard version is correct but the AMP list disappears from every test page, check the module status, AMP configuration, and cache. This order narrows the possible causes. It does not require dismantling useful settings simply because the symptom appears in another page version.

Test Link Targets and URL Fragments

Click a visible item, an item from the middle, and a lower link. In every case, the destination heading should be visible in the reading area. The address may contain a fragment after # when the selected behavior uses one. Do not remove it manually unless you have confirmed that it is the actual cause of the problem.

If the browser reaches the correct section but the heading is hidden under a fixed header, examine the tools provided by the theme or AMP template. If the page jumps to the top, first rule out invalid HTML, duplicate identifiers, and conflicting scroll behavior. A recent Easy Table of Contents support thread linked a similar mobile symptom to invalid HTML structure that changed the block's position in the DOM. Treat that as a useful hypothesis to test, not a universal diagnosis.

Check AMP Validation Separately

Open the validation screen or report provided by the installed AMP tool. The presence of the list does not prove that the AMP HTML is valid. Public support materials show that table-of-contents and AMP combinations have encountered markup errors that were fixed through updates. Before attempting manual intervention, check official updates for the core plugin, the add-on, and the AMP component.

If the validator identifies an element, do not hide it with a CSS rule. Record the error text, page URL, active component set, and test outcome. Support teams can work more easily with a reproducible case than with a statement such as it doesn't work. In the request, state separately whether the symptom appears on the standard URL or only in AMP.

Check Usability and Accessibility

Make sure links are distinguishable by more than color, the block label is clear, and a collapsed list can be expanded without having to hit a tiny icon precisely. With a sticky version, always test a narrow screen and long chapter titles. Do not place a critically important section only inside a hidden table of contents: it is a navigation tool, not a replacement for content.

Ask one final question from the perspective of a new visitor: can they understand the topic from the top of the page, is the list placed before an overly long introduction, and does it interfere with reading? The configuration is successful when it reduces scrolling and decision-making rather than merely adding interface elements.

Troubleshooting AMP Easy Table of Contents: Symptoms, Checks, and Safe Rollback

Do not begin by disabling every plugin. First identify where the issue appears: on the standard page, only in AMP, only on mobile, only in one post, or only in a cached copy. Then work from input to output: headings, core rules, insertion method, AMP compatibility, cache, theme, and link behavior.

The List Is Missing from Both the Standard and AMP Pages

Symptom: the published article does not display a table of contents at all. Likely cause: the required post type is not enabled, the content has no real headings at the selected levels, the threshold is too high, the table of contents is disabled for that post, or page-builder content does not pass through the expected WordPress output.

Check: open Settings → Table of Contents, confirm the post type, create a temporary test page with several H2 headings, and see whether the list appears. Review any individual post settings. Fix: enable the correct type and correct the structure, threshold, or single insertion method. Rollback: if a global rule added the block to unintended pages, restore the previous support scope and configure a separate content type.

The Standard Page Is Correct but the AMP Version Has No Table of Contents

Symptom: the list is correct on the standard URL, but it is missing from AMP or displays an old version. Likely cause: the add-on is not active, components have been updated inconsistently, the AMP cache contains old HTML, or the wrong AMP URL is being checked.

Check: confirm the AMP Easy Table of Contents status, open the actual URL, clear the cache for the specific page, and repeat the test in a private window. Compare two articles of the same type. Open the AMP validation report. Fix: update components from official sources and repeat the test without changing settings at the same time. Rollback: if the failure is critical, temporarily disable only the new compatibility module, restore the verified configuration, and continue the investigation in a test environment.

Two Identical Lists Appear on the Page

Symptom: two similar tables of contents appear before the content or in separate positions. Likely cause: automatic insertion is active while [ez-toc] is also present in the content, or the theme, page builder, or another plugin generates its own navigation. In some cases, an old template remains cached after the insertion method changes.

Check: locate the shortcode in the editor, review automatic-output settings, temporarily disable the theme's TOC feature on a test page, and clear the cache. Fix: leave only one source: automatic mode, a manual shortcode, or a theme feature. Do not hide the second block with CSS. Rollback: if disabling automatic mode removed the list from an entire article series, restore it and remove the manual shortcode only from the problematic post.

A Link Goes to the Top of the Page or a Nearby Location

Symptom: clicking an item changes the address, but the page remains at the top or lands at the wrong chapter. Likely cause: invalid HTML structure, duplicate headings, a scrolling conflict, old cached HTML, or a fixed header hiding the destination.

Check: compare the standard and AMP URLs, look for repeated headings, inspect the markup around the container, and temporarily isolate conflicting optimizations in a test. Fix: correct markup and duplicates first, then test conflicting components one at a time. If the header covers the target, configure an acceptable offset at the theme or AMP-template level. Rollback: if a smooth-scrolling experiment made jumps worse, return to standard behavior and retain verifiable anchor links.

FAQ Items, Cards, and Template Elements Enter the List

Symptom: the table of contents includes widget titles, related-content items, or utility cards. Likely cause: these elements use real heading tags inside the area scanned by the core plugin.

Check: find every unwanted item on the published page and identify its source block. Fix: first reduce the utility element to appropriate semantics or move it outside the main content, then use a precise built-in exclusion. Reserve the ez_toc_exclude_by_selector filter for a stable selector and experienced maintenance. Rollback: if a global exclusion removed useful chapters from other pages, undo it and address the issue inside the specific template.

The AMP Validator Reports an Error After an Update

Symptom: a previously working page receives a warning after an update. Likely cause: an incompatible markup change, a conflict with another plugin, or cache. Support history includes AMP issues that were fixed in updates, so do not automatically assume the problem is caused by your configuration.

Check: record the exact error text, URL, and active versions in the support request, reproduce the issue on a test page and in a minimal test configuration. Fix: apply an available official fix or contact support with a reproducible report. Rollback: for a serious failure, return to the last verified state using a normal backup rather than editing files.

Frequently Asked Questions About AMP Easy Table of Contents

Do I need to configure the AMP add-on separately?

The main decisions are made in Easy Table of Contents: post types, heading levels, output location, and exclusions. AMP Easy Table of Contents is a compatibility extension for an existing configuration. Get the standard list right first, then test AMP.

Why not manually copy the list of links into AMP?

A copy quickly falls out of sync with the article: an editor adds a new heading to the main content while the manual AMP list remains outdated. The plugin combination is useful because it reduces the number of parallel editing points. Manual markup is justified only when the table of contents should not be generated from headings.

Can I use H2 only?

Yes. For a typical article, that is often the best choice: the list shows major chapters and stays concise. Add H3 when visitors genuinely benefit from jumping to an independent stage in a long guide. After changing the setting, compare both versions across several posts.

Does the module work with a table of contents generated by a theme or another plugin?

There is no reason to expect that automatically. The product is presented as a compatibility extension specifically for Easy Table of Contents. If a theme, Gutenberg block, or another tool creates the list, study that tool's documentation and AMP compatibility. Do not use this add-on as a universal fix for every list of links.

Can I add [ez-toc] to just one page?

Yes, the core plugin supports manual placement. This is convenient when you need precise editorial positioning. However, disable automatic insertion for the same situation or two instances will appear. After saving, check both the standard and AMP URLs.

Does a table of contents improve SEO by itself?

No. It may make a long article easier to use and provide clear anchor jumps, but it does not replace content quality, technical quality, accessibility, or broader search work. Use it for the reader's route, not as a ranking promise.

What should I do if an AMP error appears after an update?

Record the error and URL, clear the cache for the specific page, confirm that components come from official sources, and repeat the test on a test article. Do not edit plugin files. If the issue is confirmed, prepare a reproducible report for the developer or temporarily return to a verified state.

When is it better not to use AMP Easy Table of Contents?

When the site does not use AMP, when the source table of contents is not generated by Easy Table of Contents, when pages are too short, or when the combination does not fit the project architecture after proper testing. One suitable mechanism is better than two unnecessary plugins.

Editorial Heading Policy: Keep the Table of Contents from Becoming a Second Editor

AMP Easy Table of Contents does not analyze the meaning of text the way an editor does. It receives an already prepared heading hierarchy from the core Easy Table of Contents plugin and helps display it in the AMP version. Navigation quality therefore begins before the plugin, in the article draft. If an author uses H2 merely for a large font, jumps from H2 to H4, or formats a repeated word as a full chapter, the list may be technically correct but noisy for readers.

It is useful to adopt one simple editorial rule in advance. An H2 marks an independent answer to a reader's question: for example, preparation, configuring a specific mechanism, testing, or a limitation. An H3 explains a step within that answer when readers genuinely need to jump to it directly. An ordinary paragraph, image caption, note, and promotional phrase should not receive a heading level simply for visual emphasis. This approach makes the article easier to read, improves structural accessibility, and provides predictable input for the link generator.

Map the Article Before Enabling Automatic Insertion

For a long guide, it is helpful to outline future H2 headings first and then decide which of them contain independent substeps. Suppose an article explains how to configure a form: major chapters may cover preparation, creating fields, notifications, spam protection, testing, and troubleshooting. Inside the notification chapter, subheadings about recipients, the email template, and a test submission make sense. Inside the preparation chapter, two short paragraphs usually do not need their own H3. The user then sees a route to completing a task rather than a technical tree of the document.

Before publishing, read the future table-of-contents items in sequence without the main text. If the titles do not make it clear where a link leads, rewrite the headings. A label such as Configuration says almost nothing on a page with several different settings. A heading such as Which Emails a Manager Receives After Form Submission already describes the expected outcome. The heading does not have to be long: naming the object and action is enough. This matters especially in AMP, where readers often open content on a phone and use the list as a quick way to avoid scrolling through multiple screens.

Choose Depth Separately for Each Article Format

One site-wide depth setting may seem convenient, but it does not always produce a useful result. For a news article with three major parts, a list containing only H2 headings is usually enough. For a substantial guide where individual substeps can be completed independently, adding H3 can help. Deeper levels should be enabled only after reviewing the actual list: on a narrow screen, multi-level nesting quickly becomes a long column of links that hides the beginning of the content itself.

Make the decision observable. Take one short post, one typical guide, and one genuinely long article. In a copy of the settings, enable only H2, then review the standard and AMP versions. Next add H3 and compare four indicators: whether important sections moved below the initial viewport, whether items without independent meaning appeared, whether the order follows the article naturally, and whether a reader can reach the required block with one tap. Choose the most useful list, not the most detailed one. Record the comparison outcome in an editorial guideline so different authors do not change the approach from page to page.

Do Not Disguise Styling as Semantics

A common cause of a poor table of contents occurs outside the settings of either plugin. An editor uses a heading to emphasize a short note, product name, the word Important, or a visual divider. The core plugin correctly recognizes that element as a section, and the compatible AMP layer carries it into mobile output. Removing the item only on AMP would be the wrong response: the standard page remains confusing as well.

A safe correction has three parts. First, replace the decorative heading with a standard paragraph using appropriate styling or another site-approved element. Next, make sure neighboring levels still follow the proper order: an H2 should be followed by an H3, not an accidental H4. Finally, update the page and inspect the generated list in both versions. Do not edit a generated anchor manually when the cause is in the original structure: the correction may disappear after the next save or rebuild.

How to Handle Repeating Blocks and Templates

Content sites often contain template fragments: an author block, promotional insert, mini FAQ, related-content list, or affiliate-link notice. If these include headings, they can enter the table of contents for every article. To readers, this creates a misleading route: an item promises part of the main article but takes them to a utility element at the bottom or between paragraphs. The issue is more noticeable in AMP because space is limited and users expect quick access to content.

Check such elements in the source template, not only in one post. If the block is not a chapter of the article, do not use heading levels that participate in list generation, or apply the exclusion provided by the core plugin if it is confirmed to work in your configuration. After making a change, test an article with the template and one without it. This protects against the reverse effect, where fixing a utility block accidentally hides a useful chapter in older posts.

Special Case: Identical or Nearly Identical Chapter Titles

Two chapters named Configuration may make sense to an author because of nearby context, but they look identical in a table of contents. Anchor links should remain distinguishable and stable when content is edited. Rename them by subject: Configuring Notifications and Configuring the Form on the Page. Then save the article and follow both links in the standard version before repeating the check in AMP. This evaluates not only the list text but the actual destination of every jump.

If old external links to a particular anchor no longer lead to the intended line after a change, do not promise automatic preservation of old addresses without confirmation from the system in use. For important published materials, test changes on a copy or in a staging environment first. Structural stability matters more than cosmetic renaming when an article is already cited, bookmarked, or used by support staff.

Publication Check Route: From Draft to AMP URL

The Easy Table of Contents and AMP Easy Table of Contents combination becomes more reliable when it is treated as part of the publication workflow rather than as a setting enabled once. Heading changes, an editor switch, a new page-builder block, a theme update, or a caching layer can alter the outcome regardless of whether anyone opened the add-on settings screen. A small repeatable review route catches those changes before readers encounter them.

Step 1. Check the Article Before Generating AMP

Open the draft or preview and review the content in the editor from top to bottom. Confirm that the main topic starts with H2 and subordinate actions use H3 only where needed. Remove empty headings, headings made of a single decorative phrase, and duplicates. If the core table of contents is inserted automatically, confirm that it appears once and in the expected position. With manual placement, make sure the shortcode or another supported core-plugin method appears in the content only once.

At this stage, it is useful not to look at AMP at all. If the standard page does not create a correct list, AMP compatibility should not mask the original failure. The first checkpoint is consistency between headings and the list in standard output. Only after that is it worth spending time comparing the second version.

Step 2. Confirm That URLs Actually Lead to the Intended Sections

Click every item not only with a mouse but also with a keyboard if that is available in your testing process. Each link should take the user to the corresponding chapter, not to a nearby but different block, the top of the container, or empty space. Pay particular attention to headings containing non-Latin characters, punctuation, links within text, and repeated words. Editors and add-ons can process these details differently, so the actual outcome matters more here than assumptions about how an identifier will be generated.

After edits, do not copy URL fragments from an old preview as permanent references. Save the post first, open the public URL, and repeat the jumps. If the site uses optimization, clear or refresh the exact page being tested. Testing against stale cache creates the false impression that the add-on ignores settings even though visitors and the generation system may be seeing different HTML versions.

Step 3. Compare Standard and AMP Versions Using the Same Checklist

The standard and AMP pages do not have to look identical pixel for pixel. Their theme containers, typography, and secondary styling may differ. However, navigation behavior should withstand comparison. Create a short checklist for the editorial team and apply it to test materials.

What to compare after publishing an article with a table of contents

Indicator	Standard Page	AMP Version	What a Difference May Mean
Number of visible items	Matches the selected heading levels	Preserves the same useful route	Check post types, exclusions, template content, and cache
Item order	Follows the article structure	Does not change the sequence without a clear reason	Check heading order and output conflicts
Jump destination	Opens the intended chapter	Opens the same meaningful chapter	Check identifiers, markup, and actual AMP HTML
Table-of-contents instances	One consistent list	No duplicate beside the main list	Check automatic and manual insertion methods
Visibility after clearing cache	Shows the saved publication	Shows the current AMP output	Check cache, CDN, and page refresh order

The table does not replace troubleshooting, but it prevents vague claims such as something is wrong on the phone. Instead, you get a specific symptom: the third item is missing, the second goes to the wrong location, two lists render, or AMP displays an old structure. With that information, it is easier to identify the boundary of the problem without changing headings, settings, and the theme all at once.

Step 4. Use Test Pages, Not One Successful Example

One simple article may pass testing even though the plugin combination does not account for the real content variations on the site. Prepare a small set of test pages: a short article with several H2 headings, a long guide with H2 and H3, a post with manual list placement, and an article containing a typical template block. These pages do not need to form a separate test site, but the team should know them and they should not change every day.

After changing core settings, the theme, editor, or optimization stack, review this set in both standard and AMP versions. Check not only whether the list exists, but also what happens after a reader taps a link. This approach detects a conflict on a page with many subheadings even when a short news item looks perfect. If the issue is reproducible in only one format, that already provides a useful boundary for further investigation.

Step 5. Separate Editorial Errors, Cache, and Component Conflicts

When the AMP list differs from the standard one, do not begin by mass-disabling plugins on a live site. Compare the facts first. If an extra item appears in both versions, the cause is most likely in content structure or a general source-table-of-contents setting. If the standard version is correct while AMP shows an old or incomplete list, record the URL, publication time, cache-clearing actions, and the exact difference. Then repeat the check on a test article.

If the difference remains after the page is refreshed, check whether the theme, a block, or another plugin is rendering its own table of contents. The task is not to guess the culprit but to establish one source of the outcome. On a test copy, you can temporarily exclude an additional mechanism and repeat the same workflow. On a live site, any changes should be reversible, aligned with the maintenance process, and limited in duration. Never fix display issues by directly editing add-on files: an update will remove the change while the real cause remains.

Step 6. Send Support a Reproducible Report, Not a General Complaint

If the issue remains confirmed after checking structure, cache, and a single table-of-contents source, prepare a short report. It is enough to include the standard and AMP page URLs, the expected outcome, actual outcome, exact validator error text when available, list placement method, heading levels in use, and the steps that reproduce the issue. Do not include administrator credentials, service keys, or full site backups in the report.

Add a minimal example: for instance, a page with three H2 headings and two H3 headings where an extra item appears only with automatic insertion. This is far more useful than saying the table of contents does not work. A developer or technical specialist can reproduce the specific observation, while you retain the option to safely roll back a temporary production change.

Making Changes Without Losing Navigation: A Safe Order for Published Articles

On an established site, tables of contents rarely arrive under ideal conditions. Some articles may have been written in the Classic Editor, others assembled from blocks; some pages contain a manual list, while others depend on automatic insertion. Adding or updating AMP Easy Table of Contents in such a library should not become a blind mass change to content. Its role is compatible with an existing Easy Table of Contents setup, so it is safer to understand which rules actually create the source list before extending them across the archive.

Start with an inventory, not by editing hundreds of posts. Select several representatives from every important group: an article with an automatic table of contents, one with manual insertion, material with deeply nested H3 headings, a post with a repeating block near the bottom, and a publication created with a nonstandard editor. For each one, note where the list comes from, how many levels it displays, whether it has an AMP URL, and what happens when links are followed. This is not bureaucratic paperwork; it prevents a special case from being mistaken for a global rule.

Keep the Roles of the Three Parts Separate

At least three layers participate in this task. Content defines headings and the order of the material. The core Easy Table of Contents plugin determines how a table of contents is created from that structure: whether it is placed automatically, for which posts, which levels participate, and what is excluded. AMP Easy Table of Contents serves as the compatibility extension so the outcome has a proper path in the AMP environment. Separately, your AMP solution generates or serves the AMP version of the page.

This separation is useful for every change. If you need to remove an extra item, first look for a decorative heading or a core table-of-contents rule. If the standard page looks correct but the AMP version differs, record the boundary at the AMP-compatibility, cache, or output-conflict level. If the AMP URL itself does not open, that is not a reason to change list settings before checking routing and the site's AMP status. One observable issue should lead to one next test, not to switching every component at once.

Introduce New Rules to a Test Sample

Suppose the editorial team wants to show only H2 headings so mobile navigation stays shorter. Do not change the rule and recheck the entire archive on the same day. First select five or ten typical articles, save a record of their current structure, and apply the change in a test environment or during a controlled window. Open the standard page and AMP version, assess the list, anchor jumps, duplicates, and visibility of the first useful paragraph after the table of contents.

If the sample passes testing, you can move to publishing the general rule. If one post format behaves differently, do not compensate with manual HTML changes inside plugin files. Find the smallest rule that explains the difference: a different post type, manual placement, a template heading, or another list generator. Then decide whether that group needs a separate editorial workflow. An exception the team understands is safer than a hidden fix that will not survive an update.

Change Only One Factor Per Test Cycle

Table-of-contents issues often become impossible to solve because of a well-intentioned effort to speed up the repair: someone updates plugins, changes heading levels, clears the entire cache, edits a template, and adds new CSS at the same time. After that, no one knows what caused or fixed the outcome. For AMP Easy Table of Contents, a short cycle is more useful: record the initial symptom, make one reversible change, refresh the specific page, test the standard and AMP versions, and record the outcome.

For example, if two identical lists appear on an AMP page, first check whether automatic insertion is active together with a manual [ez-toc]. Temporarily leave one supported method and repeat the test. Only if the duplicate remains should you move on to the theme, block, or another plugin. If the list is single but contains an extra utility chapter, restore the single source and correct the source semantics in the template. This sequence keeps cause and effect visible.

Be Especially Careful with Historical Anchors

Links to article sections may be saved in bookmarks, email campaigns, support documentation, and other site materials. When an author changes a heading, the core mechanism may generate a different identifier for the jump. You cannot confidently promise that all old URL fragments will remain: this depends on the editor, plugin, filters, and specific markup. Important published guides are therefore best changed gradually, with testing focused on the links that the team or external documentation actually uses.

Create a short list of critical jumps, such as installation, troubleshooting, and download. After adjusting the structure, open old and new links in the standard version, then in the AMP version if it uses the same meaningful destinations. If an address no longer opens the correct block, do not hide the issue by replacing table-of-contents text. The solution should align with your CMS redirect policy and available tools. When uncertain, it is safer to retain a clear heading and postpone mass renaming until it has been tested.

What to Record Before Updating Components

Updating the core plugin, AMP solution, theme, or WordPress itself can change markup, filter order, or cache behavior. Before scheduled work, record non-secret information that will help restore context: URLs of test pages, screenshots of the standard and AMP output, table-of-contents insertion method, selected heading depth, and the observed validator state. This information can be kept in an internal release note. Do not include administrator passwords, tokens, backup archives, or private visitor data.

After updating, repeat the same test set instead of expanding it simply because the work went quickly. If the appearance changes, separate cosmetics from functionality: a list may look different because of the theme while remaining correct in composition and jump behavior. Conversely, a familiar-looking list may lead to incorrect locations. The readiness criterion is not the absence of visible changes, but preserved and verifiable navigation for readers.

How to Evaluate the Value of an AMP Table of Contents Without SEO Myths

A table of contents is not a button for higher rankings. Its practical value lies elsewhere: a long article gains a visible route, and users can move to the topic they need without guessing where it is located. This is particularly noticeable in AMP on long pages, when reading begins with finding an answer rather than working through every paragraph linearly. AMP Easy Table of Contents helps preserve that route alongside the core table of contents, but it does not replace the usefulness, accuracy, or clear structure of the article itself.

Define a Testable Reader Task

Instead of an abstract goal such as improve SEO, define a concrete visitor path. For example: someone opens a guide to configuring a form and wants to jump directly to notifications; a site owner is looking for the section on diagnosing an AMP error; an editor returns to an instruction to verify the step for enabling a feature. In each case, the table of contents is useful if the item title lets the reader identify the needed section and the anchor link takes them there without unnecessary scrolling.

You can test this manually. Give someone who did not prepare the text one question and open the AMP page on a device or in an appropriate viewing mode. Observe whether they can choose the right item from the table of contents, understand the difference between similar titles, and arrive at the beginning of the needed block. There is no need to collect personal data or turn this into a large experiment. Even a few quality observations often show that the problem lies in a vague chapter title rather than in the AMP add-on.

Evaluate the Path, Not Just the Presence of a Block

A superficial check that the list exists is not enough. A usable table of contents should help readers complete a path: notice it, understand the items, choose a link, arrive at the location, and continue reading. On an AMP page, assess whether the list itself occupies too much of the above-the-fold area, whether nested entries become an unreadable column, and whether a fixed header hides the beginning of the section after a jump. The last effect can look like a broken link even when the anchor worked technically.

If the destination is covered by the header, do not immediately change the list itself. First confirm the symptom across several items and check the behavior of your theme and AMP output. Any CSS change should be small, reversible, and tested in both versions. When there is no documented extension point and no precise cause, it is better not to add custom code to a live site: it may create a new conflict after an update. In that case, document the observation for the theme or support team and use safe structural settings available in the components you use.

Keep Titles Distinguishable

Table-of-contents items compete for attention. A list containing Configuration, Settings, and Additional Settings forces users to open every section in turn. More distinct items, such as Configuring Fields, Configuring the Administrator Email, and Testing Submission, let readers decide before jumping. This is not keyword optimization; it is respect for the reader's time.

Review titles at two levels. First, read each item on its own: is the object of the action clear? Second, read the entire list: do the opening words repeat so heavily that the eye loses the differences? If necessary, put the shared subject in the major chapter title and make subheadings specific and action-oriented. Do not sacrifice accuracy for uniform length: a guide should remain natural English, not become a set of utility labels.

Treat Accessibility as Part of the Outcome

Anchor navigation helps many visitors, but only when jumps remain understandable and controllable. Make sure each link has readable text rather than a meaningless symbol or number. Do not rely only on color to distinguish an item or its state. Where possible, navigate the list with a keyboard and confirm that users can see which link has focus. These checks are not a specific AMP Easy Table of Contents setting; they concern the real quality of the output that the core table of contents and AMP compatibility should preserve.

If the theme removes visible focus, links blend into the background, or built-in styles alter contrast, record this as a theme or AMP-layer styling issue rather than evidence of an add-on error. Then identify an accessible and supported place to correct it. Do not insert styles into add-on files: such a change is hard to maintain and may disappear after an update. Editorial structure, clear titles, and one source for the list remain the safest ways to improve navigation without risky customization.

Decide Page by Page: Where a List Helps and Where It Gets in the Way

Not every publication needs an automatically visible table of contents. A short two-paragraph news item usually gains nothing from one, and a promotional landing page may have its own differently designed navigation. In contrast, a substantial practical guide, a knowledge-base article with independent questions, educational material with stages, and a collection of options often benefit from clear anchors. The core plugin lets you define inclusion rules, while the compatible AMP layer makes sense where those materials are genuinely available in AMP.

Practical decision matrix for tables of contents

Page Type	Usually Useful Approach	What to Check Before Publishing
Short news item	Do not add a list merely for consistency	Whether there are at least several independent chapters readers will want to jump to
Step-by-step guide	Show H2 headings and use H3 for important independent stages	Every item leads to an action or an outcome check
Large knowledge base	Maintain a clear hierarchy and avoid excessive depth	Utility template blocks have not entered the list
Page with manual insertion	Keep one controlled instance	The automatic rule does not create a second list
Content without an AMP version	Evaluate only the core table of contents	There is no unnecessary dependency on the AMP compatibility add-on

The matrix is not a set of rigid prohibitions. It helps you decide according to a page's purpose rather than a habit of enabling one feature everywhere. After deciding, always inspect the final reader-facing outcome. If the list does not give readers a shorter path to their question, omitting it can be more honest and more useful than adding a decorative column of links.

A Minimal Log for the Content Team

To maintain consistent site behavior, a short internal record is enough: which content types receive a table of contents, which levels are the standard, when manual insertion is acceptable, which AMP test pages should be opened after changes, and where to report a difference. This log should not duplicate plugin documentation. Its purpose is to record decisions for the specific site so the next editor does not add a second [ez-toc] or turn utility labels into navigation chapters.

It is useful to add the date of the internal review and a link to an official source in sources.txt, but do not expose operational details in the visitor-facing article. When the theme, AMP solution, or publishing method changes, review the rules against a test sample. A maintainable workflow is not about never changing anything; it is about ensuring that every change can be tested and safely reversed if needed.

Three Practical Workflows for Editorial and Technical Teams

The same table-of-contents configuration can behave differently depending on how a site creates and maintains content. The following are not universal recipes, but three workflows that help separate the content task from the AMP compatibility task. In every case, the starting point is the standard page: it must first have a clear structure and one expected list, then that outcome is compared with the AMP version.

Workflow 1. A Knowledge Base with Long Independent Answers

The site publishes detailed guides that visitors rarely read from the first line to the last. One person searches for installation, another comes from support to an error section, and a third returns to a familiar step. For this kind of knowledge base, a good list is built around questions and actions. Major H2 headings identify independent parts of the work: preparation, configuration, testing, and recovery after an error. Add H3 only where a section contains several independent sub-tasks.

Configure the core Easy Table of Contents plugin to use an agreed set of levels and test it at two extremes: the shortest article where a list is still justified and the longest guide. Then open the corresponding AMP pages through the route used on the site. Compare not the styling, but the route: whether all required chapters are present, whether the list captures a utility FAQ from the template, whether nesting becomes too heavy on a narrow screen, and whether troubleshooting jumps work. AMP Easy Table of Contents has a clear role here: preventing useful navigation from disappearing in AMP output.

If several authors contribute to the knowledge base, record a minimal editorial standard alongside publication rules. For example: do not use headings for visual notes, give sections distinguishable names, and open one standard and one AMP URL before release. This does not force authors to shape their writing around a tool. Instead, the tool receives a structure readers can already understand.

Workflow 2. Content with a Manually Chosen Table-of-Contents Position

Sometimes an editorial team does not want the list immediately after the introduction. In a review, it may appear after a short conclusion; in a tutorial, before the first practical step; and on a warning page, after an important message. The core plugin supports manual placement, including through [ez-toc], so the position can be controlled in a specific article. However, this workflow requires discipline: automatic insertion for the same page or post type must not create a second instance.

Testing starts in the editor. Locate the manual element, save the page, and confirm that one list appears on the standard URL. Then open the AMP version and repeat the same check. If a duplicate appears, do not remove an arbitrary HTML node from the output or try to hide one block with styles alone. Determine which path creates the second list: the manual shortcode, a general automatic-insertion rule, a theme block, or an independent plugin. Keep one deliberate source, clear the cache for the specific page, and test both versions again.

This workflow is especially useful for important articles where list placement forms part of the editorial rhythm. However, manual insertion should not be applied to every publication without a reason. The more placement points there are, the more likely a future author will forget one, add a repeated list, or move the block together with an inappropriate heading. An automatic rule is better for a repeatable structure; a manual position is better for a confirmed exception.

Workflow 3. AMP Looks Different After a Theme, Optimization, or Cache Change

The editorial team updates the theme or adds another optimization layer. The list remains on the standard page, but the AMP version shows old items, disappears, or looks like a separate duplicate block. Before changing AMP Easy Table of Contents settings, record the observation: public URL, AMP URL, article save time, expected items, and the actual difference. Open a test page with a simple structure and another with nested headings. If the issue occurs only for one content type, that immediately narrows the search.

The next safe action is to refresh or clear the cache for the affected page only, using the order accepted on your site, then reopen both URLs in a new session. If AMP still displays an old structure, confirm that you are viewing the current published version rather than an old preview. Next, look for a second list generator, a change in template content, or a conflicting component. Do not immediately add a CSS rule, disable several plugins, and edit headings at the same time: otherwise, you lose the ability to connect an action with an outcome.

Once the cause is confirmed, fix it in its own layer. A decorative H2 issue belongs in content or the template. A second instance is resolved by selecting one insertion mechanism. A failure after an update that reproduces on a clean test page should be documented for the technical team or support. If a temporary rollback is required, use a normal backup and the site's established process. Editing add-on files for an urgent outcome is not a safe rollback: it complicates future updates and leaves no clear change history.

Shared Release Checklist Before Publication

Regardless of the workflow, a compact set of actions is enough before release. First, reread only the headings: they should form a logical route and contain no decorative elements. Next, inspect the standard page: exactly one expected list is present, its items are distinguishable, and every jump reaches the intended chapter. Then compare the AMP version: the route has not lost useful sections, gained a duplicate, or displayed an outdated publication after a cache refresh.

Finish the check from a reader's perspective. Open the content on a narrow screen or in the corresponding mode, choose a question that can be answered only in the middle of the page, and find it through the table of contents. If the route is clear, the jump works, and the section beginning is not obscured by the interface, the task is complete. If not, record the specific symptom and return to one previous step. This checklist turns AMP Easy Table of Contents from an invisible dependency into a testable part of publication quality.

When AMP Easy Table of Contents Is a Good Choice

The module fits well on a site where Easy Table of Contents is already active, long structured materials are published, and preserving the same route through sections in AMP matters. Its strength is not a separate panel of effects, but a clear role: using the verified core table-of-contents configuration for compatible output.

Start with one test publication, check the headings, leave one source for the list, and compare the standard URL with the AMP URL after clearing the cache. If the outcome is stable, extend the rule to other articles. When you are ready to test the combination on your site, go to the section where you can download the latest version of AMP Easy Table of Contents, and use it only together with the core Easy Table of Contents plugin and an active AMP solution.