IndexNow for WordPress
Three ways to set it up, and the WordPress-specific reasons the key file fails validation while appearing to work.
Quick answer
Install one IndexNow plugin — either Bing's official IndexNow plugin or the IndexNow feature already built into Rank Math, Yoast, All in One SEO or SEOPress. Then check that the key file actually resolves, because WordPress has several ways of making a missing file look present. IndexNow reaches Bing, Yandex, Naver, Seznam, Yep and Amazon — not Google.
Pick one route, not two
Every route below ends in the same place: a key file at your site root, and a request sent when a
post is published or updated. What differs is who does the work. Run exactly one of them — two
plugins each generating their own key means two key files, and the submissions made with the
losing key are accepted with a 202
and then quietly discarded.
1. Bing's official IndexNow plugin
Published by the Bing Webmaster Tools team, around 100,000 active installs. It generates the key, serves the key file through WordPress itself, and submits on publish and update. Nothing to configure beyond activating it.
Best when you have no SEO plugin, or your SEO plugin has no IndexNow feature.
2. The SEO plugin you already run
All four of the major SEO plugins ship IndexNow support. Using the one you already have avoids a second plugin and a second key.
| Plugin | Where to find it |
|---|---|
| Rank Math | Enable the Instant Indexing module, then its IndexNow section |
| Yoast SEO | IndexNow integration, enabled from the integrations screen |
| All in One SEO | IndexNow, alongside the other search-engine notification settings |
| SEOPress | Instant indexing, which covers IndexNow for Bing and Yandex |
Menu labels move between releases — look for "instant indexing" or "IndexNow" rather than a fixed path.
3. No plugin at all
The protocol needs a readable file and an HTTP request. Nothing about that requires PHP running in your site.
- Generate a key and download the
{key}.txtfile. - Upload it to your site root over SFTP or your host's file manager — the directory holding
wp-config.php. - Confirm
https://example.com/{key}.txtloads in a private window. - Submit your URLs from the submit page, or from a script against the API.
Best for sites where new content is rare enough that submitting by hand costs nothing, or where publishing is already driven by CI rather than the WordPress editor.
Why the key file fails on WordPress specifically
A static host either serves the file or returns 404, and either way you know where you stand. WordPress sits in front of every request that does not match a file on disk, which produces failures that look like successes. These are the ones worth checking, roughly in order of how often they are the cause.
The 404 page is served with HTTP 200
This is the one that wastes the most time. WordPress rewrite rules hand the request to
index.php, some themes and page
builders then render their "not found" template with a
200 OK status, and the response body is an HTML page rather
than your key.
A search engine fetching that file sees a valid response whose contents are not the key, so
validation fails — but nothing in your dashboard says so. Our checker reports this as
mismatch and shows you the first
characters it actually received, which makes the cause obvious immediately.
A security plugin is blocking .txt requests
Hardening rules that block direct access to non-PHP files, or that challenge unknown user agents, apply to search engine crawlers fetching your key file too. The symptom is a 403 rather than a 404 — the file exists, it is just not readable by the party that needs to read it. Whitelist the exact key file path rather than disabling the rule.
A cache or CDN is still serving the old 404
Page caching plugins and CDNs cache negative responses. If you tested the URL before uploading the file, that 404 may be cached at the edge for hours. Purge the cache after publishing the key file, then retest — from a private window, because your browser cached it as well.
The file went into /wp-content/uploads/
The WordPress media library is the obvious place to put a file, and it is the wrong one. The key
file has to sit at the host root. If you genuinely cannot write there, the protocol allows the
file to live elsewhere on the same host as long as you pass its URL as
keyLocation when submitting.
The host does not match your canonical URL
A key file published at www.example.com
proves nothing about example.com.
They are separate hosts as far as the protocol is concerned. Submit the same host your
canonical tags and sitemap use, and make sure the key file resolves on that host without a
redirect — some engines do not follow one.
Multisite subdirectories
On a subdirectory multisite, every site shares one host, so one key file at the root covers all of them. On a subdomain multisite each site is its own host and needs its own key file. Plugins activated network-wide do not always get this right — check each site's file separately.
Verify before you believe the 202
The reason all of this matters: the global IndexNow endpoint, Bing and Yandex return
202 Accepted for any well-formed
submission, including one whose key was never published. The key is validated later,
asynchronously, and a failed validation discards the submission without notifying anyone.
So a WordPress plugin showing a green tick has told you the request was well-formed. It has not told you the submission will be honoured. Checking the key file yourself is the only way to know, and it takes a few seconds.
What IndexNow will and will not do for a WordPress site
It removes the discovery wait
Engines learn the URL exists within seconds instead of waiting for a crawl or a sitemap fetch.
It does not force indexing
A notified URL still has to clear the same quality bar. Thin or duplicate posts stay out either way.
It does not reach Google
Google does not participate. Your sitemap and internal linking are still what Google works from.
It does not replace a sitemap
IndexNow announces changes. Your sitemap is still how engines reconcile what your site contains.