Table of contents10
Last spring I launched a new site for a client — forty carefully written articles, beautiful design, everything by the book. A month later I checked Google Search Console. Twelve pages indexed. Twelve out of forty. The content was good, the site was fast, but Google was barely finding anything. I felt sick.
I am Daniel Okafor, and I have set up WordPress sites for years. That day I learned a lesson I now teach every site owner: your XML sitemap is the map you hand to Google. When that map is broken, torn, or unreadable, Googlebot wanders your site blind — and your pages sit unindexed while competitors take the traffic. My client’s sitemap was returning errors Google could not parse. We fixed it in an afternoon. Two weeks later, all forty pages were indexed.
That is the fear behind this guide. You can write the best content on the internet, and it will not matter if Google cannot find it. Sitemap problems are one of the most common technical SEO issues on WordPress, and also one of the most fixable. Most are resolved in under thirty minutes once you know where to look.
In this guide you will learn how WordPress sitemaps actually work, how to set yours up correctly from scratch, and how to diagnose and fix the seven errors Google Search Console reports most often. Whether your sitemap is missing, broken, or just confusing, by the end you will know exactly what to do. Ready? Let us get started.
You do not need to buy anything or hire anyone. Everything here uses free tools and settings already inside WordPress.

Here is what this guide covers:
- How WordPress sitemaps actually work (two systems, one winner)
- How to set up and submit your sitemap in 10 minutes
- The symptom table: what you see, what it means, which fix to use
- Fixing “sitemap not found” and blank sitemap pages
- Fixing parsing errors and “couldn’t fetch” in Search Console
- The stale-cache trap and the physical-file trap
- How to keep one sitemap system (not two)
- A monthly sitemap health routine
Ready? Let us get started.
How WordPress Sitemaps Actually Work
Before fixing anything, you need to know which system is generating your sitemap, because WordPress sites usually have two candidates and only one should be active.
The native WordPress sitemap. Since WordPress 5.5, core ships its own sitemap at yoursite.com/wp-sitemap.xml. It is basic but functional: it lists posts, pages, and taxonomies, updates automatically when you publish, and requires zero configuration. For small, simple sites it is often all you need.
The SEO plugin sitemap. If you run an SEO plugin, it almost certainly generates its own sitemap — usually at yoursite.com/sitemap_index.xml. These are more capable: you can exclude post types and taxonomies, split large sites into child sitemaps, and control exactly which URLs get included.
The golden rule: run one sitemap system, not two. Having both the native sitemap and a plugin sitemap active is not directly harmful — Google will not penalize you for it — but it makes troubleshooting miserable. When Search Console reports an error, you will waste time checking the wrong file. Pick one system and disable the other. If your SEO plugin generates a sitemap, that is almost always the one to keep, because it gives you real control.
To disable the native one while keeping your plugin’s, add this single line to your theme’s functions file or a code snippet manager:
add_filter( 'wp_sitemaps_enabled', '__return_false' );
That is it. One line, and the core sitemap quietly steps aside. This is a technique, not a product recommendation — any code snippet tool or child theme functions file works.
Here is what a healthy sitemap looks like when you open it in a browser: raw XML with , , and tags listing your pages. If you see that, your sitemap exists. If you see anything else — a 404 page, a blank white page, your homepage, a login screen — your sitemap is broken, and the symptom table in the next section tells you exactly which fix to apply.
Setting Up and Submitting Your Sitemap in 10 Minutes
Setup is genuinely simple. The mistakes happen when people skip steps, so follow this order.
Step 1: Confirm the sitemap loads. Open an incognito window and visit your sitemap URL. You are checking three things: the HTTP status must be 200 OK (not 404, not 500), the content must be raw XML (not a styled HTML page), and it must be fresh (a post you published this week should be listed; a page you deleted months ago should not be).
How do you check the status code without tools? In Chrome, right-click the page, choose Inspect, open the Network tab, reload, and look at the status column for the sitemap request. It takes ten seconds once you know where to look.
Step 2: Submit it to Search Console. In Search Console, go to Sitemaps in the left menu, enter the sitemap filename (for example sitemap_index.xml — just the filename, not the full URL), and click Submit. Google will fetch it and report a status: Success, Couldn’t fetch, or errors. This status is your ongoing health monitor. Check it monthly.
Step 3: Decide what belongs in the sitemap. A sitemap should list pages you want Google to index — nothing else. That means: include posts and pages, include categories only if they have real content and traffic value, and exclude tags, date archives, author archives, and attachment pages in almost all cases. These archive pages create thin, low-value URLs that waste Google’s attention — the same problem I describe in our guide on wasting crawl budget. Your SEO plugin’s sitemap settings let you toggle each content type. Be ruthless. A sitemap with 200 strong URLs beats one with 2,000 weak ones.
Step 4: Exclude the sitemap from caching. This is the step everyone skips, and it causes half of all “my sitemap is not updating” complaints. Caching plugins love to cache your sitemap file, which means Google keeps receiving yesterday’s version. Add sitemap*.xml (and your specific sitemap filenames) to your caching plugin’s exclusion list, and do the same in your CDN’s cache rules if you use one. XML files should always be served fresh, with a 200 status and a proper XML content type.

