Why can The SEO Framework's virtual sitemap return a missing-page error on Nginx?

Definition: A missing-page error can occur when an Nginx regular-expression location rule handles an XML request before the request reaches WordPress. The SEO Framework generates its virtual sitemap through WordPress, so an XML rule that handles the endpoint independently can leave /sitemap.xml with a 404 response.

Key facts

• The SEO Framework's sitemaps are generated virtually through PHP and are not stored on the website's drive. Its sitemap documentation says that WordPress must display them.
• The same guide says that custom NGINX configurations can prevent the proxy from calling WordPress.
• The guide identifies independent .xml endpoint rules as a cause of 404 errors and says to remove the xml part from matching location rules.
• NGINX first remembers the longest matching prefix location, then checks regular expressions in configuration order and uses the first matching regular expression. The NGINX core module documentation describes this selection sequence.

How does an XML location rule block the sitemap?

The request path /sitemap.xml looks like a static XML file to a server rule that matches file extensions. TSF's sitemap documentation describes a different path: the sitemap is virtual, so WordPress and PHP generate the response. A rule that treats .xml separately can therefore stop the request before WordPress's /index.php receives it.

The TSF guide names the type of configuration to inspect:

location ~* .([...|xml)$

Its prescribed change is to remove the xml alternative from every matching rule. The same page also distinguishes this failure from a redirect: if /sitemap.xml is sent to /wp-sitemap.xml or /sitemap_index.xml, it says to remove sitemap-related NGINX configuration.

NGINX's selection algorithm explains why rule order matters. It checks prefix locations first, remembers the longest match, then checks regular expressions in the order in which they appear. The first regular-expression match supplies the configuration. A broad case-insensitive XML rule can therefore take control of a request that would otherwise fall through to the general WordPress route.

What route should handle the request?

The NGINX documentation's WordPress and Joomla example uses try_files in the general location and sends the fallback to a named @wordpress location:

location / {
    try_files $uri $uri/ @wordpress;
}

location @wordpress {
    fastcgi_pass ...;

    fastcgi_param SCRIPT_FILENAME /path/to/index.php;
    ... other fastcgi_param's
}

NGINX documents that try_files checks files in order, uses the first one found in the current context, and internally redirects to the last parameter when none is found. For a virtual TSF endpoint, the request needs the fallback path that invokes WordPress. The example is a routing pattern, not a complete server configuration: the FastCGI address and parameter set depend on the PHP setup.

How can the error be checked?

Start with the public /sitemap.xml endpoint. If it redirects to /wp-sitemap.xml or /sitemap_index.xml, inspect the server configuration for sitemap-specific rules and remove them as the TSF guide directs. If it returns a 404, inspect every case-insensitive regular-expression location rule that includes xml, remove that alternative, and reload the configuration through the hosting provider's documented process.

The TSF documentation also says that a blank styled sitemap can involve incorrectly configured .xsl endpoints on NGINX and recommends applying the same NGINX fixes with xsl in place of xml. That is a stylesheet request, while the missing-page error described here concerns the XML sitemap request itself.

Related terms

• Why do several sitemap URLs return the same XML in The SEO Framework?
• XML sitemap

FAQ

Does TSF create a physical sitemap file?

No. TSF documents that its sitemaps are virtually generated through PHP and are not stored on the website's drive. The public endpoint therefore needs WordPress routing.

Should you add a special NGINX rule for /sitemap.xml?

The TSF guide says to remove sitemap-related NGINX configurations when the endpoint redirects, and to remove xml from matching location rules when the endpoint returns a 404.

What if the XML response is present but the browser shows a blank page?

Inspect the sitemap source. TSF says that an incorrectly configured .xsl endpoint on NGINX can cause the styled view to be blank and recommends applying the NGINX fix to xsl.

Sources

1. The SEO Framework, "All You Must Know About Sitemaps", October 13, 2026
2. NGINX, "Module ngx_http_core_module", undated

---

Check how a page reads to answer engines. Open the GEO score analyzer