How to set up IndexNow on WordPress (without breaking anything)

WordPress is the most common platform we see, and also the one where IndexNow setups most often fail silently. Here are the three approaches, in order of reliability.

Step one: the key file (all methods need this)

IndexNow verifies that you control a domain by requiring a text file at its root, named after your key and containing only that key. Nothing works until this is in place.

1. Generate a key — 8 to 128 characters of letters, digits and hyphens. A 32-character hex string is always valid.
2. Save it as yourkey.txt, containing just the key.
3. Upload it to the folder containing wp-config.php — usually public_html, httpdocs or www. Not into wp-content or your theme folder.
4. Visit https://yoursite.com/yourkey.txt. You should see the key and nothing else.

No FTP access?

Serve it from code instead. Add this to your theme's functions.php — ideally a child theme, so a theme update does not wipe it:

add_action('init', function () {
    $key = 'YOUR_KEY_HERE';

    if (trim($_SERVER['REQUEST_URI'], '/') === $key . '.txt') {
        header('Content-Type: text/plain; charset=utf-8');
        echo $key;
        exit;
    }
});

Method 1: a plugin

Several SEO plugins now include IndexNow support, and Bing publishes an official one. This is the lowest-effort route.

What to watch for: most plugins fire a submission on every post save. That includes autosaves, minor typo fixes and bulk edits, which is exactly the behaviour the protocol asks you to avoid — the guidance is to leave at least five minutes between updates to the same URL and to submit only meaningful changes. On a busy site this can get you rate limited with HTTP 429.

It also only covers posts and pages saved through the WordPress admin. Products changed by a stock sync, listings updated by an import, or anything touched directly in the database will not trigger it.

Method 2: roll your own

Hook transition_post_status and POST to the API yourself:

add_action('transition_post_status', function ($new, $old, $post) {
    if ($new !== 'publish' || $old === 'publish') {
        return;
    }

    wp_remote_post('https://api.indexnow.org/indexnow', [
        'headers' => ['Content-Type' => 'application/json; charset=utf-8'],
        'body' => wp_json_encode([
            'host' => parse_url(home_url(), PHP_URL_HOST),
            'key' => 'YOUR_KEY_HERE',
            'keyLocation' => home_url('/YOUR_KEY_HERE.txt'),
            'urlList' => [get_permalink($post)],
        ]),
    ]);
}, 10, 3);

Note the $old === 'publish' guard: without it, every subsequent edit resubmits. This is the single most common bug in hand-rolled implementations.

What to watch for: no retry on failure, no logging, no visibility when it silently stops working after a plugin conflict, and no handling of the 10,000-URL limit if you ever want to submit in bulk.

Method 3: an external service

Something outside WordPress reads your sitemap on a schedule, works out what genuinely changed, and submits it. Nothing runs inside your site, so plugin conflicts and theme updates cannot break it, and changes made outside the admin are still caught.

That is what Index-now does, for $12 per domain per year. You still host the key file — that part is unavoidable — but everything after it is external.

How to tell whether it is actually working

This is where most people are flying blind. Three checks:

1. The key file loads. Open the URL in a private window. A styled 404 page returned with HTTP 200 is the classic trap — it looks fine to you and fails verification.
2. Bing Webmaster Tools shows submissions. Its IndexNow section reports URLs received. If it is empty a week after setup, nothing is being sent.
3. You can see the response codes. A 200 or 202 means accepted. A 403 means your key file is missing or wrong. A 422 usually means you submitted URLs for a host your key does not cover — often the www variant.

WordPress-specific gotchas

• Caching plugins. WP Rocket, W3 Total Cache and LiteSpeed will happily cache the 404 you got before uploading the key file. Purge after uploading.
• Security plugins. Wordfence and similar sometimes block root-level .txt requests from unknown user agents. Allowlist the file if verification fails despite the file being there.
• www vs non-www. Your key file must be on the same host as the URLs you submit. If your site canonicalises to www., that is the host you verify.
• Multisite. Each site with its own domain is a separate host and needs its own key file.