A sitemap is an XML-formatted file that lists links of your site, optionally with discrete information, like timestamps. It isn’t easily readable for humans–but robots, like Googlebot, can quickly digest it.

We attach a stylesheet to the sitemap so that humans can read it. Search engines ignore that stylesheet. Chrome is dropping the clickable version of this view. See sitemap styling.

Let’s get this out right away: A sitemap does not directly contribute to ranking — sitemaps only help with indexing pages quicker. Most sites without a sitemap perform just as well in search as sites with one in the same sector. And, if you manage content via a dynamic CMS like WordPress, you probably do not need a sitemap at all.

Below, we’ll dive into the intricate, layman-friendly details so that you can make an informed decision on why you should use a sitemap. Thereunder, we’ll explain how our sitemap works with your WordPress website.

As always, we composed this article using reliable evergreen sources, such as Google’s documentation and Bing’s documentation, and we never rely on pseudo-science or hacks spouted by self-proclaimed SEO gurus.

In this article, we cover search engines that have a 98% combined market share.

Why should I use a sitemap?

You may want to consider using a sitemap if:

• Your site is new and search engines aren’t aware of its hierarchy yet.
• Your site is large and has over 500 pages.
• Your site has many old, deeply tucked away pages.
• Your site does not have a natural hierarchy.
• Your site publishes time-sensitive, expiring content, such as news.

You don’t need a sitemap if:

• Your site is small and well-established.
• Your site has proper internal linking, such as menus, archives, and breadcrumbs.

Some SEOs advocate using sitemaps for indexing images and videos. The sitemap is antiquated and limited in this regard, and we recommend moving forward using Schema.org structured data, instead.

Your site is new: discovering all pages

Search engines crawlers (also known as “spiders”) first need to discover your site before the search engine can index it. As they crawl over your pages, they’ll need to process each page to discover more links. Then, they’ll crawl those linked pages, process those pages, discover more links, and so forth.

So, when your site is new, you can help the crawler discover all important links instantly by handing them a sitemap. This way, most of your pages will get indexed quickly.

Your site is large: prioritized crawling

Search engines keep a record of all internal and external links of-and to your website. The search engines tag a hidden priority to each page (depending on the number of backlinks and indexing state) and periodically crawl those. For instance, your homepage will be crawled more often than your contact page.

As your site grows larger, search engines won’t necessarily crawl your pages at a proportionally increased rate. So, when you add new pages, it might take longer for the crawler to discover those via internal linking. This is where a sitemap can truly help.

Larger sites often come with larger sitemaps. However, keep in mind that a bigger sitemap takes more time for search engines to parse. It’s better to have fewer items in the sitemap when you plan on posting often. For the same reason, it’s also better to have fewer sitemaps. The SEO Framework outputs one base sitemap. Our Articles extension can add a Google News sitemap. WPML and Polylang add one extra sitemap per extra language.

There’s no harm in leaving pages out of the sitemap — once a search engine is aware of a page’s existence, they’ll keep it indexed (when indexable) and will always crawl it periodically.

Your site is old: maintaining intent

When your website has old, forgotten, isolated content with few backlinks, then search engines might hide that content from the search-engine-index. This is because modern search engines intend to discover your intent.

Simply put, CMSs like WordPress can generate pages for you. Add /search/any+search+query to your site’s URL, et voilà, there’s a new page. Because most sites nowadays can create pages on-the-fly, there’s an infinite number of pages around the web, and not all of those are useful.

This is where intent comes in: Did you link to the page? How often do others link to that page? Is the link trustworthy? Is the content duplicated? Does your sitemap link to the page?

Your site is unnatural: substitute bad hierarchy

We covered above that search engines discover links automatically from your content. When your website does not link to pages via menus, breadcrumbs, archives, footers, sidebars, or via the content, then you may require a sitemap.

However, if a visitor can’t navigate your site easily, then why would a search engine? Do you want your business to rely solely on an overlord like Google? If you require a sitemap because there’s a lack of internal linking, then you’re doing it wrong or are otherwise being creative and are making the life of your visitors and yourself needlessly difficult.

