Heading Structure and Internal Links on Long Pages

Three consumers arrive at a long page and all of them do the same thing: look for the part that answers their question, ignore the rest.

Headings solve the first two rows. Links solve the third. The fourth is where they merge, because most retrieval pipelines split a long document at heading boundaries and keep the heading text attached to the passage as its label. Your H2 becomes the title of that chunk. A section called "The Bigger Picture" produces a passage whose most heavily weighted line contains no query terms at all. We covered how that splitting works in how AI answer engines break pages into retrieval chunks, and it is the strongest practical argument for writing headings plainly.

The working definition for a long page: every section should be findable by scanning, reachable by one link, and quotable on its own.

One H1 per page. It names the page, the way a book has one title and many chapter titles.

The counterargument you will hear is that the HTML5 outline algorithm allowed multiple H1 elements inside section and article, each scoped to its own section. True on paper, never true in practice. No browser implemented the outline algorithm, no assistive technology built on it, and the WHATWG HTML standard now advises against relying on it. What five H1 tags give you today is a flat list of five equally weighted page titles and a screen reader user who cannot tell which one is the page.

The H1 is not the title tag and they do not have to match word for word. The title tag competes for a click on the results page and gets truncated. The H1 reassures someone who already clicked that they landed in the right place. They should agree on subject and promise, not on wording, and we went through that relationship in matching your title tag to the landing page headline.

Two habits to drop:

• Using an H1 for the site logo in the header. Every page on the site then shares one H1, your brand name, and the real page title sits a level down.
• Using an H2 for the page title because the H1 style looked too big. Size is a CSS problem. Never pick a heading level for its font size.

Descend one level at a time. H1, then H2, then H3 under that H2. Coming back up can skip freely, so an H4 followed by the next H2 is correct, because closing several sections at once is normal. Going down cannot skip.

What breaks when you jump from H2 to H4 is more specific than the usual warning that search engines get confused:

Accessibility is where the damage is real rather than theoretical. Screen reader users navigate long pages by pulling up the heading list and moving between levels, which is why the W3C Web Accessibility Initiative page structure guidance treats a correct hierarchy as a primary navigation mechanism, not decoration. For how that overlaps with search behavior, see accessibility as search experience.

To check your own page, open the browser console and run:

document.querySelectorAll("h1,h2,h3,h4,h5,h6").forEach(function (h) {
  console.log(h.tagName, "|", h.textContent.trim().slice(0, 70));
});

Read the tag column top to bottom. Every downward step should be exactly one. Fifteen seconds per page, and it finds most of what a crawler would flag.

The strongest change most long pages can make is also the least glamorous: rewrite each H2 as the question a reader would type, then answer it in the first sentence below it.

Two guardrails so this does not slide into stuffing. Not every heading needs a question mark: "How the tracking works" is fine, and twelve consecutive questions read like a quiz. And do not repeat the primary keyword in every H2. Once in the H1 plus once or twice across the H2s is plenty; past that you are writing for a parser that stopped rewarding it a decade ago.

The test: read only the headings, in order, and nothing else. If you cannot tell what the page argues from that alone, your headings are labels and not signposts.

Anchor text is a promise about the destination. Screen readers read it out of context when listing every link on a page, and it is the main thing a crawler has to categorize a URL it has not fetched yet.

Exact-match anchors are where sensible advice turns into superstition. Using the destination page target phrase once or twice is natural writing. Using the identical phrase for all fourteen internal links pointing at that page is not something a human writer produces, and it is the pattern link-spam systems are built to recognize. The backfire is usually not a penalty, it is a flattening: every link says the same thing, so none of them tells anyone which aspect of the page you meant. Vary the anchor to match what the surrounding sentence is about.

One widely repeated claim to be careful with: that when a page links twice to the same URL, only the first anchor counts. Testers have reported that behavior for years, but no search engine has documented it, and it is not something to build an internal linking system around. Put links where the reader needs them and stop building rules on folklore.

There is no documented limit. The old guidance to keep a page under roughly a hundred links was removed from Google Search Central documentation years ago, and the current crawling and indexing documentation cares about whether links are crawlable at all, meaning real elements with real href attributes, rather than about counting them.

The practical constraint is reader attention. A working range for a two to three thousand word page is one contextual internal link per two hundred to three hundred words, so eight to fifteen on a long page, plus whatever navigation, breadcrumb and related-post modules the template adds. That is a planning figure and an example range, not a published standard.

Placement matters more than count:

The failure mode on long pages is bunching: two links in the intro, none for nine hundred words, then eleven in a related-reading block at the bottom. Body links get clicked because they arrive at the moment of curiosity. Bottom-block links get clicked by whoever reached the bottom, which on a long page is a minority of the traffic.

