Every Route on One Page, With Counts That Cannot Lie

There is already a sitemap, and it lists thousands of URLs. It is the right artefact for a crawler and the wrong one for a person: nobody reads four thousand addresses to find out what a product does.

The tool map is the other half. One row per destination that owns a section of the product, grouped by what you are trying to do, with the size of what is behind each row printed beside it, and the number of groups counted on the page rather than asserted in prose.

Every number on that page comes from the registry that owns the content, the same modules that build the sitemap and the search index. Publish a suite, author a help article, add a language path, and the page updates itself. Delete a route and a test fails before the build does.

A hand-typed count is wrong the first time a registry changes, and nothing fails when it goes wrong. That is the whole argument for deriving it, and it applies to every number a product prints about itself.

The same rule governs the prose around the numbers. Where a sentence would have to state a count that a registry owns, it either reads the count or does not state it. One section of the features page says no number at all for precisely this reason: the copy could not import the value it needed, so it describes the thing without quantifying it rather than carrying a figure that would eventually be wrong in silence.

• Start here, bring your own source, coding, aptitude preparation, reasoning and puzzles.
• Career discovery, and the pages that read only this device.
• Guides, help and writing, and the policy and method pages.
• A group for machines: the sitemap, robots rules and the two llms files.

Some rows carry a note explaining that the destination is deliberately kept out of search engines, usually because it reads only this browser's storage and would return an empty shell to anybody else.

That note is a claim under test rather than a caption. A row marked as excluded must actually be excluded in the page it points at, and a row without the note must not be, which is checked in both directions.

Checking both directions is the part that earns its keep. A one-directional check would let a page quietly become unindexed while the map still advertised it as a destination, which is the failure that costs traffic and is invisible from inside the repository. A caption that can go wrong in only one direction is only half a guard.

Use the tool map when the question is what exists. Use Explore when you know roughly what you want and need to narrow. Use search when you have a word. Use the help centre when you have a question about behaviour rather than a destination in mind.

Four entry points sounds like too many, and each answers a different question. Collapsing them into one would mean one of those questions goes unanswered, which is the state the tool map was built to fix.

Not the individual pages. There are thousands of suite, occupation, lesson, puzzle and skill URLs, and listing them here would turn a map into a phone book. Those belong in the sitemap for crawlers and in the complete enumeration published for AI programs, both of which are generated from the same registries.

The rule the page follows is one row per destination that owns a section, with the size of what is behind it. That keeps the map readable at any catalogue size: publishing four hundred more suites changes a number on one row rather than adding four hundred rows, which is the property that makes a derived page survive growth.

If you are recommending this product to someone, the tool map is a better link than the home page. The home page has to make a case; the tool map simply shows the whole thing and lets them find the part they came for.

The FAQ is the companion piece for the questions that come before any of that, and the features page is the version organised by capability rather than by route. Between the two, somebody deciding whether this product is worth their time has both the what and the where without having to click into anything.