Common questions & solutions

A site’s homepage (the bare domain, with or without a trailing slash) is a special case for several engines. Each one decides whether to accept the homepage independently, so it’s normal to see a mix of Succeeded and Dead on the same URL across engines:

• Bing / IndexNow — accepts the homepage as long as the host matches the verified key file.
• Yandex / Seznam — generally accept the homepage without extra setup.
• Naver — frequently rejects the bare homepage with Invalid urls error.

The retry policy on Dead rows respects each engine’s rules, so fixing the underlying registration / verification will let future submissions go through cleanly without you having to re-queue old rows.

“Invalid urls” is what Naver returns when its API doesn’t recognise the destination as a property it’s allowed to accept submissions for. It is not a comment on the HTTP health of the URL — Naver doesn’t fetch it before responding.

Checklist:

1. The site is registered in Naver Search Advisor under the exact host you’re submitting (apex vs. www. matters).
2. Ownership is verified (HTML file or DNS TXT). Unverified properties always get Invalid urls.
3. The API key you stored in BetterIndexNow belongs to the same Naver account that owns that verified property.
4. The URL is under the verified host root — submitting a path from a different subdomain than the one verified will fail.

If you don’t plan to support Naver yet, you can disable it on the site’s Engines panel — those rows will stop being created and existing Dead rows can be ignored.

IndexNow requires every URL in a submission batch to share the same host as the key file. If your site emits both apex and www. URLs, the ones on the wrong host get marked Skipped with reason host_mismatch. Verify the other host as its own site and submissions will be routed correctly.

• blocked_by_robots — the URL’s robots.txt disallows our preflight user-agent.
• noindex — the page returned <meta name="robots" content="noindex"> or an X-Robots-Tag: noindex header.
• canonical_differs / canonical_other_host — the page’s <link rel="canonical"> points elsewhere, so submitting the original would waste crawl budget.
• bad_status — the origin returned a 4xx/5xx for our preflight fetch.
• host_mismatch — the URL’s host doesn’t match the site you registered.

Transient failures (network errors, 5xx, timeouts) get an automatic exponential-backoff retry up to the per-engine attempt cap. Permanent failures (4xx, the engine explicitly rejecting the URL) are terminal and not retried — you can re-queue them manually after fixing the underlying issue.

Google doesn’t participate in IndexNow, so we don’t ping it the same way. Instead, BetterIndexNow uses the Google Indexing API to submit supported content and Google Search Console to read real indexing status. IndexNow itself notifies Bing, Yandex, Seznam, and Naver. You get the right channel for each engine from one account.

• Free — every 24 hours
• Pro — every 6 hours
• Agency — every 1 hour

On the first poll of a sitemap we record the URLs we found but don’t enqueue them — otherwise we’d submit the entire archive on day one and burn through your quota. From the next poll onwards, only URLs that newly appear are auto-submitted. You can manually queue any of the existing URLs from the site page if you want them pushed immediately.

Submitting a URL doesn’t guarantee it gets indexed — and engines don’t tell you when something quietly drops out. Index monitoring closes that gap.

BetterIndexNow checks the real indexing status of your URLs on Google (Search Console) and Bing (Webmaster Tools), keeps re-checking them over time, records every change as an event, and shows current status plus full history for each URL. It’s what powers the daily summary email.

1. Open the site and switch to its Index Monitoring tab.
2. Connect Google Search Console and/or Bing Webmaster Tools and map the matching property, if you haven’t already.
3. Enable monitoring.
4. We seed the URLs we already know about (from your sitemap and past submissions) and begin checking their status. From there, newly discovered URLs are picked up automatically — no further action needed.

For each URL, per engine, we surface:

• ✓Indexed
• ✓Crawled — currently not indexed
• ✓Discovered — currently not indexed
• ✓Not indexed
• ✓De-indexed
• ✓Excluded
• ✓Noindex
• ✓Redirected
• ✓Soft 404
• ✓Duplicate
• ✓Blocked

Automatically, on a schedule we manage for you. Active and problem URLs (recently changed, not indexed, recently de-indexed) are re-checked more often, while stable, long-indexed URLs are checked less frequently to conserve each engine’s API quota. Newly discovered URLs start being monitored on their own — you don’t queue checks manually.

Yes. Most URLs are discovered from your sitemap automatically, but you can also enrol pages by hand with Add URLs:

• Up to 1,000 URLs per request.
• Each URL must be on this site’s own host (the apex and www. are treated as the same site); anything off-host is skipped.
• The site needs Google Search Console or Bing Webmaster Tools connected first.

This is also the way to use index monitoring on a site that doesn’t publish a sitemap at all.

That’s expected. The first round of checks takes a little time, so instead of an empty table you’ll see a “we’re gathering indexing information — check back shortly” notice. Status and history fill in as Google and Bing report back.

Indefinitely. Every status change is recorded as an immutable event, so the complete timeline for each URL — submitted, crawled, indexed, de-indexed, re-indexed, redirected, canonicalized — is always available for audit.

Both connect Google Search Console, but they do different jobs:

• Service account (bring your own Google Cloud project) — reads indexing status and enables URL submission via the Google Indexing API.
• OAuth — reads indexing status only. Submission stays off until a service account is added.

For full Google coverage (status + submission), connect a service account.

A connection authenticates your Google or Bing account; a property mapping tells us which Search Console / Bing Webmaster property corresponds to this site. Without the mapping we can sign in but can’t read this site’s data, so its status stays unavailable until you map it. That’s why a site can show a connected account but still need attention.

• Red — no connection for that engine, or the site is mapped to a connection that’s broken.
• Yellow — connected and healthy, but this site still needs action: the property isn’t mapped yet, or (Google) only OAuth is connected with no service account, so submission is off.
• Green — connected, healthy, and mapped — plus, for Google, an org-level service account is available.

An index status card shows Not connected when that engine has no working connection for the site — either it was never connected, or its token/credentials expired and need re-authorising. Reconnect the engine to restore status; it never reports a misleading “0 indexed” for an engine it can’t read.

Only on days when something actually changed — no change means no email, so the digest stays signal, not noise. When it does send, it covers:

• Gains — newly indexed and re-indexed URLs.
• Losses — newly de-indexed URLs and pages that moved into problem states.
• Discoveries — newly discovered and crawled URLs.
• Summary — net indexed change, total events, and a Google vs Bing breakdown, with links back to the dashboard.

One URL successfully delivered to one engine = one submission. Fanning the same URL out to four engines counts as four (one per engine). Preflight-skipped URLs are free.

We allow a small soft buffer, after which new submissions return HTTP 402 with an upgrade pointer. Reads (dashboard, audit log, exports) keep working, and existing in-flight submissions finish.

Email alerts (usage thresholds, webhook delivery failures) are included on Pro and Agency. On the Free plan the toggle is hidden because we don’t fire those emails. Upgrade to turn them on.