A rule that has held up well: if you catch yourself explaining a concept in one line because the full explanation would derail the section, that sentence is where the link goes. The link does the work the digression would have done.

Every internal link on a long page does one of three jobs, and naming which one keeps the structure from drifting.

• Down to detail. The page mentions a subtopic in a sentence and the link goes to the page covering it properly. This is how a long page avoids becoming an infinitely long page.
• Up to a hub. The page belongs to a cluster and the link goes to the category or pillar page listing that cluster. This is the link most often missing, because writers add it once in the template and never in the body.
• Sideways to a sibling. Two pages cover adjacent decisions and a reader choosing between them benefits from both.

State the hub relationship in two places: in prose, as a body link, and in machine-readable form. A breadcrumb trail is the cheapest way to declare the parent relationship to a crawler and it renders as a real navigation aid at the same time. The markup is straightforward, and we walked through it in breadcrumb and organization schema. If the crawl-and-index layer under all of this is unfamiliar, what technical SEO actually covers is the wider map.

Long pages get this wrong on depth. A page four clicks from the home page with one internal link pointing at it is discoverable in theory and neglected in practice. Aim for anything you care about to sit within three clicks of a hub and to have more than one route in. The second route keeps it alive when you restructure the first.

An orphan page exists, resolves, appears in sitemap.xml, and has zero internal links pointing at it. It is the purest version of the problem this article is about, and it is common on sites that have published steadily for a couple of years.

It matters because a sitemap is a hint, not an instruction. Google sitemap documentation is explicit that inclusion does not guarantee crawling or indexing. Internal links are the stronger signal, because a link is a statement that the destination is worth reaching, made by a page that already has standing. A URL appearing only in an XML file is a URL nothing on your site vouches for.

Find them by comparing lists that should match and usually do not:

The mechanical version in a crawler such as Screaming Frog: run a standard crawl, enable list mode against your sitemap, then run crawl analysis to produce the orphan URL report. The set difference is your worklist. Sort it by whether the page is worth keeping, then give each survivor two contextual internal links from relevant pages, or remove it from the sitemap and let it go.

Check one adjacent failure at the same time: pages that are linked and crawled but still not indexed, which is a different problem with different causes. We covered that in crawled but not indexed.

Pick the page with data rather than instinct. Open Google Search Console, go to Performance, then Search results. Set the date range to Last 3 months. Switch to the Pages tab and sort by impressions, then filter to pages with high impressions and average position between 5 and 15, because a search engine already treats those as relevant and readers are not choosing them. Take the longest one.

Switch to the Queries tab with that page still filtered and export the top fifty queries. Read them beside your heading list. The question you are answering: does every query cluster in that export have a heading that matches its phrasing? On most long pages, two or three clusters have no corresponding heading anywhere, and one existing heading matches nothing anyone searches. That is your rewrite list, and it took ten minutes.

The rest of the pass, in order:

1. Run the heading dump snippet from the nesting section. Fix any skipped level and any heading tag applied to something that is not a section.
2. Confirm one H1, and that it agrees in subject with the title tag.
3. Rewrite the headings that matched no queries into the phrasing the export showed.
4. Check every table of contents anchor resolves. Broken anchors fail silently.
5. Count contextual body links. Under six on a page over two thousand words, place the missing ones at the sentences where a concept is glossed over.
6. Check the page links up to its hub in the body, not only in the breadcrumb.
7. Check the page itself is not an orphan.

A measurement design that will tell you something. Do not change the whole site at once, because then you cannot attribute anything.

• Baseline: 28 days before the change, exported per page from Search Console, plus scroll depth or section engagement from analytics if you have it.
• Change set: ten long pages. Headings and internal links only. No title tags and no meta descriptions, because changing the title changes the click decision and contaminates the result.
• Control set: ten comparable long pages, matched roughly on impressions and topic, deliberately untouched.
• Wait: 28 days after recrawl, not after publishing. Check the last crawl date in the URL Inspection tool before starting the clock.
• Read: average position, impressions and clicks for both sets, plus the toc_jump events if you added them.
• Signal versus noise: across ten pages, a change smaller than the seasonal drift in your control set is noise. If control drifted 6 percent and the change set moved 7 percent, you learned nothing. Those are example figures; use your own control drift as the threshold.

Be honest about what this experiment can show. Cleaner headings and better internal links mostly move engagement and navigation, and any search visibility effect is indirect and slow. What you should expect is a page people can use plus better passage-level quotability. Anyone promising a position jump from a heading change is selling something.