What WordPress’s built-in sitemaps publish before installation
Since version 5.5, WordPress core ships its own sitemap at /wp-sitemap.xml. It is on by default. Most sites already have one and never noticed.
Core's version is deliberately minimal. It lists posts, pages, public custom post types, public taxonomy terms and author archives, chunked into part files, with no changefreq, no priority and no image entries. It also has no interface: excluding a single URL or dropping author archives means writing a filter.
That matters because it changes the real question. You are not choosing between "a sitemap" and "no sitemap". You are choosing between core's opinionated minimum and something you control.
Do you actually need a sitemap generator plugin?
Honest answer: often not.
Core's sitemap is enough if your site is a few dozen pages and a blog, everything you publish is meant to be indexed, and you are not fighting an indexing problem. Installing Yoast purely for a sitemap is installing a large plugin for a file you already have.
A plugin earns its place when any of these apply:
- You have
noindexcontent that core still lists. Core knows nothing about per-post SEO settings, and listing a noindexed URL sends Google a contradictory instruction. - You want author or tag archives out. Thin tag archives are a classic index-bloat source, and core has no toggle.
- You want
lastmodyou trust, or image entries alongside pages. - You have thousands of URLs and want per-content-type reporting in Search Console.
One thing to avoid: running both. Yoast and Rank Math disable core's wp-sitemap.xml when they take over, and that is correct behavior. If you hand-upload a static sitemap while core's is still live, you now have 2 files describing the same site with different contents. Pick one, and make robots.txt name only that one.
How the URL shape decides which file a page lands in
The generator has no database access, so it reads permalink shapes. The rules, in order:
/category/…or/categories/…→ category archives/tag/…or/tags/…→ tag archives/author/…or/authors/…→ author archives/product/…,/products/…or/shop/…→ products- A first segment of 4 digits, as in
/2026/08/post-slug/→ posts - A single top-level segment, as in
/pricing/→ pages - Anything else with more than one segment → posts
That last pair is the interesting one, and it encodes how WordPress permalinks usually work. Pages sit at the root: /about/, /pricing/, /contact/. Posts sit deeper, either under a date or under a category prefix. So depth is a decent proxy for type.
It is a proxy, not a fact. A genuine page at /blog/archive/ gets filed as a post, and so does anything you moved under /company/about/. The split table exists for exactly this: check it, and rename the file if the bucket is wrong. The XML inside is unaffected, since a URL entry does not carry its content type.
Why the chunk size is 1,000 or 2,000, never 50,000
The sitemaps.org protocol caps a single file at 50,000 URLs and 50 MB uncompressed. No WordPress producer goes anywhere near that, and they do not agree with each other either:
| Producer | Index filename | URLs per file |
|---|---|---|
| Yoast SEO | sitemap_index.xml |
1,000 |
| Rank Math | sitemap_index.xml |
1,000 |
| WordPress core | wp-sitemap.xml |
2,000 |
Core's figure is adjustable through the wp_sitemaps_max_urls filter. The plugins' is not, in practice.
The reason any of them chunk early is diagnostic, not technical. Search Console reports submitted and indexed counts per file. At 50,000 URLs per file you learn that 38,000 are indexed and nothing about which ones. At 1,000 you can see that product-sitemap3.xml is at 12 percent while everything else sits above 90, and go look at what those 1,000 URLs have in common.
Pick your producer in the tool and it emits that layout exactly - the right index filename, the right part-file naming, the right chunk size. The index filename is the part that actually matters operationally, because it is the URL you submit and the one you put in robots.txt. Submit sitemap_index.xml on a core-only site and you get a 404.
The sitemap fields, and the 2 that matter
urls is the input. One URL per line. Optional extra columns after a |, in any order: a date becomes lastmod, a keyword like weekly becomes changefreq, a number between 0 and 1 becomes priority. Lines starting with # are ignored, and tabs work like pipes so a spreadsheet paste works directly.
baseUrl is the one you must not skip. A sitemap index has to point at absolute file URLs; relative <loc> values make the index invalid. Set it to https://www.example.com, matching your canonical host including the www decision.
lastmod is the field worth thinking about. 3 options: omit unless a per-line column supplies one, stamp today on every URL, or take it only from the per-line column. Take it from the column. Stamping today on 4,000 URLs is a claim you cannot back up, and Google demonstrably discounts lastmod on sitemaps where it is always current. An accurate lastmod on a subset beats a fabricated one everywhere.
changefreq and priority default to omitted, and should stay omitted. Google ignores both, and has said so repeatedly. Priority is relative within one file anyway, so setting everything to 1.0 is arithmetically meaningless.
A worked example
Paste 4 representative URLs:
https://www.example.com/
https://www.example.com/pricing
https://www.example.com/2026/08/technical-seo-audit | 2026-08-12
https://www.example.com/category/marketing
https://www.example.com/tag/seo
You get 5 files. sitemap_index.xml at the top, then post-sitemap.xml with the dated post, page-sitemap.xml with the homepage and /pricing, category-sitemap.xml, and post_tag-sitemap.xml. The index looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<sitemap>
<loc>https://www.example.com/post-sitemap.xml</loc>
</sitemap>
<sitemap>
<loc>https://www.example.com/page-sitemap.xml</loc>
</sitemap>
</sitemapindex>
Note that the homepage, with no path segments at all, is filed as a page. That is correct and it is also the entry most hand-built sitemaps forget.
Submitting it without wasting a week
Upload every file to the web root, alongside each other. Add one line to robots.txt:
Sitemap: https://www.example.com/sitemap_index.xml
Then submit the index URL in Search Console. Submit the index only, never the parts individually. Google follows the links and reports each part separately anyway, so submitting them by hand just duplicates rows in the report.
2 time-wasters. Google retired the sitemap ping endpoint in 2023, so scripts calling google.com/ping?sitemap= hit a dead URL. And WordPress generates a virtual robots.txt unless a physical file exists - upload a static one and it wins, without the sitemap lines your SEO plugin was adding.
If maintaining this by hand across a growing site is the part you dislike, BlazeHive automates SEO content end to end.