How to Map and Customize WordPress XML Sitemaps

A WordPress XML sitemap is a file that lists website URLs so search engines can discover pages. Sitemap mapping means deciding which kinds of WordPress content belong in that list, then checking that the generated files match those decisions. A sitemap helps search engines find URLs; it does not guarantee that they will crawl or index them, as Google’s sitemap guidance explains.

Start by deciding which pages you want search engines to discover, then identify the sitemap generator your site uses so you can adjust its settings or code and inspect the result. This keeps the sitemap focused on public pages that are useful to searchers. Sitemap inclusion does not control rankings.

Decide which WordPress content belongs in the sitemap

Inventory your content before changing settings. WordPress sites can contain posts, pages, custom post types, taxonomy archives, author archives, and media attachment pages. A custom post type is a content class beyond the standard posts and pages, such as products or events. A taxonomy groups content, as categories and tags do.

For each class, decide whether its URLs lead to pages you want search engines to find. Use this table as a starting point:

These are decisions to make for your site, not automatic rules. For example, a public custom post type might contain valuable product pages, while another might hold internal records that should not appear in search. Map the content types separately rather than enabling every available category by default.

A sitemap should list the preferred, canonical URL for each destination. A canonical URL is the version of a page that the site identifies as the primary one when duplicate or similar URLs exist. Google generally uses canonical URLs. Including a URL in a sitemap signals that you prefer it, but does not guarantee Google will select it.

Find out which sitemap generator is active

WordPress includes a built-in sitemap feature, introduced in WordPress 5.5. Its sitemap index is available at /wp-sitemap.xml, and core provides sitemap entries for posts, taxonomies, and users. The WordPress Core announcement describes the feature and its extensibility.

SEO plugins have their own sitemap settings and generate their own files. For example, Yoast documents controls for content types and categories or tags, while Rank Math documents settings and code hooks for sitemap inclusion. Each product has different controls and generates different files. First open the sitemap index your live site serves, then check your active plugin settings. Do not assume that the core endpoint is the sitemap your search setup currently uses.

WordPress core sets a default maximum of 2,000 URLs per sitemap file. Yoast documents a default of 1,000 entries per sitemap for its setting. Those are product-specific defaults, not search-engine limits. Google allows up to 50,000 URLs or 50 MB uncompressed in a single sitemap file, whichever limit comes first, according to its sitemap building instructions. When a site has more URLs than fit in one file, the generator can split them across multiple files and list those files in a sitemap index.

Customize inclusion with plugin settings or WordPress hooks

For most sites, use the active SEO plugin’s settings first. Review one content type at a time, save the changes, then inspect the sitemap to confirm that the expected URLs appeared or disappeared. Yoast, for example, documents settings that connect a content type’s search visibility with its sitemap presence. Rank Math documents separate inclusion controls for post types and taxonomies.

When plugin settings cannot express the rule you need, use a documented code hook. WordPress and plugins expose code hooks at named points where custom code can change specific behavior. A filter is a WordPress hook that lets code change a value generated by WordPress or a plugin. WordPress core provides filters such as wp_sitemaps_posts_query_args, which changes the arguments used to retrieve posts for a sitemap, and wp_sitemaps_max_urls, which changes the per-file URL limit. Developers can also register a custom provider, a component that supplies sitemap entries for a content class. The WordPress developer reference documents the post-query filter.

SEO plugins have their own hooks. Yoast documents ways to exclude individual posts, post types, taxonomies, authors, or terms. Its XML sitemap API also explains how to add custom or external sitemap entries. Rank Math documents hooks in its sitemap documentation. These cover exclusions and URL changes, along with images and additional sitemap URLs. Plugin hooks are specific to that plugin; do not paste code written for one generator into another and expect it to work.

Put custom code in a site-specific plugin or child theme. Test it on a staging copy of your site, then inspect the generated files. Preserve existing filter values unless you intend to replace them. Recheck the output after WordPress or plugin updates because the installed version and configuration determine what the site serves.

Keep sitemap inclusion separate from crawl and index controls

Leaving a URL out of a sitemap does not prevent search engines from finding or indexing it. Internal links and external links can still lead crawlers to that page. To keep a page out of Google Search, use a control such as a noindex directive or password protection. Google explains that robots.txt controls crawling, but does not reliably prevent a URL from appearing in search. A crawler must be able to access a page to read its noindex directive, so blocking that page in robots.txt can interfere with that instruction.

For a page you want indexed, include its preferred canonical URL, make sure crawlers can access it, and check that the page itself does not carry a conflicting indexation directive. For a page you want excluded, use the appropriate indexation control rather than relying on sitemap omission alone. Use robots.txt when you want to control crawling.

Check the generated files and their URLs

After you change settings, open the sitemap index and the sitemap files it lists. Confirm that the files load and the intended content classes appear. Check that unwanted URLs are absent. Then check a sample of listed URLs directly. Each should lead to the intended page and return a successful response. Confirm that each uses the canonical URL you expect.

Google’s sitemap format requires fully qualified URLs, such as a complete address beginning with the site’s scheme and domain, and UTF-8 encoding. Keep files at the site root when practical; a sitemap’s location affects which URLs it covers unless you submit it through Search Console. If the site exceeds Google’s file limits, split the URLs into multiple sitemap files and list them in an index.

Google ignores the priority and changefreq fields. It may use lastmod, the date a page was last modified, when the value is accurate and consistently reflects meaningful changes. Do not update dates just to make unchanged pages look fresh.

After you verify the live sitemap files, submit the sitemap index in Google Search Console if you use it. Submission helps Google discover the sitemap and provides a way to monitor reported issues; it does not compel crawling or indexing. If Google reports a URL problem, inspect that page’s response, canonical URL, crawl access, and indexation directive rather than assuming the sitemap setting alone caused it.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com