Sitemap HTML template: keep the route and the page identity together

The Library page is renamed, but the site map still lists library.html. A tidy list hides the mismatch until someone follows the link.

Start with a route inventory and carry the page identity through the rename.

This sitemap HTML template gives you four content entries plus one separate utility route. Its self-contained review shows the planned navigation and a proposed Library rename, with selectable HTML markup you can copy into the actual project. It keeps destination and return-link checks untested because this example does not contain the four target pages.

Four pages. One route inventory.
Four pages. One route inventory.
Open the full example ↗

Build the inventory first

The fictional same-directory project has P01 Home at index.html, P02 Library at library.html, P03 Events at events.html, and P04 Contact at contact.html. The human-readable site map is sitemap.html. That utility does not turn four content pages into five content pages.

Organize links under Home, Resources, Events, and Contact. The Resources section contains the Library label. A descriptive label can differ from its filename; confirm it against the actual page title rather than renaming content just to resemble a route. Keep each P01–P04 identity stable as targets change.

Use actual anchors in the project markup

The generated snippet uses navigation headings and real anchor href values from the inventory. It is selectable HTML, not a pretend button that claims to open an absent page. Copy it into the actual site-map page, then build or locate its target pages in the same serving context.

The on-page outline links only to the review's own P01–P04 sections. Those sections show planned target and return routes, so the standalone file remains useful without pretending it hosts the multi-page site. The navigation markup intended for your project is kept in a separate labeled text area. Neither a snippet nor an internal jump verifies an external destination.

Test both directions

W3C's G63 technique discusses a site map as an overview with links, and includes destination, return-link, and reachability checks. Use those checks to inspect the maintained site. W3C techniques are examples of ways to address accessibility needs; this four-page design alone establishes no conformance claim.

For each content route, open the site-map destination in the actual site, confirm the expected content, and follow its Site map return link to sitemap.html. Record the version, target, actual result, and unresolved issue. Confirm all four maintained content pages are covered and labels remain useful. The review leaves those operational results not_tested.

Inspect the proposed rename

Choose Propose resources.html. P02 remains Library, but its planned target changes to resources.html in both the inventory and generated snippet. The old library.html route is flagged unresolved; no redirect is invented. Return to Original route to inspect the starting plan.

The rename also calls for checking the actual renamed page, its return link, and affected navigation references. A planned filename is not a tested route. Keep this human navigation page distinct from an XML crawler sitemap. It makes no indexing or ranking promise. After applying the markup to the real project, update the native link checklist with actual findings rather than changing untested labels merely because the plan looks complete.

Copy this prompt to adapt the example

Design a clear page-directory review with a route inventory, real on-page navigation, and selectable navigation markup for the four proposed destinations. Return one self-contained HTML file with embedded styling and working interactions. Use readable type, strong contrast, clearly labeled keyboard controls, and a layout that flows on a narrow phone. Identify the supplied data as a fictional example.

Prepare a single self-contained human-readable sitemap planning review, not an invented multi-page site. Inventory P01 Home index.html under Home, P02 Library library.html under Resources, P03 Events events.html under Events, P04 Contact contact.html under Contact. Separate utility sitemap.html. Count four content pages and one utility. Show route identity, label, target, planned return link sitemap.html, and destination/return checks not_tested.

Provide an internal section navigation using real anchors to the four on-page review sections, and a clearly labeled readonly textarea with project-ready HTML navigation markup using the four relative target routes. Do not claim those external pages exist or were tested. Provide Original route and Propose resources.html buttons. The rename changes only P02's target in the inventory and markup, retains its Library label and identity, and flags old library.html unresolved without inventing a redirect. The return plan still points to sitemap.html. Explain target, backlink, coverage, and label checks in the actual project. No network or link testing control. Make the internal anchors usable by keyboard. Check destination pages and their return links in the actual project. Do not claim XML output, indexing, ranking, accessibility certification, site hosting, or persistence.

After copying the selected navigation markup into the project, visit each real destination and follow its return link. A proposed rename is easier to discuss when the old and new routes remain visible together; NOS can render this HTML route review for that discussion. The final check happens in the actual site, where a correct-looking inventory must still lead readers to the intended page.

Keep reading