# Fix Rank Math XML Sitemaps on an Nginx WordPress Server
Rank Math can generate XML sitemap content dynamically inside WordPress, but a working generator does not always mean the public sitemap URL is routed correctly. On an Nginx server, the missing piece can be a rewrite rule that passes a sitemap-style URL to WordPress. When that routing is absent, a visitor or crawler may be unable to open the expected sitemap even though Rank Math itself can produce sitemap output.
This guide follows the workflow in the source article. It begins with a simple diagnostic request, explains what that result suggests, shows the Nginx rewrite rules provided by the source, and closes with the setting refresh described there. It is limited to one scenario: Rank Math is installed on WordPress, sitemap generation works dynamically, and the public sitemap path needs to be rewritten to WordPress.
> **Risk and recency note:** Nginx file locations, active server blocks, WordPress permalink behavior, and Rank Math settings can differ between hosts and versions. Back up the active site configuration and test changes before reloading Nginx. The rules below are source-based examples, not a universal configuration to paste into every server.
## Start by checking dynamic sitemap generation
The source recommends visiting this URL first:
“`text
domain.com?sitemap=1
“`
Replace `domain.com` with the site’s actual domain. This request is useful because it asks WordPress and Rank Math for sitemap output through a query parameter rather than through the usual XML sitemap filename.
If that request loads successfully, the source’s interpretation is specific: Rank Math can generate the sitemap, but Nginx is not rewriting the public sitemap address, such as `sitemap_index.xml`, to the WordPress request that produces the content. That distinction prevents a common mistake: changing plugin settings before checking whether the web server is simply failing to route the request.
If the query-parameter request does not work, do not assume the rewrite rules alone are the answer. The source article does not diagnose every possible sitemap failure. Confirm the WordPress and Rank Math configuration, inspect the server’s active configuration, and determine whether the issue is generation, routing, access control, or something else.
## Why Nginx needs an extra rule in this case
The source describes Rank Math’s sitemap as dynamic and dependent on server-level routing. A crawler normally asks for a familiar XML path, while WordPress needs the corresponding internal query variables to produce the response. Nginx rewrite rules can connect those two forms of the request.
This is not the same as creating a static XML file. The rules in the source pass the request internally to `index.php` with the relevant sitemap or XSL parameter. The final `last` flag tells Nginx to continue processing the rewritten URI according to its normal request handling.
Before adding anything, locate the Nginx site configuration that actually serves the WordPress domain. The source gives `/usr/local/nginx/site-enables/xxx` as one possible location, but that is an example rather than a guarantee. Some systems use a different directory and may include multiple configuration fragments. Editing an unused file will not change the live site; editing the wrong active block can affect another site.
## Add the Rank Math rewrite rules
After identifying the correct site configuration, place the following source-provided rules inside the applicable `server` block, before its final closing brace:
“`nginx
# START Nginx Rewrites for Rank Math Sitemaps
rewrite ^/sitemap_index.xml$ /index.php?sitemap=1 last;
rewrite ^/([^/]+?)-sitemap([0-9]+)?.xml$ /index.php?sitemap=$1&sitemap_n=$2 last;
rewrite ^/([a-z]+)?-sitemap\.xsl$ /index.php?xsl=$1 last;
# END Nginx Rewrites for Rank Math Sitemaps
“`
The first line covers the sitemap index path and rewrites it to `index.php?sitemap=1`. The second is intended to match individual sitemap filenames and pass the sitemap name and optional number into query parameters. The third is intended to handle the sitemap stylesheet request.
Keep the syntax exactly as it is validated for the configuration you are using. Regular-expression escaping is easy to damage when copying rules through a shell, control panel, or templating system. The source article presents this block as the plugin-specific rewrite code to add near the end of the Nginx site configuration.
## Save carefully and apply Nginx changes
The source workflow is short:
1. Edit the appropriate Nginx site configuration, for example with `vim`.
2. Add the rewrite block before the final `}` of the relevant server block.
3. Save the file.
4. Restart Nginx with `systemctl restart nginx`.
A safer operational habit is to validate the configuration before a reload if the server’s normal operating procedure supports it. The point is not to add unverified commands to the source workflow, but to avoid discovering a syntax problem only after traffic is affected. Keep the previous configuration available so that a bad change can be reversed promptly.
A restart or reload only makes a valid configuration active; it does not prove that the sitemap routes correctly. Test the expected public paths after Nginx has accepted the change. The source’s diagnostic remains useful: compare the behavior of `?sitemap=1` with the XML sitemap URL. If the dynamic request works but the XML route still fails, re-check that the rules are in the active server block and that no other directive is intercepting the request.
## Refresh the Rank Math sitemap settings
The source calls for one further step after adding the rewrite rules: refresh the sitemap settings in WordPress. In the WordPress administration area, open **Rank Math SEO → Sitemap Settings**, make a small change to the **Links Per Sitemap** value, and save the change.
The purpose of that small edit is to refresh the sitemap settings after the server-side routing adjustment. Record the original value before changing it so it can be restored if needed. This is a settings refresh, not a reason to change the site’s sitemap scope, post types, or taxonomy inclusion without a separate review.
## A focused troubleshooting sequence
When the public sitemap is inaccessible, use the source workflow in this order:
1. Request `domain.com?sitemap=1` to determine whether Rank Math can generate a sitemap response.
2. If it succeeds, identify the active Nginx configuration for the WordPress site.
3. Back up that configuration and add the supplied rewrite block to the relevant server block.
4. Apply the configuration through the server’s normal Nginx restart process.
5. Refresh the Rank Math sitemap settings by making and saving a small Links Per Sitemap adjustment.
6. Revisit the sitemap index and individual sitemap URLs.
This sequence keeps the problem bounded. It does not assume that every sitemap error belongs to Nginx, and it does not treat a plugin setting change as a substitute for a missing route.
## Conclusion
For the specific case described by the source article, a successful `?sitemap=1` request is the key clue: Rank Math can generate the sitemap, but Nginx needs rewrite rules to expose the usual XML sitemap paths. Add the source-provided rules in the correct active configuration, apply the change carefully, refresh the Rank Math sitemap settings, and verify the public URLs afterward. Because web-server and plugin behavior can change, retain a backup and treat successful live verification, not the edit alone, as the completion criterion.