Your site may also be unnatural because it’s dynamically rendered via JavaScript (animations, REST, etc.). This doesn’t mean it’s challenging to navigate for human beings, but it takes longer for search engines to process because they need to parse your site in an actual browser. A sitemap will then become an essential tool for indexing your pages quickly.

Your site publishes news: indexing ASAP

News publishers need to get their pages indexed as soon as possible. To help search engines, you can attach <lastmod> timestamp values to each link in the sitemap. Aptly, these timestamps indicate when pages were last modified. Search engine crawlers read these, and when a timestamp is more recent than what they logged before, they’ll recrawl the page more quickly.

If your site is connected to Google News, then a Google News sitemap will help you tremendously. Google crawls this sitemap type and its content with a greater priority than anything else. To speed up parsing, they want you to limit the Google News-sitemap’s with content published only within the past two days, with at most 1 000 links. We provide a Google News sitemap via our Articles extension.

Do I need a sitemap with WordPress?

Talking about 99.99% of WordPress sites? No. WordPress does not benefit from sitemaps much. Let’s go over the benefits of the sitemap again, so that you can decide you need one.

Discovering all pages: When you start with WordPress, you won’t accumulate hundreds of pages instantly. You’d probably write at most one blog post a day (perhaps, you feel jazzy and publish an about page) — something which with search engines can easily keep up.

Prioritized crawling: WordPress makes it easy for search engines by spawning links to tag-and category-pages everywhere. Those help search engines find your latest pages and posts eventually — often within a few days. Nevertheless, if your site is over 500 pages large, a sitemap will probably help accelerate this process a bit.

Maintaining intent: If you use an (at least, our) SEO plugin and adequately categorize your pages and organize your menus so that even a human could navigate your website easily, then intent is kept, and you won’t need a sitemap.

Substitute bad hierarchy: If your site’s hierarchy is terrible, then you probably won’t need a sitemap because no one will visit anyway. However, if you use complex protocols that confuse search engines to process your site slowly, then yes, you probably need a sitemap; otherwise, you still won’t need one.

Indexing ASAP: Only when your content is of utmost evanescent importance (news or the cure for disease X), then you’ll require fast indexing. But let’s be honest, you’re impatient, so you’ll ignore everything postulated on this page and want a sitemap anyway. If you’re managing a news publisher’s site, then you genuinely need a sitemap and will pardon our presumptuousness from the sentence before.

The sitemap of The SEO Framework

The base sitemap we bring in TSF plugin is small and consists of one page only. We use one page for the reasons described above: Search engines process it easily and rapidly.

Only posts and pages are included in the sitemap of The SEO Framework; you won’t find archives, attachments, or author pages therein. We exclude those because most themes already properly provide internal linking, among technical difficulties.

The sitemap lists posts by last modified date, newest first. When your site has more posts than the sitemap query limit allows, the least recently modified ones drop out. Password-protected posts never appear. Set the limit at SEO Settings → Sitemap Settings, under the General tab. An empty limit uses the default of 250.

The sitemaps from TSF are virtually generated via PHP and aren’t stored on your website’s drive. This feature adds support for WordPress multisite environments, where multiple WordPress websites can work from one directory — storing the sitemap on the drive would otherwise prevent outputting unique sitemaps for each site.

Multiple sitemaps

TSF‘s sitemaps are dynamic and have unlimited sitemap endpoints, accessible from /sitemap.xml. You can add anything to the endpoints, like /sitemap.xmlanything.

We added this feature to automatically support any random translation plugin because that adds /es/ or ?lang=es to WordPress URLs. You can learn more about this on our KB article about translation plugin compatibility.

We also added the /sitemap_index.xml endpoint to support misconfigured hosts that cater to Yoast SEO. If you can access /sitemap.xml, your website is configured correctly in this regard, and you can ignore the /sitemap_index.xml one.

We were forced to add support for /sitemap_index.xml because the people at Yoast intentionally work in bad faith against the spirit of Open Source. We notified them many times in the past decade, and they still arrogantly create vendor lock-in by spreading broken NGINX configurations. We expound on this in the NGINX support section.

Robots.txt integration

If there’s no custom robots.txt file in the root folder of your website, TSF can add sitemap URLs to robots.txt.

