How We Preserve Section Links for AI Search

A page-level method for keeping shared URL fragments landing on the same evidence after heading edits, CMS template changes or section moves. It separates page reachability from in-page location, explains how an element ID determines the browser’s landing target, recommends retaining stable identifiers while meaning holds, proposes a handoff table of old fragments and intended targets, and keeps browser landing checks distinct from any claim about crawling, indexing or AI citation.

Test the section as well as the page

A shared reference link can keep opening the right page and still lose the passage it once pointed to. The page loads, the reader sees the top of the document, and the sentence someone meant to cite is somewhere below. That is not a broken URL. It is a broken in-page location, and it needs a different test.

The HTML navigation algorithm looks for an element ID equal to the fragment. When that matching step fails, the surrounding algorithm can return no indicated element, so the browser has nothing specific to scroll to. The practical consequence is that a fragment is only as stable as the identifier it names.

Keep the scope narrow. The object under test is an author-defined element anchor inside one page and the evidence it was meant to mark. Text fragments, citation formatting, and whether a base URL redirects are separate questions that this check does not answer. A redirect can send the reader to the correct page and still drop the fragment, and a citation that returns a page proves nothing about which section the reader lands on.

So the first question is not whether the link works. It is whether the link still lands where it used to. Those are two different results, and only the second one tells you whether a previously shared reference still points at its evidence.

Source reference

Keep a section identity when the heading changes

When we edit a heading, we check what happens to the ID. The browser matches an element ID rather than the visible heading text. If a rewrite preserves the ID and the passage meaning, the reference can remain valid. If a template rebuild changes or removes the ID, open the original link to verify where it lands.

Our recommendation is to treat the identifier as a separate editorial asset from the heading copy. If the section still carries the same meaning, keep its existing ID even when the visible heading is rewritten, and confirm after publishing that the ID survived the template. If the meaning has genuinely moved to a different section, point the old fragment at the new location deliberately rather than leaving a stale ID on unrelated content.

Two failure modes are worth naming because both look like fixes. With duplicate IDs, the browser’s matching step can select the first element even when the editor intended another one. Arbitrary aliasing is the other: attaching an old fragment to whatever section happens to be nearby so the link stops looking broken. That preserves the appearance of a working reference while sending readers to evidence that no longer supports the original claim. When the evidence has been removed, the honest outcome is a recorded gap, not a redirected fragment.

Keep a map of old fragments and intended targets

Editors and developers need a shared record before a heading, template or page structure changes. The table below is a proposed template: it names the fields to fill for each shared fragment and is deliberately empty of sample values, so no invented reference is mistaken for a real one.

Original URL and fragment	Intended passage	New location	Meaning still equivalent?	Observed landing
The full shared link, including the fragment	The evidence the fragment was meant to mark	Where that evidence now sits, or that it was removed	Whether the new target supports the same claim	Where the browser actually lands after publishing

Fill the row from the original link, not from memory. The intended passage is the claim the fragment was shared to support, which is often narrower than the section it sits in. The new location should name the specific target, and the equivalence column is the one that decides whether keeping the old fragment is honest. The observed landing column stays empty until someone opens the link in a browser after the change.

The map is also where a split or collapse becomes visible. When one section becomes two, the old fragment can only follow one of them, and the other needs its own identifier if it is to be shared. When a section is removed, the map records the removal instead of quietly reassigning the fragment.

Open original links in a browser after publishing

After publishing, open each original shared link in a browser and look at where it actually lands. The check is visual and specific: does the viewport sit on the intended passage, and does the surrounding text still support the claim the link was shared for? A link that opens the page at the top has failed this test even though the page itself loaded.

Compare what you see against the intended passage recorded in the map. If the browser lands on a different section, compare the actual target with the map and inspect its identifier. If it lands on nothing specific, inspect whether the fragment matches an element and whether that element and its surrounding evidence are visible. Record the observed landing in the map rather than fixing it silently, so the next editor can see what changed.

Keep this separate from a base-URL status check. A response confirming the page exists says nothing about the fragment, and a redirect that preserves the page can still drop the reader at the top. Use a browser to verify the reader’s actual landing and a markup inspection to investigate the target when the landing fails.

Splits, removals and collapses each need their own verdict. A split section may leave one fragment correct and the other orphaned. A removed section leaves a fragment with no honest target. A collapsed section may have merged its evidence into a larger block, in which case the fragment should point at that block only if the merged text still supports the original claim.

Report which shared references still resolve correctly

The outcome to report is narrow and navigational: which shared fragments still land on their intended evidence, which now land elsewhere, and which have no equivalent. That report is useful to editors and to anyone who shared the links, and it is honest about what was and was not checked.

It does not establish that a search engine will crawl, index or cite the section. The cited search guidance advises making important content available in textual form, but that is a statement about content presentation for the cited search service, not a demonstration that a stable fragment produces visibility or a citation. A working section link and an AI citation are different outcomes, and one does not prove the other.

Where the work extends beyond the fragment check, SHMLANG publishes a CMS-ready publishing structure as part of its website systems scope, where editors can account for stable identifiers during template changes. SHMLANG also describes a GEO method that uses question baselines and approved business facts, and that method is a separate review from the browser landing test described here.

For teams planning the surrounding page and link work, the related reading on GEO website architecture covers page inventory, crawl prioritization and internal link flow, which sit alongside this fragment check rather than replacing it.