Sitemap URL troubleshooting

Invalid sitemap URL and loc errors

Every URL entry and sitemap-index entry needs one usable loc value. Most location errors come from relative application routes, missing schemes, unescaped query strings, empty database fields, or URLs copied from the wrong environment.

Use one absolute URL per entry

A URL sitemap places one loc inside every url. A sitemap index places one loc inside every sitemap. The value must include an HTTP or HTTPS scheme and hostname:

Resolve application routes against the production site origin before serializing XML. Avoid inferring the origin from an internal request when proxies or preview deployments can supply the wrong hostname.

Escape XML and encode the URL

XML escaping and URL encoding solve different problems. A literal ampersand separating query parameters must appear as & in XML source:

<loc>https://example.com/catalog?color=blue&amp;size=large</loc>

Spaces and other characters that cannot appear directly in a URI need URL encoding, such as %20. Non-ASCII paths should use a consistent UTF-8 URL representation accepted by the server. Feed the final URL through a URL library, then let an XML serializer escape the resulting text. Replacing characters by hand can cause double encoding, such as turning an existing %20 into %2520.

Keep locations below the protocol limit

The sitemap protocol limits loc values to fewer than 2,048 characters. Very long locations often point to filter combinations, session identifiers, analytics parameters, or generated application state that offers little search value. Prefer a stable canonical URL and remove parameters that do not change indexable page content.

Choose canonical, index-intended URLs

A structurally valid location can still be a poor sitemap entry. Review each source set for:

• HTTP URLs that permanently redirect to HTTPS;
• www and non-www duplicates;
• uppercase or trailing-slash variants that redirect to one canonical form;
• tracking, sorting, filtering, session, and preview parameters;
• staging, localhost, internal service, or temporary deployment hosts;
• pages with a canonical declaration pointing somewhere else;
• pages blocked from crawling or excluded from indexing.

Google treats sitemap locations as canonical suggestions while retaining its own canonical-selection process. Keep the list aligned with the URLs used in internal links, redirects, and canonical markup.

Watch for environment and migration mistakes

Host changes expose location defects quickly. A migration from HTTP to HTTPS, a www change, or a new locale structure can leave an old base URL in one generator process. Preview deployments sometimes publish their temporary hostname when configuration falls back to the incoming request origin. Set the canonical production origin explicitly and cover it with a generator assertion.

During a staged migration, generate URLs for the destination only when those pages are live and return their intended final status. A sitemap filled with redirecting old URLs gives crawlers a weaker and less efficient inventory than one containing the final destinations.

Understand host and submission scope

The base sitemap protocol expects URLs from one host, and the sitemap's deployment location affects which URLs it can cover. Google supports documented cross-site submission arrangements when ownership is established through Search Console or robots.txt. CorrectSitemap validates the shape of a pasted URL but cannot infer the deployed sitemap URL, property ownership, or authorization relationship.

If Search Console reports that a URL is not allowed for a sitemap, compare the location's scheme and host with the submitted sitemap and the active Search Console property. Also check whether the sitemap lives below a directory boundary that limits its default scope.

Find missing and duplicate locations at the source

An empty loc often originates from a nullable route, a deleted content record, or an object whose public URL was never assigned. A duplicate loc child inside one entry usually indicates that a template rendered a default and an override. Filter invalid source records before writing the XML and make the serializer accept exactly one location per entry.

Duplicate URLs across separate entries require a different inventory check. CorrectSitemap's privacy-safe response does not retain submitted locations for cross-entry deduplication. Run a bounded duplicate check inside the generator, where canonical URL values are already available.

Separate location syntax from page availability

The validator can establish that https://example.com/page has an acceptable absolute HTTP(S) shape. It does not request that page. The destination may still return 404, redirect elsewhere, require authentication, declare a different canonical, or carry a noindex directive. Sample the deployed destinations and use crawler or server data for larger inventories.

A page becoming temporarily unavailable does not make its URL malformed. Decide whether it belongs in the sitemap based on the publishing state and recovery plan, then keep generator rules consistent with that decision.

Validate, deploy, and sample

1. Generate the sitemap from production-like source data.
2. Validate the supplied XML and repair every reported location line.
3. Check representative URLs with query strings, Unicode paths, and redirects.
4. Deploy the sitemap and fetch the public response.
5. Sample listed pages to confirm status, final URL, canonical markup, and crawl policy.
6. Submit the sitemap and review URL-specific errors in Search Console.

Protocol references

The Sitemaps protocol defines required locations, escaping, URL length, file placement, and host rules. Google's sitemap guide recommends fully qualified canonical URLs and documents cross-site submission options.