With the optimized sitemap enabled, robots.txt lists /sitemap.xml. With WPML or Polylang in subdirectory, parameter, or Polylang “from content” format, it also lists each extra language sitemap. TranslatePress adds the sitemap of every language that has a language directory. With WordPress Core sitemaps, it lists the Core index (/wp-sitemap.xml) instead.

Toggle this at SEO Settings → Sitemap Settings, under the General and Robots.txt tabs.

For the language URLs and which formats get extra robots.txt lines, see our translation plugin compatibility article.

Ahrefs reports that the sitemap is duplicated!?

TSF‘s sitemap can be accessed from an unlimited number of endpoints. It’s not a bug, but a feature.

Ahrefs marks it as an issue because was a problem in other SEO plugins that pointed search engines directly to the duplicated sitemaps via internal links. This prompted search engines to crawl copies of the sitemap over and over again, wasting resources and harming indexing performance.

After this issue was discovered, Ahrefs reports about this. They always look for the /sitemap.xml and /sitemap_index.xml endpoints, since those are the most common endpoints used by other SEO plugins. Because these are the same with TSF, Ahrefs immediately reports this as an issue. But this is not how search engines discover or handle sitemaps.

TSF does not generate internal links to all these endpoints. robots.txt lists the primary sitemap and the extra language sitemaps described above. Search engines won’t treat every possible /sitemap.xml... suffix as a sitemap they must recrawl.

This is not a real world issue; only for Ahrefs.

Updating the sitemap

TSF caches the sitemap’s generated content in the database for 604 800 seconds (1 week). It refreshes whenever you:

• Update, publish, or delete any type of post or page, including through the WordPress REST API or WP-CLI;
• Update the permalink settings;
• Or update the SEO settings.

If the sitemap doesn’t update accordingly, you might have a caching plugin enabled that interferes with the sitemap’s cache. Please see if you can exclude the sitemap, or flush it periodically otherwise.

Cache plugins without exclusion rules for the sitemap and sitemap stylesheet endpoints could serve an empty sitemap or stylesheet on later visits. Since TSF v5.2.0, we tell cache plugins that honor DONOTCACHEPAGE not to store those responses. That does not remove an empty response your cache already stored. After updating, run your cache plugin’s “Purge All,” “Clear all cache,” or equivalent full-cache action. Do not purge only sitemap.xml, sitemap_index.xml, sitemap.xsl, or sitemap.css, because cache plugins can store variants by host, scheme, compression, mobile view, language, or query state. Also do not count on the plugin update to clear the cache. Most cache plugins don’t purge their whole page cache on updates.

Excluding posts and pages

You can exclude posts and pages from the sitemap by applying noindex to them.

Where do I find my sitemap link?

Open SEO Settings → Sitemap Settings and look under “Output optimized sitemap?” on the General tab. With the optimized sitemap, that tab links “View the base sitemap.” With WordPress Core sitemaps, it links “View the sitemap index.” instead.

Those links reflect the saved setting. After you toggle “Output optimized sitemap?”, save your settings first. Until then, the page warns you that the sitemap links will update after saving.

Translation plugins

WPML, Polylang, and TranslatePress get a unique optimized sitemap per language. Open SEO Settings → Sitemap Settings and use “View translated sitemaps” for the advertised URLs. For URL formats, robots.txt, and known issues, see translation plugin compatibility.

NGINX support

NGINX is a web server meant to improve performance and scalability with statically loaded files. Since WordPress always serves its pages dynamically (even when using a caching plugin), NGINX must proxy to a PHP process, which negates NGINX’s performance benefits and adds complexity. Custom configurations of NGINX can prevent the proxy from calling WordPress, which is why you might be experiencing issues with NGINX.

NGINX’s configuration language is very powerful and straightforward […], but often people coming from other servers are not sure how things work in NGINX and just copy and paste whatever they see from a blog that seems to fill their needs. — NGINX

NGINX must be configured correctly to display dynamically created pages, including TSF’s sitemaps. We recommend relying on WordPress’s proposed NGINX configuration. This configuration will work as-is with most WordPress setups.

If you don’t know how to fix NGINX configuration issues, please reach out to your hosting provider.

NGINX: The sitemap redirects