The Symptom Table: What You See, What It Means, Which Fix to Use
This is the technique I promised in the research: troubleshoot from symptoms outward, never from random tips. Find your symptom in this table, then jump to the matching fix.
- Sitemap URL returns 404 — cause: sitemap feature disabled, or permalinks broken. Fix: re-save permalinks, check the feature toggle.
- Sitemap shows a blank white page — cause: two sitemap systems conflicting, or PHP memory exhausted. Fix: keep one system, raise the memory limit.
- Browser shows XML parsing error — cause: PHP memory cut the output off mid-file. Fix: raise the PHP memory limit.
- Search Console says “Couldn’t fetch” — cause: firewall, security plugin, or robots.txt blocking Google. Fix: check robots.txt and firewall rules.
- Search Console shows 0 submitted URLs — cause: stale cache, or submission not refreshed. Fix: clear caches, delete and re-submit.
- Sitemap loads but new posts are missing — cause: caching plugin serving an old copy. Fix: exclude the sitemap from all caches.
- Two different sitemap URLs both load — cause: native + plugin sitemap both active. Fix: disable the native one.
Work through this table before trying anything else. Nine times out of ten, your symptom is here, and the fix takes minutes.
Fixing “Sitemap Not Found” and Blank Sitemap Pages
The 404 is the most reported sitemap symptom, and the fix is almost embarrassingly simple: go to Settings, then Permalinks, and click Save Changes without changing anything. This regenerates WordPress’s rewrite rules — the internal map that turns pretty URLs into actual content. Stale rewrite rules are the number one cause of sitemap 404s, and this one click fixes them.
If the 404 persists after re-saving permalinks, check three things in order. First, confirm your permalink structure is not set to Plain — sitemaps require pretty permalinks to work. Second, verify the sitemap feature is actually enabled in your SEO plugin; plugin updates and site migrations sometimes reset the toggle to off, and no toggle means no sitemap at all. Third, check for conflicts: two SEO plugins active at once, or a security plugin blocking the sitemap path.
The physical-file trap is the sneaky one. If an old static sitemap.xml file exists in your site’s root folder (from a previous plugin, a migration, or a manual upload years ago), the server serves that dead file instead of your live dynamic sitemap. Open your hosting file manager, look in the main website folder, and if you find a sitemap.xml file sitting there, rename it to sitemap.xml.bak. Your dynamic sitemap will immediately take over. I have seen this trap waste hours of debugging because nobody thinks to look for a file.
A blank white page instead of XML usually means two sitemap systems are fighting, or PHP ran out of memory while generating the XML. Fix it by keeping one sitemap system (disable the native one as shown earlier) and, if the page is still blank, raising your PHP memory limit. Your host’s control panel usually lets you raise it, or you can ask support — it is a two-minute change for them.
Fixing Parsing Errors and “Couldn’t Fetch” in Search Console
These two Search Console errors look similar but have completely different causes. Getting them mixed up wastes time, so here is how to tell them apart.
“Parsing error” means Google fetched your sitemap but could not understand it — the XML is malformed. The most common cause on WordPress is PHP memory exhaustion cutting the XML output off mid-file: the sitemap starts fine and then just stops, leaving broken XML. The fix is raising the PHP memory limit. Less commonly, a plugin is injecting HTML or whitespace into the XML output — deactivate recently added plugins one by one and re-check the sitemap URL until the XML renders cleanly. You can also paste your sitemap URL into any free XML validator to see exactly where the syntax breaks.
“Couldn’t fetch” means Google could not even download the sitemap. This is a access problem, not a content problem. Check in this order: Is your site currently reachable at all? Is your robots.txt blocking the sitemap path? Is a security plugin or firewall (or your CDN’s bot protection) blocking Googlebot? I have seen security plugins silently block Googlebot’s IP ranges after an overzealous “block bad bots” rule. Temporarily test with the security plugin paused — if the fetch succeeds, you found your culprit, and you can whitelist Googlebot properly.
One more honest note: sometimes “couldn’t fetch” is transient. Google’s fetcher hiccups. If your sitemap loads perfectly in your browser and nothing is blocking it, delete the sitemap submission in Search Console and re-submit it. A fresh submission forces an immediate re-fetch, and the error often clears on its own. Do not rebuild your whole setup over a transient error — verify first, then act.

