Most Fetchie problems come down to one thing: something standing between the indexer and your rendered pages. This page starts with the one-click diagnosis, then works through the usual suspects.
—
Start Here: the Test Page Fetch
On Tracksies > Fetchie > Index, click Test page fetch. Fetchie fetches your homepage exactly the way the indexer fetches every page — anonymously, as a logged-out visitor — and tells you what came back:
- “Rendered pages fetch fine — N words read from your homepage” — the fetch path is healthy. If search results still look thin, the issue is elsewhere on this page
- A warning that rendered pages can’t be fetched — the indexer is being blocked. Read on
Run this before rebuilding, not after. A rebuild against a blocked fetch path wastes the whole pass on thin content.
—
The Thin-Content List
When documents couldn’t be indexed from their rendered pages, the Index tab shows a warning listing them: they were indexed from stored post content instead, which is thin for builder-built pages — their body text may be missing from search. The list is your map of what needs re-fetching. Fix the cause below, then click Rebuild index to retry.
—
Why Rendered Fetches Fail
Three causes account for nearly all of it:
- Maintenance or coming-soon mode. Logged-out visitors get a placeholder page, and the indexer is a logged-out visitor. Finish launching, or allowlist the indexer (next section), then rebuild
- A security plugin or firewall rule blocking automated requests, or rate-limiting bursts of requests from the site’s own address
- Blocked loopback requests. Some hosts stop a site from making requests to itself. Your host can confirm and usually fix this in minutes — it also affects WordPress’s own cron and site health checks, so they’ll know exactly what you mean
Individual pages can also fail for their own reasons — a page that redirects, errors, or responds with something other than a normal page won’t index from render. Those show up in the thin-content list too.
The search-bot tip
Fetchie’s indexer identifies itself politely: its requests carry the user agent Fetchie-Indexer. Most maintenance-mode and security plugins have an allowlist for search engine crawlers and named bots — add the Fetchie indexer there and it can read your pages even while real visitors see the coming-soon screen. That lets you build the index before launch day.
—
“My Insights Numbers Look Low”
Usually not a bug — three deliberate choices:
- Administrator searches are never logged. Your own testing doesn’t count, on purpose
- Page two isn’t a new search. Paging through results counts once
- Empty-after-cleanup queries aren’t logged — a search of only filler words or single characters records nothing
If you’re comparing against an analytics tool that counts every results-page view, expect Fetchie’s number to be lower and more honest.
—
The Digest Didn’t Arrive
Quiet week (zero searches sends no email, by design), toggle off, or plain email delivery. The weekly digest page has the checklist.
—
The Debug Log
When you need to see what actually happened, Fetchie can narrate its work:
- Go to Tracksies > Settings > Debug
- Switch on logging for Fetchie
- Reproduce the problem (rebuild, wait for the daily pass, or save the affected page)
- View the log from the same screen
Fetch failures land there with the reason recorded — what URL failed and why (a timeout, an error code, a non-page response). Rebuild batches, the daily freshness pass, digest sends and skips are all summarised too. Logs are written per-plugin and cleaned up automatically when you switch logging off.
If a rebuild stops with “Indexing failed — check the browser console and try again”, the browser console note is literal: the error that stopped the batch is printed there, and it’s usually a security rule or an exhausted server timeout.
—
Related
- The search index — how indexing is meant to behave
- Insights — what’s counted and what isn’t
- The weekly digest — delivery checklist