Brand Extractors·3 min read

Reading Site Structure From a Sitemap Tree View

Inheriting a website nobody documented is a rite of passage, and the fastest orientation exercise costs nothing: the site's own sitemap.xml already lists every page it wants indexed. Reading site structure from a sitemap turns that flat file into a map of sections, sizes, and depth, no crawler required. The Sitemap Visualizer renders the XML as a collapsible tree in seconds. This piece covers how to read the tree, what depth and orphan patterns mean, and the file-format rules worth knowing.

Open the tool All insights

The sitemap tree as an X-ray of a site

Structure hides in plain sight.

A sitemap is a machine-readable confession: here is everything we publish. Reading it as XML tells you almost nothing, because two thousand loc lines in arbitrary order have no shape. Group those same URLs by path segment, though, and the site's skeleton appears: which sections exist, how big each one is, how deep the content sits.

That view answers real questions fast. Where did the old agency put the landing pages? Is the blog 40 posts or 900? Does the site have a /es duplicate tree someone half-launched in 2021? One glance at the tree, versus an afternoon of clicking.

Reading site structure from a sitemap, step by step

From flat file to folded tree.

The Sitemap Visualizer takes a domain, appends /sitemap.xml if you didn't paste a full XML address, extracts every loc entry, and splits each URL's path into segments. Segments become nested branches, so /shop/planters/ceramic files under shop, then planters, then ceramic.

The first two levels open by default, counts sit beside every branch, and each leaf links to its live page. Start by scanning the top-level branches and their counts, that's the site's table of contents, then expand whichever branch your project actually concerns.

A worked sitemap tree walkthrough

1,240 URLs, four findings.

Load a garden retailer's sitemap and the top level reads: /shop with 860 URLs, /journal with 310, /guides with 58, and 12 loose pages at the root. Expanding /shop shows /planters, /tools, and /seeds, with paths reaching /shop/planters/ceramic/small-terra-pot.

Four findings in one look: commerce dominates the site five to one over content, the journal is a serious archive rather than a token blog, guides are underdeveloped relative to everything else, and product pages sit four segments deep. That's an information architecture summary a stakeholder can read, generated from one public file.

Depth and orphan sections in the sitemap tree

The two patterns worth hunting.

Depth and orphan sections are what the tree exposes best. Depth first: when a branch nests five or six segments, ask whether users can actually click their way down there. URL depth and click depth aren't identical, but they correlate, and pages buried that far usually earn little internal linking and less crawl attention.

Orphan candidates look different: a branch full of pages that the site's navigation never mentions. Old campaign folders, staging leftovers, and abandoned locale trees all show this signature. The sitemap proves the pages exist; a quick check of the nav proves nothing points at them anymore.

Sitemap size limits and index files

The protocol's fine print.

The sitemap size limits are fixed by protocol: 50,000 URLs or 50 MB uncompressed per file, whichever comes first. Sites that exceed either limit split into multiple sitemaps and publish a sitemap index that lists them.

When you load an index in the visualizer, its loc entries are themselves .xml files, so you'll see child sitemap addresses rather than pages. That's not a bug, it's the index's actual content. Copy the child sitemap covering the section you care about and load it directly to get page-level branches.

Mistakes when reading a sitemap tree

The tree is only as truthful as the file behind it, so keep these in mind.

Assuming the sitemap equals the site. It lists what the owner chose to submit; pages can exist outside it and entries can 404.
Reading URL counts as importance. A branch of 800 thin tag pages outweighs nothing.
Forgetting the file may be stale; sitemaps generated by a cron job that died last year still look authoritative.
Confusing sitemap structure with navigation. The tree shows URL paths, not the menus users travel.

Tips for sitemap structure audits

Check robots.txt first, since it names the real sitemap location and often reveals several: page sitemaps, image sitemaps, news feeds. Auditing the wrong one wastes the exercise.

Then compare the tree against the site's main navigation side by side. Sections present in the tree but absent from the nav are your orphan shortlist, and sections in the nav but thin in the tree show where the site promises more than it publishes.

Sitemap Visualizer vs related tools

Reading, writing, and the page level.

The Sitemap Visualizer reads structure that already exists. When you're producing the file instead, the XML Sitemap Generator builds a valid sitemap from your URL list. The Robots.txt Reader pairs naturally with both, since robots.txt is where sitemap locations get declared. And once site-level structure looks sane, the Headings Tree applies the same tree thinking one level down, to the outline inside a single page.

Try it now

Open Sitemap Visualizer

The tool is one click away. No sign up, no upload, no payment.

Open Sitemap Visualizer

Write a review