If the /sitemap.xml endpoint redirects to /wp-sitemap.xml or /sitemap_index.xml, and perhaps even shows a 404-error because of that, you’ll have to remove all sitemap-related configurations from your NGINX configuration file, which might’ve been erroneously added by your hosting provider or NGINX installation script.

After you’ve removed the misconfigurations, you may experience some of the other issues listed below. You’ll need to fix those as well.

NGINX: The sitemap shows a 404-error

Some NGINX configurations instruct .xml endpoints independently; therefore, those can’t resolve via WordPress’s /index.php file. Because TSF relies on WordPress to display its sitemaps virtually, the sitemaps will resolve with a 404-error. To fix this issue permanently, you must remove the xml-part from any location ~* .([...]|xml)$ configurations.

You can work around this issue by adding -alt to the sitemap’s endpoint and submit that URL to Google and Bing’s sitemap reports — for example: https://example.com/sitemap.xml-alt. However, we recommend foregoing this workaround and fix the cause instead.

Why did the sitemap stop being clickable?

A sitemap is XML. Browsers used to run an XSLT stylesheet attached to that file. That transform rebuilt the XML as a normal page, with clickable URLs and formatted dates.

Chrome is removing XSLT from the browser. From Chrome 158 (17 November 2026), Chrome ignores type="text/xsl" stylesheets. Firefox and Safari have indicated they will follow. Search engines never used the stylesheet. This only changes what you see when you open your WordPress /sitemap.xml in a browser.

This is a browser problem, not a ranking problem, and not something we chose. Chrome’s stated reason is security: the library that runs XSLT in Chromium is old C code with a history of memory bugs. That is a real engine problem. The web still has no replacement that can turn XML element text into a hyperlink. Chrome kept XML+CSS, which can paint a layout. CSS cannot make a <loc> URL clickable. CSS cannot reformat timestamps. They removed the useful half of XML presentation and left the decorative half.

The XSL view pretty-prints <lastmod> (date and time, time zone dropped) so our users are not tempted to change the timestamp format incorrectly. That pretty date is not stored in the XML. The CSS view has no equivalent, so you will see the raw W3C datetime, like 2026-08-27T15:51:00+00:00. Leave it. Do not “prettify” <lastmod> with a human date, a locale string, or a space instead of T. Crawlers expect W3C-NOTE datetime. A pretty lastmod is invalid, and they may ignore it. If you want a shorter lastmod, use SEO Settings → General Settings → Timestamps and pick the date-only format (YYYY-MM-DD). That is still valid. It also changes timestamps elsewhere on the site, not only the sitemap.

We will not inject JavaScript or a WebAssembly XSLT polyfill into the sitemap. That file is for crawlers. Shipping the same discarded XML library as WASM would recreate the attack surface Chrome used to justify the removal.

What you get instead:

• Browsers that still run XSLT keep the clickable sitemap.
• Browsers that dropped XSLT get a CSS-styled sitemap.
• The CSS view is not clickable, but it is still easier to scan than raw XML.
• Search engines keep reading the same XML they always did.

Compared to the XSL sitemap, the CSS view cannot do the following. These are browser limits, not ranking limits:

• URLs are not links. You cannot click, Ctrl/Cmd-click, or tab to a <loc> URL. Copy still works; the full URL is in the XML.
• The title and logo do not go to the homepage. In XSL they wrap an <h1> in a link. CSS can only paint the logo and title.
• Intro and footer links are plain text. XSL turns the Google, Bing, sitemaps.org, and The SEO Framework mentions into real links. CSS content cannot. The labels remain; the destinations do not.
• Last Updated is the raw W3C datetime stored in <lastmod>, not the XSL pretty date and time. See the paragraph above: do not prettify the XML to hide this.
• Phones do not get a mobile viewport. XSL emits <meta name="viewport" content="width=device-width, initial-scale=1">. A CSS stylesheet on XML cannot. Mobile Chrome keeps a desktop-width layout and shrinks it. You pinch-zoom. Breakpoints in CSS cannot fix that.
• Long URLs clip with an ellipsis to the column width, instead of wrapping. XSL also shortens visible link text after 95 characters, but the href stays complete and clickable.
• The browser tab has no document title. XSL sets XML Sitemap plus the site name. CSS cannot set <title>. The tab usually shows the sitemap URL. Site icon tags from WordPress are also missing from this document.
• It is not an HTML page. There is no heading outline or data table for assistive technology. The header and description live in CSS generated content, so find-in-page may skip them. Column labels sit on the first URL row, not a separate header row.

