HTML Sitemaps: Do You Still Need One?

An HTML sitemap is a normal page on your site. It has a URL, it loads in a browser, and it contains a list of links to your other pages, organized however you choose. That is the whole thing. No submission process, no ping to a search engine, no special file format. Anyone can click it, including a crawler that follows links the way it follows any other link on the web.

That is also exactly how it differs from an XML sitemap, and the confusion between the two is why the question "do you still need one" keeps coming up. An XML sitemap is a machine-readable list of URLs (plus optional metadata like last-modified dates) that you submit to Google Search Console or reference from robots.txt. It tells a crawler these URLs exist, but it adds no links to your site's actual link graph, because nobody clicks a line in an XML file. An HTML sitemap does the opposite: it is a real page with real anchor links, so it changes how deep or shallow a page sits in your internal linking, not just what a crawler knows about. For most modern sites with clean navigation, that no longer matters much. For a specific set of sites, it still does, and knowing which category you're in is the actual question worth answering.

What an HTML Sitemap Is For

An XML sitemap is a hint. It tells Google's indexing systems which URLs you consider canonical and worth crawling, and it can flag when something changed. Google has been explicit that inclusion in an XML sitemap does not guarantee crawling or indexing, and it does not by itself pass any link authority, because the format has no concept of links in the internal-linking sense. It is a discovery signal aimed at crawlers, submitted through a side channel most human visitors never see.

An HTML sitemap is aimed at both crawlers and people, but its mechanism of action is entirely different: it works because it is a page with outbound links on it. When a crawler renders that page, it finds every URL listed on it the same way it finds a link in your main navigation or footer. If a page was three clicks from the homepage before, and the sitemap page (itself linked from the footer) links directly to it, that page is now effectively closer to the surface of your site's link structure. That is the entire value proposition, and it has nothing to do with the file being for Google. It works precisely because it behaves like any other page with a list of links.

The secondary use, and the one that predates modern SEO entirely, is human navigation. Before faceted search and mega-menus were standard, an HTML sitemap page was how a visitor who got lost found the page they wanted. That use case is smaller than it used to be on most sites, but it hasn't vanished: support portals, documentation sites, and large catalogs still get real traffic to a page titled Sitemap, from users who typed the word into on-site search or who simply scroll to the footer looking for an index.

The Cases Where It Still Earns Its Keep

The sites where an HTML sitemap genuinely changes outcomes share a common shape: important pages exist, but the normal path to them is long, broken, or inconsistent, so the underlying problem an HTML sitemap fixes is always the same one, a missing or unreliable direct link. A few recurring patterns show up again and again:

• Deep catalogs. An ecommerce site with categories, subcategories, and then products can bury a product several clicks below the homepage. If category pages paginate weakly or filter navigation hides most of the catalog behind JavaScript state that isn't in the raw HTML, a sitemap that lists every category, and at a coarser grain links to sub-sitemap pages for products, shortens that distance.
• Post-migration sites. After a re-platform, redesign, or CMS switch, it's common for old internal links to break or for a new navigation to surface only a fraction of existing content. Pages that used to be two clicks from the homepage can end up unreachable except by direct URL or search. An HTML sitemap rebuilt from your URL inventory re-establishes paths to everything while you fix navigation properly.
• Sites with weak or siloed internal linking. If your CMS generates pages, a documentation set, a knowledge base, a large tag or archive structure, without deliberately cross-linking them, plenty of pages end up with only one inbound link, or none. That single inbound link being broken, or the parent page itself being weakly linked, orphans the child.
• JavaScript-heavy sites where the primary navigation renders client-side. If your main menu is built by a script that doesn't run the same way for every crawler pass, a plain HTML sitemap page, a server-rendered list of anchor tags with no client-side dependency, is a reliable fallback path that doesn't depend on script execution succeeding.
• Large sites approaching crawl budget limits. On sites with tens of thousands of URLs, how efficiently a crawler finds your important pages affects how much of its visit gets spent on them versus on low-value URLs. A sitemap page that groups and links directly to your priority sections helps a crawler reach them without wading through low-value intermediate pages first.

How to Tell If Orphaning Is Actually Happening on Your Site

Before adding a sitemap page, check whether the problem it would solve actually exists, because building one for a site that doesn't need it just adds a low-value page to maintain, and if none of the checks below turn up a gap, you almost certainly don't need one.

