XML namespace troubleshooting

Sitemap namespace errors

The element names in an XML sitemap belong to a specific namespace. A document may contain familiar tags such as urlset, url, and loc while those elements resolve to no namespace—or to an unrelated one—and therefore do not represent the sitemap protocol vocabulary.

What the default namespace does

The xmlns attribute without a prefix establishes the default namespace for the root and its unprefixed descendants. In this example, urlset, url, loc, and lastmod all belong to the sitemap namespace:

Namespace-aware parsers compare an element's local name and namespace URI together. Visual similarity does not compensate for a missing or different URI.

Frequent namespace mistakes

The declaration is missing

<urlset> by itself creates a root in no namespace. Adding the standard declaration to the root usually fixes the whole unprefixed core tree:

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">

The URI was “corrected” to HTTPS

The standard identifier uses http://www.sitemaps.org/schemas/sitemap/0.9. Namespace URIs act as exact identifiers; they are not fetched during parsing and should not be upgraded to https. Changing the scheme creates a different namespace.

A spelling or version differs

Values such as http://sitemaps.org/schema/sitemap/0.9, .../schemas/sitemap/1.0, and a URI with an extra trailing slash do not match the protocol namespace. This often appears after a template is retyped instead of copied from a known-good generator.

A child resets the namespace

An empty declaration such as <url xmlns=""> removes the inherited default namespace for that element and its unprefixed descendants. The file may have a correct root while individual entries silently leave the sitemap vocabulary. Search the generated XML for nested xmlns attributes when only some entries fail.

A prefixed tree is bound incorrectly

XML permits prefixes, so a document can bind a prefix to the sitemap URI and use it consistently:

<sm:urlset xmlns:sm="http://www.sitemaps.org/schemas/sitemap/0.9">...</sm:urlset>

The prefix text itself has no fixed meaning; its binding supplies the identity. Default, unprefixed sitemap markup remains easier to generate, inspect, and compare with public examples.

Core elements and extension elements

Image, video, news, and XHTML alternate-language data use their own namespaces. Those declarations sit alongside the default sitemap namespace. A page entry might therefore contain core children such as loc plus prefixed extension children such as image:image or xhtml:link.

A simplified image sitemap root can look like this:

CorrectSitemap counts bounded non-core extension elements and continues checking the surrounding sitemap structure. It does not validate the image, video, news, or XHTML extension schemas. Use the documentation for the search engine and extension involved when those fields are the source of an error.

Unexpected elements in the sitemap namespace

A custom element should not be placed in the core sitemap namespace merely because it appears inside a sitemap. For example, <category> under a url entry becomes an unknown sitemap-protocol element when it inherits the default namespace. CorrectSitemap reports that condition as a warning. Remove the field, translate it into a supported extension, or assign it to a properly designed custom namespace if a downstream consumer genuinely needs it.

A practical repair sequence

1. Inspect the root element and copy its namespace URI exactly.
2. Confirm the root local name is urlset or sitemapindex.
3. Search descendants for xmlns="" or another default namespace declaration that changes the inherited vocabulary.
4. Check every prefix used in an extension element has a declaration in scope.
5. Fix the generator, serialization library, or template responsible for the declaration.
6. Regenerate the complete document and validate it again.

If a browser reports an “unbound prefix” error, XML well-formedness is already broken: a prefix such as image: appears without a matching xmlns:image declaration. Resolve that parser error before evaluating extension content.

Where namespace defects enter a build

Namespace failures frequently appear when XML is assembled from several templates. A root template may declare the default sitemap namespace correctly, while a reusable component adds xmlns="" because it was created for ordinary XML. Converting an object tree through a generic serializer can also produce prefixed elements without carrying the prefix declarations into the final document.

Inspect the final generated bytes rather than only the template source. Build tools, minifiers, middleware, and edge transformations can all change the delivered response. If local validation succeeds and the downloaded production sitemap fails, compare the two files byte for byte and look for injected markup, an HTML error page, or an altered root element.

For a recurring defect, keep a small namespace-aware test fixture next to the generator. Assert the expanded name of the root and representative core children. A plain string assertion for the presence of xmlns can miss a nested reset or a declaration bound to the wrong URI.

When a valid namespace still does not solve submission

Once the supplied XML has the correct namespace, a live sitemap can still fail because it returns HTML, redirects unexpectedly, requires authentication, is blocked by an edge rule, or serves compressed data incorrectly. Fetch the deployed URL as a crawler would and inspect its status, headers, and response body. Search Console reports can then show whether Google retrieved and processed that deployed version.

Namespace validation also says nothing about whether listed pages are canonical, crawlable, or indexable. Those are URL and site-policy questions handled after the document structure is sound.

Protocol references

The Sitemaps protocol defines the root namespace and core vocabulary. For currently supported Google extensions and examples, use the Google Search Central sitemap guide and the linked extension documentation.