Visual Sitemap Generator That Maps Your URL Hierarchy

How the visual sitemap is rebuilt from paths alone

Every URL is split on / and each segment becomes a node. https://www.example.com/blog/seo/technical-audit creates blog, then seo underneath it, then technical-audit underneath that. A node is marked as a real page only if some URL in your list ends there.

The result is an ASCII tree you can copy into a doc or a ticket, plus a downloadable HTML version with working links:

/
├── blog/
│   ├── link-building
│   └── seo/   ← no page at this path
│       ├── technical-audit
│       └── keyword-mapping
├── pricing
└── about

Sibling nodes are sorted alphabetically, so the same input always produces the same tree and 2 runs are diffable. A trailing / marks a node with children. The flag on seo/ is the whole point of the tool.

This is inference from URL structure, nothing more. No crawling happens, no page is fetched, and everything runs in your browser. Which means the tree reflects your URL design, not your navigation. When the 2 disagree, that is worth knowing.

The gap worth finding: a segment with children and no page

/blog/seo/ in the example above appears in 3 URLs as a path component, and there is no page at it. Type it into a browser and you get a 404, or a directory listing, or whatever your framework does with an unmatched route.

That gap costs you in 3 ways:

• Every breadcrumb on those child pages links to a dead URL, if your breadcrumbs are generated from the path, which most are.
• The topic has no hub. The strongest internal-linking pattern is a hub page that links to its children and is linked from the parent. A missing segment breaks the chain, and the children are held up only by whatever links they picked up individually.
• Visitors trim URLs. Not many, but the ones who do are the ones evaluating whether the site is maintained.

The tool counts these and lists the first several by path, and shows the total as a Missing hubs stat. Most sites have a few. Sites that grew by publishing into a folder structure nobody designed have dozens.

Not every flagged segment needs a page. /2026/08/ on a date-based blog is a routing artifact and building a page for it would be silly. Read the list, decide case by case, and build the ones that name a real topic.

Crawl depth and why level 4 is the warning line

The tool charts how many URLs sit at each depth, and flags anything at depth 4 or deeper. Depth here is path segments, which is a proxy for click distance rather than a measurement of it. A page at /a/b/c/d/e linked from the homepage is one click away no matter how long its URL is.

The proxy is still useful because on most sites the 2 correlate. Pages buried several segments deep tend to be linked only from their parent, get crawled less often, and take longer to reflect edits. When you see a large population at level 4 and beyond, the question to ask is not "should I shorten these URLs" but "what links to them". Often the answer is a hub page you have not built, which is the same finding the orphan check produces from the other direction.

Also watch the shape of the distribution. One enormous section next to a dozen small ones usually means one part of the site got all the investment. A flat tree with 3 hundred nodes at level one means there is no information architecture at all, just a folder.

The 3 fields on this page

• URLs is the input, one per line. Extra columns after a | are ignored for this output, so you can paste the same list you use for the XML generator without stripping the lastmod or anchor-text columns. Lines starting with # are skipped, duplicates are removed, and fragments are dropped, since #section is not a distinct node.
• Sitemap type is preset to visual. The same input drives the standard XML, HTML, image, news, video and WordPress outputs, which is the point of keeping one list.
• Base URL resolves relative lines. Paste /blog/seo-guide with a base of https://www.example.com and the node lands in the right place. Without a base, relative lines are reported as skipped, with the reason, rather than being guessed into the tree.

If your paste spans several hostnames, you get a warning. For this output it is only advice, since the tree merges paths across hosts, and a merged tree of 2 different sites is not telling you anything true about either.

Where to get the URL list for a visual sitemap

The tree is only as good as the input. 3 sources, in descending order of usefulness:

• A crawl export. Whatever crawler you use, export the list of indexable 200-status HTML URLs. This gives you what actually exists.
• Your existing XML sitemap. Fast, and it shows what you are telling Google exists, which is not always the same set. Comparing the tree of your sitemap against the tree of a crawl is itself a good audit.
• A CMS export. Accurate for published content, and blind to anything your framework generates outside the CMS.

Whichever you use, strip out parameterized and paginated URLs first. A hundred ?page=2 variants add depth to the chart and tell you nothing about structure.

What a visual sitemap cannot tell you

It reads paths. It does not read links, so a page that is linked from nowhere still appears in the tree at its path, and a page linked from every footer looks the same as one linked from a single archive. It does not know about redirects, canonicals or noindex tags. It cannot see a navigation menu that contradicts the URL structure entirely, which is common on sites where everything lives at the root.

Use it to find structural gaps quickly, then confirm with a real crawl before you act on anything. BlazeHive automates the content side end to end, but the decision about which hub pages deserve to exist is still a judgment call worth making deliberately.