• Compare your CMS's full URL export against what Search Console's Page Indexing report lists as indexed. A meaningful gap between pages that exist and pages Google has indexed is worth investigating before assuming a sitemap page will fix it; plenty of gaps are caused by noindex tags, a canonical pointing elsewhere, or thin content, none of which an HTML sitemap addresses.
• Check whether your important pages are reachable by following links only, starting from the homepage, without typing a URL directly. If you have to search or dig through pagination to reach a page you'd consider a priority, a normal visitor and a crawler will have the same trouble.
• Look at how a page acquired its inbound links. A page linked only from one place, a single blog post, a single filter combination, is one broken or removed link away from becoming unreachable.
• Review your crawl stats for how much of the crawler's activity lands on low-value URL patterns, filtered or faceted variants, session parameters, paginated pages deep in a series, versus your actual priority pages. If most crawl activity goes to variants nobody wants indexed, a sitemap page that links priority pages directly can redirect some of that attention.

When It Backfires

An HTML sitemap can also make things worse, and the failure modes are specific enough to name.

• Link dilution on a single page. There used to be a widely cited rule of thumb about keeping the links on a page under roughly a hundred. Google no longer states a hard limit, but the underlying mechanism it was describing hasn't changed: a page's outbound links each get a smaller share of that page's link equity as you add more of them, and a crawler treats an enormous, undifferentiated link list with more suspicion than a curated one. A sitemap page listing every one of ten thousand product URLs, flat, with no grouping, reads to both a user and an algorithm like a doorway page rather than a navigation aid.
• Staleness. A sitemap page that's hand-maintained or generated once and forgotten will drift from reality: it links to pages that have been removed or redirected, and it misses everything created since. A stale HTML sitemap actively creates crawl errors and dead ends, which is worse than not having one.
• Listing pages that shouldn't be indexed. Pulling every URL from your database without filtering means your sitemap page may link to admin pages, thank-you pages, internal search results, or anything else you've deliberately noindexed or blocked elsewhere. Linking to it undercuts the reason you excluded it in the first place.
• Treating it as a substitute for fixing navigation. An HTML sitemap patches a symptom. If your actual site architecture buries pages, the sitemap becomes a permanent workaround instead of a prompt to restructure categories, add contextual internal links, or rebuild a broken menu. Sites that lean on a sitemap page for years usually have an underlying architecture problem that never got fixed.
• Orphaning the sitemap page itself. If the link to it only lives in the footer of some templates but not others, or the page isn't linked from anywhere consistent, it becomes exactly the kind of hard-to-reach page it was built to prevent.

Building One That Doesn't Become a Liability

If you've confirmed a real orphan-page or deep-architecture problem, the version of an HTML sitemap that helps without the downsides above has a few concrete traits:

• Group by structure, not by a flat alphabetical or chronological dump. Mirror your actual category hierarchy: a top-level sitemap page links to section pages (by category, by content type, by date range for something like an archive), and each section page links to the individual URLs within it. This keeps any single page's link count reasonable and keeps the structure legible to a reader who's actually trying to find something.
• Link only to canonical, indexable URLs. Pull from whatever list represents pages you want indexed and reachable, not a raw database dump. If a URL is noindexed, redirected, or canonicalized elsewhere, it doesn't belong on the sitemap page.
• Regenerate it on a schedule that matches how often your content changes, and make regeneration automatic rather than manual if your CMS allows it. A sitemap page is only as useful as it is current.
• Link to it from a permanent, sitewide location. The footer is the conventional choice precisely because footers render on every template, which guarantees the sitemap page is never more than one click from any page on the site.
• Keep it server-rendered plain HTML. Its entire value for crawlers rests on being link-graph content that doesn't depend on script execution, so building it with the same client-side framework that's causing your discovery problem elsewhere defeats the purpose.
• Treat it as a bridge, not a fix. Use it to solve the immediate reachability problem while you address the actual cause, thin cross-linking, a menu that only shows top-level categories, pagination that buries older content, because fixing that reduces how much your site depends on a manually maintained page to stay discoverable.

The Bottom Line

The honest answer to "do you still need one" is: not by default, and not as a permanent architecture decision. But on a site large or deep enough that pages routinely fall out of reach of normal navigation, a well-scoped, well-maintained HTML sitemap is still one of the more direct fixes available, and it costs little to build once you've confirmed the problem it's solving is real.