Indexing tools inside your AI assistant
Connect Instant IndexNow to Claude, ChatGPT, Cursor or any MCP client and it can check indexability, trace redirect chains, test robots.txt, read meta tags and response headers, validate sitemaps and submit URLs via IndexNow: against live sites, not from memory.
A remote server: nothing to install, no account, no API key.
Server URL
https://instantindexnow.com/mcp
Streamable HTTP transport. No authentication.
Connect it
Claude Code
One command:
claude mcp add --transport http Instant IndexNow https://instantindexnow.com/mcp
Claude desktop & web
Settings → Connectors → Add custom connector, then paste the server URL. No authentication is required, so leave those fields empty.
ChatGPT
Settings → Connectors → Create, paste the server URL, and choose No authentication. Available on the plans where custom connectors are enabled.
Cursor, Windsurf, Zed and others
Add to your MCP config file:
{
"mcpServers": {
"Instant IndexNow": {
"url": "https://instantindexnow.com/mcp"
}
}
}
The 11 tools
10 read-only checks, and one that submits.
check_indexability
read-only
Checks every signal that can keep a URL out of a search index, in one pass: HTTP status, robots.txt, the robots meta tag, the X-Robots-Tag response header, and the canonical. Returns a verdict plus the specific rule responsible for each blocker. Also flags the robots.txt-plus-noindex combination, where the crawler never fetches the page and therefore never sees the noindex, so an already-indexed URL can persist indefinitely.
check_redirects
read-only
Follows one URL through every redirect hop and returns the status code, timing, mechanism (HTTP Location, meta refresh or JavaScript), cookies set and security headers at each step. Detects loops and chains that end on a 4xx or 5xx. Useful for finding a 301 that points at a dead page, which a plain status check of the starting URL hides because it reports the redirect's status rather than the destination's.
test_robots_txt
read-only
Fetches a site's robots.txt, parses every group, and tests whether given paths are crawlable, applying RFC 9309 precedence: the most specific user-agent group wins, then the longest matching rule, with Allow beating Disallow on an equal-length tie. Returns the exact rule that decided each answer. Also reports the status-code handling, which runs opposite to intuition: a 4xx on robots.txt means no rules apply at all, while a 5xx means crawlers should stay away entirely.
check_meta_tags
read-only
Returns the title, meta description, canonical, robots directives, Open Graph and Twitter card tags, hreflang alternates, language, viewport and H1s: read from the raw HTML as delivered, before any JavaScript runs. Tags injected client-side will therefore be reported as missing, which is deliberate: that is also how social crawlers see the page, and why a link preview can be blank when the tags look correct in a browser inspector.
check_http_headers
read-only
Returns every response header with a plain explanation, and lists which common security headers are absent. Highlights X-Robots-Tag, which carries the same directives as the robots meta tag but as a header: invisible in the page source, and therefore the hardest indexing block to find by hand. Deliberately produces no numeric security score, because any such number would be invented.
check_sitemap
read-only
Locates and reads an XML sitemap the way a crawler would: robots.txt Sitemap: directives first, then the conventional paths. Follows sitemap index files and totals across them. Returns the URL count, lastmod values and any parse errors. Pass a bare domain to have it discovered, or a full sitemap URL to read that one directly.
bulk_check_urls
read-only
Takes up to 25 URLs and returns, for each, the status of the URL you supplied, the status after following redirects, how many hops it took, and the final destination. Reporting the first and final status separately is the only way to see a 301 that lands on a 404. URLs the request budget could not reach are returned marked as unchecked rather than silently omitted.
verify_indexnow_key
read-only
Fetches https://{host}/{key}.txt the way a search engine does and reports whether it would pass validation: verified, not_found, mismatch, bad_status or unreachable. This matters because the shared IndexNow endpoint, Bing and Yandex all answer 202 Accepted for a submission whose key was never published, validate it asynchronously afterwards, and discard it silently on failure, so a 202 is not evidence a submission will be honoured. Naver, Seznam, Yep and Amazon validate during the request and return 403 instead.
generate_indexnow_key
read-only
Returns a spec-compliant IndexNow key and the filename to publish it under. The key is not a secret: the protocol requires it to be world-readable at your domain root, and it proves control of the host rather than granting access to anything.
list_indexnow_engines
read-only
Returns the search engines this server can submit to, and, the useful part, whether each validates your key during the request or afterwards. Engines that validate asynchronously return 202 for a broken key; engines that validate synchronously return 403. Google is absent because Google does not participate in IndexNow.
submit_to_indexnow
has an external effect
Notifies participating search engines that URLs have changed. The key file is fetched and verified BEFORE anything is sent, and nothing is submitted if it does not resolve. Reaches Bing, Yandex, Naver, Seznam, Yep and Amazon, not Google, which does not participate. This has a real external effect: it asks live search engines to crawl the URLs given, so only call it for URLs that genuinely changed and that the user controls.
Why give an assistant these tools
An AI assistant asked why a page is not indexed will produce a plausible list of causes. It cannot tell you which one is yours, because it has not read your robots.txt, followed your redirects or seen your response headers. With these tools connected it can, and the answer stops being a checklist and becomes a diagnosis.
Two of the checks matter more than they sound. A redirect chain that ends on a 404 is
invisible to a plain status check, because the URL you tested honestly reports a healthy
301. You have to follow it to the end to find the dead page. And a
noindex delivered as an
X-Robots-Tag header appears nowhere in
the page source, so it survives every review that consists of reading the HTML.
The submission tool verifies your key file before it sends anything. That is worth stating
plainly, because the alternative is worse than useless: the shared IndexNow endpoint, Bing
and Yandex return 202 Accepted for a
submission whose key was never published, check the key afterwards, and discard the
submission without notifying anyone when that check fails. Naver, Seznam, Yep and Amazon
validate during the request and return 403
instead, which is why one broken key can look like success on three engines and failure on
four.
Questions
What is an MCP server?
Do I need to install anything?
Does it cost anything, and do I need an account?
Can it submit URLs to Google?
Will it submit URLs without asking me?
Why does the key file get verified first?
Prefer the browser?
Every one of these tools also exists as a web page: the indexability checker, bulk redirect checker, robots.txt tester and the rest, and there is a REST API if you would rather script it.