HTML vs XML Sitemaps for Magento: A Practical Checklist
Two maps, two different jobs
An HTML sitemap is a page people can browse. An XML sitemap is a machine-readable list you make available to search engines. A Magento store can use both: one helps a visitor find useful destinations, while the other provides a discovery signal for the canonical URLs you want considered for search.
Neither fixes a broken destination, overrides a noindex instruction or guarantees indexing. The practical task is to make both maps agree with the current storefront rather than publishing every URL the database contains.
| Question | HTML sitemap | XML sitemap |
|---|---|---|
| Who uses it? | Visitors following labelled links, and crawlers that encounter those links. | Search engines processing a sitemap file. |
| What does it look like? | A normal page with useful groups such as products, guides and support. | Structured URL entries in XML, or a sitemap index linking to sitemap files. |
| Where should I link it? | A visible navigation or footer link where visitors can find it. | Use the appropriate search-engine submission tools and a sitemap reference in robots.txt. |
| What should I test? | Readable labels, useful grouping and working destinations. | Valid output, canonical public URLs and accurate modification information where supplied. |
A worked example: one shop, several URL types
Imagine a shop with a product, an installation guide, a sign-in screen and an old offer. These are illustrative paths, not instructions to create pages with these names.
| Destination | HTML decision | XML decision |
|---|---|---|
| /trade-drill-kit | Link under the relevant product group if it helps navigation. | Include the canonical product URL if the page is intended for search. |
| /guides/choosing-drill-bits | Link under buying guides. | Include the canonical guide URL if it is useful and indexable. |
| /account/login | A sign-in link may be useful to visitors. | Keep a utility page out of the search-discovery list when its intended policy is noindex. |
| /old-summer-offer | Remove the obsolete link. | Remove the retired URL. Use a relevant replacement only where one actually exists. |
| /product/old-drill-alias | Link straight to the preferred product destination. | List the preferred canonical URL rather than a redirecting alias. |
This is why the two maps need not contain exactly the same links. A useful account link can belong in navigation without becoming a search landing page. Conversely, a large XML product inventory may be unwieldy as a single page for people.
Check XML generation in the deployed storefront
Adobe's site-map documentation covers Magento sitemap configuration and generation. In a headless setup, also establish which system publishes the public sitemap: Magento, the frontend or another service. Check the file visitors and crawlers actually receive on the storefront domain.
For a small example, a URL entry might look like this. Replace the example domain and path with the actual canonical destination; this is a format illustration, not a complete Magento configuration.
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://shop.example/trade-drill-kit</loc>
</url>
</urlset>
Use absolute canonical URLs. If you publish lastmod values, they should represent meaningful updates rather than the time a routine build happened. Google's sitemap guidance explains supported formats and submission; it also states that submitting a sitemap does not guarantee crawling or indexing.
Build the HTML map around the visitor's task
Choose useful headings and link labels. A merchant with a small catalogue might list products directly; a larger store may prioritise categories and important guides rather than presenting thousands of links at once. Keep support, documentation and commercial information easy to distinguish.
The AgenticEcom HTML Sitemap product and its configuration guide describe its grouped output and controls. For a headless frontend, review the guide's GraphQL and URL-prefix settings against your actual routes. The HTML sitemap module is a navigation feature; it is not a replacement for checking XML generation or search-engine reports.
A repeatable review after a catalogue change
- Pick representative URLs. Include an active product, a useful guide, a redirect and a retired page. Record what each should do.
- Open the public destinations. Compare status, visible content, canonical tag and indexing policy with your intention.
- Inspect both maps. Look for old domains, API hostnames, redirecting aliases, retired offers and missing useful destinations.
- Check the headless route mapping. A correct product identifier with the wrong route prefix is still a broken visitor journey.
- Refresh the generated output. Use the site's documented generation and cache process, then check the public result again.
- Review discovery reports later. Separate a successful sitemap fetch from actual URL indexing. Investigate the reported reason for each commercially important exclusion.
How to use our site as an example
Compare AgenticEcom's HTML navigation sitemap with its XML sitemap. The navigation page groups useful destinations, including the documentation hub and visual storefront demos. Those demo storefronts deliberately use noindex and cannot take orders; a link to them for visitors does not mean they should be included as indexable product pages.
Use the example to plan a map for your own content, then verify your own output. The goal is a coherent set of working destinations, not a larger URL count or a promised ranking improvement.