The Stale-Cache Trap (Why Your Sitemap Shows Old URLs)
You publish a new post. You check the sitemap. The post is not there. You publish another. Still not there. The sitemap is frozen in time — and the culprit is almost always caching.
Here is what happens: your caching plugin (or your CDN, or your server cache) saved a copy of the sitemap XML the first time it was requested, and now it serves that stale copy to everyone, including Google. You update the XML, but nobody sees the update. Google sees the mismatch and keeps reporting stale data.
The fix has three layers, and you should apply all three. First, add your sitemap URLs to your caching plugin’s exclusion list — every caching plugin has a “never cache these URLs” setting. Second, do the same in your CDN: exclude sitemap*.xml patterns from caching, minification, and HTML optimization features. Third, after making these changes, manually visit each sitemap URL in your browser — most sitemap generators rebuild the file when accessed directly — then clear all caches one final time.
Bonus Tip: If you disabled WordPress cron (DISABLE_WP_CRON) and rely on a server cron job instead, make sure that server cron is actually running. Sitemap regeneration can depend on scheduled tasks, and a dead cron means a frozen sitemap. Check with your host if you are unsure.
After clearing everything, wait 15 to 30 minutes before checking Search Console again. Some sitemap statuses only update after a fresh crawl cycle, and refreshing the report every two minutes will only raise your blood pressure.
Large Sites, Sub-Sitemaps, and the 50,000-URL Limit
Sitemaps have hard limits set by the sitemap protocol itself: 50,000 URLs and 50MB uncompressed per sitemap file. If your site is large, a single sitemap file cannot hold everything, and you need a sitemap index — one master file pointing to multiple child sitemaps.
The good news: every competent SEO plugin handles this automatically. It generates a sitemap index (like sitemap_index.xml) that links to child sitemaps (post-sitemap.xml, page-sitemap.xml, and paginated ones like post-sitemap2.xml when needed). You submit only the index to Search Console, and Google follows the children on its own.
But large sites have a second problem the limits do not cover: low-value URLs eating your sitemap budget. On a site with 10,000 URLs, every tag archive, author page, and thin category in the sitemap is a URL Google will crawl instead of your money pages. For large sites, sitemap curation is not optional — it is strategy. Exclude tags, date archives, and author archives. Review categories individually: keep the ones with real content, drop the rest. The goal is a sitemap where every URL deserves to be there.
If your site is truly massive and sitemap generation times out (blank pages, partial XML), that is usually PHP memory or execution time limits. Raise both, and consider generating the sitemap during off-peak hours. And remember the golden rule from the start: one sitemap system. On large sites, two competing sitemap generators do not just confuse troubleshooting — they can double your server load during generation.