Chrome 158+ (17 November 2026) uses the CSS view. Firefox and Safari keep the XSL view until they drop XSLT, so the same sitemap can look different by browser.
There is no workaround that restores clickable URLs in the sitemap. The CSS stylesheet is a plain sitemap — not all too accessible, but better than nothing. If that is still too much, disable styling at SEO Settings → Sitemap Settings, under the Style tab. You will see raw XML. That is less accessible than the CSS view. It is still fine for Google and Bing.

The sitemap shows a blank page

If you notice that the sitemap shows a blank page, inspect the source (CTRL+U on Windows) of the sitemap and see if anything’s there. If you find something, disabling the styling of the sitemap should fix the issue immediately. There are multiple causes for this issue.

1. You may’ve accessed the sitemap from a domain that’s not alike the one you’ve set in the General Settings of WordPress. Since XSL (XML stylesheet) files are executable scripts, they’re applicable to CORS-related directives. Make sure you’re accessing the sitemap from the same domain as configured in WordPress–even the subdomain (www.) and the protocol (https://) must match.
2. On NGINX, you may’ve configured .xsl endpoints incorrecty. Apply the same fixes for NGINX listed above, but then for xsl instead of xml.

If disabling the sitemap’s stylesheet doesn’t resolve the issue, then you may’ve increased the sitemap’s query-limit too high — we recommend lowering it to a query-limit of 3000 or below. And if even that doesn’t resolve the issue, then you may experience plugin or theme conflicts.

The sitemap is locked

The sitemap locking mechanism helps mitigate DoS attacks. This feature only works with sitemap transient caching enabled. Essentially, the sitemap locks itself when two or more threads try to generate the sitemap concurrently.

The lock’s duration is equal to PHP’s max-execution-time set by the server, or 3 minutes — whichever takes less time. The lock releases early when the sitemap’s generation is completed; so, the timer only indicates the “worst-case scenario.”

When a locked sitemap is presented to a search engine crawler, TSF will also hint that the search engine should try again later by sending an HTTP 503 status error.

The lock should resolve itself. When it doesn’t, you should consider lowering the sitemap’s query-limit or otherwise enable sitemap prerendering. Sitemap prerendering also mitigates issues when search engines timeout or face a locked sitemap.

Inspecting via Google Search Console

TSF prevents indexing of its sitemaps because they aren’t helpful landing pages for human visitors. So, when you inspect the sitemap via the URL inspector, Google Search Console will report that it’s not indexable and perhaps some other errors. You can safely ignore these notices.

You’ll find a “Sitemaps” report under the “Index” tab in the sidebar menu at Google Search Console. There, you can submit, manage, and inspect your sitemaps properly.

Using Core Sitemaps

WordPress 5.5 empowers every WordPress website with a native sitemap. You can activate them by deactivating TSF‘s sitemap, provided that another plugin or theme hasn’t disabled them.

We don’t believe the Core Sitemaps are beneficial for most WordPress sites. We stubbornly kept our sitemap simple; it’s easier for us to maintain and faster search engines to process. Search engines crawl your pages more quickly using TSF’s sitemap, no matter your website’s size.

WordPress Core sitemaps do not get TSF’s per-language extras for WPML or Polylang.

TSF also augments the Core sitemaps:

• The posts sitemap omits password-protected posts.
• The users sitemap lists only authors who have published posts.
• The users sitemap omits authors whose archive is set to noindex or to redirect. That follows the site-wide author archive settings and each author’s own profile settings.
• An author you set to index on their profile page stays in the users sitemap, even when you set all author archives to noindex.
• The users sitemap stays registered when you set all author archives to noindex. It returns a 404 error when no author is indexable.

Nevertheless, when using Core Sitemaps in combination with TSF, most Sitemap Settings (on the SEO Settings page) will affect the sitemap. Since TSF v5.0.5, the availability of these settings dynamically change, depending on which sitemap you choose.