What a fragment identifies
In /services/#consulting, /services/ identifies the document and #consulting identifies a destination within it. A matching element, often a heading with id="consulting", gives the browser a place to scroll to. The HTML Standard’s fragment navigation rules describe how navigation can bring the indicated part of a document into view. A visitor can share the full address as a useful starting point for a colleague.
The destination remains part of the same document; it has no separate page body, title, or independently authored search snippet. Treat a fragment as a reading position, not a miniature landing page.
Use a fragment for a section, not a second page
Ask what the destination represents, not whether it looks like a tab. If readers should discover the material on its own, link to it from another site, or see a different title and description, it is probably a separate resource. Give it a path such as /services/consulting/ and make that route load the intended content. If the destination is a subsection of a broader service guide, #consulting is a sensible jump target.
For example, a pricing page can use #annual plans to skip to a comparison while retaining the context above it. Google’s URL structure documentation cautions against using fragments to change page content. That is a crawlability recommendation, not a claim that ordinary heading links are harmful.
Distinguish section links from interface state
A hash may represent application state, but that does not make every state a section destination. A link from /catalog/#/shoes that replaces the page with a shoe category uses the fragment as an application route. Google’s JavaScript SEO guidance advises using the History API instead of fragments to route between distinct views. Use paths such as /catalog/shoes/ and /catalog/bags/ when each category is a meaningful page.
A real path can be shared, linked, loaded directly, and handled by the server or application router. For a tab that reveals details within one document, use an accessible control and do not assume a changing hash gives each panel separate search visibility.
Design IDs that readers can keep using
Add an id where it solves a navigation problem: a contents list, a support answer pointing to a remedy, or a section customers often revisit. Make it unique, readable, and tied to meaning. Names such as setup, refund policy, and annual pricing are clearer than generated values such as section 4. Avoid changing established IDs during routine editing, because bookmarks, emails, and external links may depend on them. If a heading changes but its destination remains useful, keep the id.
When a migration is necessary, update internal links and test old shared URLs rather than silently abandoning a frequently used anchor.
Make jump links understandable and accessible
A jump link should say where it goes: “Compare annual and monthly pricing” is more informative than “Go here.” Use a native anchor with an href such as href="#annual pricing", and make sure the matching id exists. A clickable span with a JavaScript handler lacks the native link behavior browsers and assistive technology expect. The Google guide to crawlable links describes the anchor and href pattern and recommends useful anchor text. Test keyboard activation and screen reader output.
A fixed header can cover the heading after scrolling; adjust the offset or spacing and verify the reading position at real viewport sizes.
Build a useful contents pattern
For a long guide, a short contents list can reduce repeated scrolling. Match its labels to the headings and link only sections that readers may want to reach directly. The target should make sense when someone lands on it, with enough nearby explanation to clarify the point. A minimal pattern looks like this:
<nav aria-label="On this page">
<a href="#annual-pricing">Annual pricing</a>
</nav>
<section aria-labelledby="annual-pricing">
<h2 id="annual-pricing">Annual pricing</h2>
<p>Explain the annual option and its conditions.</p>
</section>Route separate views so they work on direct load
A client side application should work when a visitor opens a route directly, not only after starting at the homepage. If /catalog/shoes/ is a real view, a fresh request should return the page or application shell and restore the intended content. Use links where possible; the router can update the address and browser history through the History API. Handle back and forward navigation, page titles, and not found states too. Google describes crawl, render, and index stages, while noting that rendering is not instant.
Server rendered or pre rendered content can help visitors and systems that do not execute scripts. For more on clear page structure, see content formatting for language models.
Test the behavior, not just the markup
Before release, test a link click and a fresh load of a copied URL ending in #annual pricing. Confirm the page loads, the target exists, the browser reaches it, and a fixed header does not obscure the heading. Try keyboard activation and the back button. Paste each distinct route into a new tab and verify the right view appears without prior navigation. Check that essential content and links exist in the rendered page.
A compact review: confirm contents links match unique IDs; open shared fragment URLs directly; verify route titles and not found handling; and revisit links after renaming headings. This is useful during client navigation migrations or when splitting a broad guide into focused resources.
What fragments can and cannot do for SEO
A fragment can make a long page easier to navigate and help someone share a relevant passage. Those usability benefits stand on their own. Do not describe a fragment as a way to multiply indexable pages, guarantee a passage ranking, or secure an AI answer citation. The primary documentation explains URL and link behavior; it does not promise a ranking benefit from adding IDs. Keep the parent useful as a whole, and give material that deserves its own search destination a crawlable route.
For broader context, see the AEO implementation hub, the guide to answer first content, and the structured data definition. Structured data can describe visible content, but it does not make a fragment a separate document.
Key takeaways
- Use #section name to reach a location within one document, not to create another search page.
- Give independently useful views distinct paths and support direct loading and browser history.
- Keep IDs unique and stable; use descriptive native links that work for keyboard and assistive technology users.
- Judge fragments by navigation value, not promised rankings, indexing, or answer citations.
Frequently asked questions
Can a fragment identifier rank as its own page?＋
Do not plan for it as a separate page. A fragment points into the document identified by the path. Google says it generally does not support fragments used to change page content. Create a route when material needs its own search destination.
Should every heading have an ID?＋
No. Add IDs where readers benefit from a contents link or shareable destination. Keep each unique and stable. There is no documented ranking guarantee for adding an ID to every heading.
Can an application use a hash for tabs or navigation?＋
An application can use a hash for interface state, but Google advises against using fragments to load different page content. Use real paths and History API routing for separate views, then check that each path works when opened directly.
Do fragments help answer engines cite a specific passage?＋
A fragment makes a passage easier for a person to share and revisit. The cited primary documentation does not promise it will make an answer engine select or cite that passage. Focus on accurate, useful content and a working page structure.