Your Monthly Sitemap Health Routine
Sitemaps break quietly. A plugin update disables the feature. A caching change re-caches the file. A migration leaves a stale physical file behind. None of this announces itself. So here is the five-minute monthly routine that keeps your sitemap healthy.
Minute 1: Open your sitemap URL in an incognito window. Does it load as raw XML with a 200 status? Is a recent post listed? Is a long-deleted page gone?
Minute 2: Check the Sitemaps report in Search Console. Status should read Success, and the discovered URL count should roughly match your real content count. A sudden drop means something got excluded.
Minute 3: Glance at the Pages report for new crawl errors. Sitemap problems and crawl errors travel together — a URL in your sitemap that returns a 404 is a double failure.
Minute 4: If you changed anything this month — new plugin, new caching rules, new CDN settings — re-verify the sitemap exclusion from caches. Caching changes are the number one sitemap killer.
Minute 5: Confirm you still have exactly one sitemap system active. Updates sometimes re-enable the native WordPress sitemap. One line of code keeps it off, but only if nobody turns it back on.
That is it. Five minutes a month, and your map to Google stays accurate. If you want to go deeper into overall site health, run a free SEO audit quarterly — sitemap health is one chapter of a bigger story.
Frequently Asked Questions
Do I even need an XML sitemap? Can’t Google find my pages anyway? Google can discover pages through links alone, but a sitemap makes discovery faster and more reliable — especially for new sites with few backlinks, large sites with deep content, and sites with pages that are not well linked internally. Think of it as handing Google a map instead of making it explore blind. It costs nothing and helps every time.
Should I submit every sitemap file or just the index? Just the index (for example, sitemap_index.xml). Google follows the child sitemaps automatically. Submitting individual child files is redundant and clutters your Sitemaps report.
Why does Search Console show fewer indexed URLs than my sitemap lists? Because a sitemap is a suggestion, not a command. Google chooses what to index based on content quality, uniqueness, and site authority. If hundreds of sitemap URLs stay unindexed, the problem is usually thin or duplicate content — not the sitemap itself. Fix the content, and indexation follows.
My sitemap includes URLs I don’t want indexed. How do I remove them? Do not just delete them from the sitemap — first stop them from being indexable. Set those pages to noindex (or exclude their post type from the sitemap in your SEO plugin’s settings), then let the sitemap regenerate. A URL in the sitemap that is also noindexed sends Google mixed signals.
How often does Google re-check my sitemap? Google re-fetches sitemaps on its own schedule — typically daily for active sites, less often for quiet ones. After fixing an error, delete and re-submit the sitemap to force an immediate fresh fetch instead of waiting for the next scheduled one.

Final Thoughts
My client’s site went from twelve indexed pages to all forty in two weeks. Nothing about the content changed. The design did not change. The only thing that changed was the map — Google could finally see the whole site clearly, and it indexed what was already good.
That is what a working sitemap does. It does not make bad content rank. It makes good content findable. And when it breaks, the damage is invisible: you keep publishing, Google keeps missing, and you blame everything except the actual problem.
You now know the full playbook: one sitemap system, submit it correctly, curate what goes in, keep it out of caches, and run the five-minute monthly check. The next time your indexation stalls, you will know exactly where to look — and you will fix it before it costs you a month of traffic.
Found a sitemap error that is not in the symptom table? Describe it in the comments. The weird ones teach us all something new.









