Every “Why pages aren’t indexed” reason in Search Console, in plain words: what it means, whether to worry, and the exact fix for the ones that matter.
You open Google Search Console, click Indexing, then Pages, and see a gray bar of “Not indexed” URLs that is bigger than your whole site. Underneath sits a list of reasons with names like Crawled - currently not indexed, Duplicate without user-selected canonical and Soft 404. Some sound alarming. Most are not.
The Page indexing report lists every URL Google knows about on your site, not just the pages you care about. That includes old URLs, redirects, feeds, parameters, attachment pages and spam links pointing at you. Each URL gets one status explaining why it is or is not in the index. This guide decodes every common status, tells you which ones deserve your time, and shows how to fix those. It is for site owners and designers who need to separate real problems from background noise.
For each URL it has discovered, Google records the outcome of its latest attempt to crawl and index it. Discovery comes from links, sitemaps and past crawls. A page can stall at several points: never fetched, fetched but blocked, fetched but rejected, or fetched and folded into another URL as a duplicate. The status tells you where it stopped.
Labels below are written as the report shows them; the interface may display the separator in “Crawled - currently not indexed” as a longer dash, but it is the same status. Google’s help page files two of them under different headings: URL marked ‘noindex’ for Excluded by ‘noindex’ tag, and URL blocked by robots.txt for Blocked by robots.txt.
| Status | Plain meaning | Worry? | Usual fix |
|---|---|---|---|
| Crawled - currently not indexed | Google fetched the page and chose not to index it for now | Yes, if these are important pages | Improve uniqueness and value, strengthen internal links, merge thin pages |
| Discovered - currently not indexed | Google knows the URL but has not fetched it yet | Yes, if numbers are large or growing | Speed up the server, cut low-value URLs, link important pages better |
| Duplicate without user-selected canonical | Google thinks this duplicates another page and you declared no canonical | Sometimes | Add a canonical, redirect, or make the page distinct |
| Alternate page with proper canonical tag | This page points its canonical at another page, and Google agreed | No, usually working as intended | Nothing, unless a page you want indexed is here |
| Excluded by ‘noindex’ tag | Google found a noindex rule and obeyed it | Only if the page should be indexed | Remove the noindex from meta tag, header or plugin setting |
| Blocked by robots.txt | robots.txt disallows crawling this URL | Only if the page should be indexed | Remove or narrow the Disallow rule |
| Soft 404 | The page returns 200 but looks like an error or empty page | Yes | Return a real 404 or 410, or add real content |
| Page with redirect | The URL redirects elsewhere, so the target is indexed instead | No, normally | Only update internal links and sitemaps to the final URL |
| Not found (404) | The URL returns 404 | Only for pages that should exist | Restore the page or 301 it to the closest replacement |
| Server error (5xx) | Your server returned an error when Google asked | Yes | Fix the server problem; check logs and capacity |
| Indexed, though blocked by robots.txt | Indexed from links alone, without Google reading the content | Yes, it is a conflict | Unblock it, then use noindex if you want it out |
| Page indexed without content | Indexed, but Google could not read any content | Yes | Find what is blocking Googlebot from the content |
You may also see Redirect error, Blocked due to unauthorized request (401), Blocked due to access forbidden (403), URL blocked due to other 4xx issue, Blocked by page removal tool and Duplicate, Google chose different canonical than user. Redirect problems are covered in FG-41, 403 responses in FG-49 and canonical disputes in FG-81.
curl runs on your own computer (macOS and Linux have it built in; on Windows use curl.exe in PowerShell or WSL). wp commands run in an SSH terminal in the folder that holds wp-config.php; some hosts call it wp-cli.At the top of the Page indexing report there is a filter that defaults to All known pages. Switch it to All submitted pages or to a specific sitemap. Now the chart only covers URLs you told Google you want indexed. A large “not indexed” number in this view is meaningful. A large number in All known pages often is not.
Every site has excluded URLs. What matters is a reason whose count jumped on a date that lines up with a change you made or a traffic drop. Click a reason, look at its chart, and open the example table.
Click an example URL and choose Inspect URL. The inspection shows the last crawl date, the crawler used, whether crawling and indexing were allowed, and the user-declared and Google-selected canonicals. Then click Test live URL to see what Google gets today. The report can lag behind your fixes; the live test does not.
Before trusting any status, confirm the URL’s current response from your computer:
curl -sI https://example.com/PAGE_PATH/Replace PAGE_PATH with the path of the example URL. -s silences progress output and -I asks for headers only. Good output for a page you want indexed is HTTP/2 200 with no x-robots-tag: noindex line. A 301 or 302 with a location: line means it redirects; 404, 410 or 5xx mean it is missing or failing.
What it means: the page declares a canonical pointing at a different URL, and Google accepted it. Typical members are URLs with tracking parameters, AMP or print versions, and variant URLs. Worry? No, this is the canonical system working. Fix: only act if you find a page you want indexed here. Then check its canonical tag: a theme, plugin or migration may be pointing it at the homepage or the wrong URL.
What it means: the URL redirects, so Google indexes the destination instead. Old URLs, http versions and non-www versions belong here after a migration. Worry? No. Fix: remove redirected URLs from your sitemap and update internal links to point at the final URL, so Google spends less time following hops. If a page you want indexed is here, something is redirecting it; trace it with FG-41.
What it means: the URL returns 404. Worry? Only if it is a page that should exist or one that had traffic or links. Google expects 404s for deleted content and they do not hurt the rest of the site. Fix: for real pages, restore them or add a 301 redirect to the closest equivalent (FG-38 covers redirect maps). For junk URLs you never created, leave them as 404.
What it means: Google crawled the page and found noindex in a robots meta tag or an X-Robots-Tag header. Worry? Not for thank-you pages, cart, account, internal search and tag archives you deliberately hid. Yes if real content is listed. Fix: check Settings, Reading, the per-post and per-type robots settings in your SEO plugin, and response headers. FG-80 walks through each source of a noindex.
What it means: Google found this URL to be a duplicate of another, the page has no canonical of its own, and Google picked the other URL as the main one. Common culprits are ?replytocom= comment links, sorting and filter parameters, http and https copies, and staging copies. Worry? If the listed URLs are variants, not really. If your main page is listed and an odd variant was chosen, yes. Fix: make sure every real page outputs a self-referencing canonical (WordPress core does this on single posts and pages; SEO plugins extend it to archives), redirect true duplicates, and link internally to one consistent version. Inspect the URL to see which page Google chose. FG-81 goes deeper.
What it means: Google fetched the page and decided not to index it, at least for now. There is no technical block; it was a choice. Worry? Yes, if your services, products or articles are here. Not for feeds, paginated archives or thin utility pages. Fix: this is a quality and signals problem, not a switch. Ask whether the page offers something not already covered elsewhere on your site or the web. Merge near-identical pages (location pages that differ only by town name are a classic case), expand thin pages with original detail, link to the page from relevant, already indexed pages, and include it in your sitemap. Then use Request indexing once. Requesting repeatedly does not help.
What it means: Google knows the URL exists but has not crawled it yet. Google’s explanation is that crawling was postponed, often because it expected the site to be overloaded, and the last crawl date is empty. Worry? A few URLs here are normal, especially new ones. Thousands, or a growing pile of important pages, means Google is not spending enough crawling on your site. Fix: improve server response time (see FG-32), stop generating crawlable low-value URLs (faceted filters, calendar pages, endless parameter combinations), and give important pages strong internal links. Check Settings, Crawl stats for slow average response time or host problems.
What it means: a Disallow rule stops Googlebot from fetching the URL. Worry? Not for /wp-admin/, internal search or cart paths you blocked on purpose. Yes if content pages are listed. Fix: edit robots.txt to remove or narrow the rule, then request a recrawl of the file in Settings, robots.txt. Do not use robots.txt to keep pages out of the index; use noindex for that.
What it means: this one appears among indexed pages, flagged as a warning. Google could not crawl the URL, but links pointed to it, so it indexed the bare address. Results often show no description. Worry? Yes, because your signals contradict each other. Fix: decide what you want. To have it indexed properly, remove the Disallow. To keep it out, remove the Disallow and add noindex, because Google has to crawl a page to see its noindex. Once it has dropped out, you can block crawling again if you wish.
What it means: your server answered with a 500-range error, or did not answer in time. Worry? Yes. Persistent server errors can lead Google to drop pages and slow its crawling. Fix: check whether the errors are ongoing or a past incident. Compare dates with your host’s logs and uptime monitoring. If ongoing, the 500, 502/504 and 503 guides (FG-12, FG-13, FG-14) cover the causes. Also check that a firewall is not returning 5xx codes to bots.
What it means: the server said 200 OK, but the page looks like an error, an empty category, a “no products found” page, or a near-blank template. Worry? Yes. You are telling Google the page is real while showing it nothing. Fix: if the page should not exist, make it return 404 or 410. If it should exist, give it substantive content. Out-of-stock product pages and empty archives are frequent sources. Check what status a missing page really returns:
curl -s -o /dev/null -w '%{http_code}\n' https://example.com/THIS-PAGE-DOES-NOT-EXIST/Run this on your computer. THIS-PAGE-DOES-NOT-EXIST is any made-up path. -o /dev/null discards the body (on Windows PowerShell use -o NUL) and -w prints only the status code. Good output is 404. Bad output is 200, which means your theme or a plugin serves error pages as successful responses, or 301, which means a plugin redirects all missing pages to the homepage, another soft 404 pattern.
What it means: the URL is in the index, but Google could not read any content from it. Worry? Yes. Fix: Google has said this usually means the server or CDN is blocking Google from receiving content. Run the URL Inspection live test and view the crawled HTML and screenshot. If they are empty, look at your firewall, bot protection, CDN challenge pages and any rule that serves bots different output. Then test with Googlebot’s user agent:
curl -s -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://example.com/PAGE_PATH/ | head -c 2000Run this on your computer. Replace PAGE_PATH with an affected path. -A sets the user agent and head -c 2000 shows the first 2,000 characters. Good output is your normal HTML with real text. Bad output is empty, a challenge page, or an “access denied” message. Because a request from your computer is not from Google’s IP addresses, IP-based blocks will not show here; for those, rely on the live test and your firewall logs.
After fixing a reason, open it in the report and click Validate fix. Google rechecks the affected URLs over the following days and weeks and emails you progress. Validation can show as Started, then Passed or Failed; a failure lists the URLs still affected. Validating does not make Google index pages it has decided are low value, so do not expect “Crawled - currently not indexed” to clear just because you clicked the button.
On large sites the example table is too long to read. Use Export at the top right of a reason to download the URLs. The CSV option downloads a zip; unzip it and use the table file inside, which lists one URL per row. Then group them by path pattern on your computer:
cut -d, -f1 EXPORT_FILE.csv | tail -n +2 | sed -E 's#https?://[^/]+##' | awk -F/ '{print "/"$2"/"}' | sort | uniq -c | sort -rn | head -20
grep -c '?' EXPORT_FILE.csvRun these on your computer (macOS, Linux or WSL). Replace EXPORT_FILE.csv with that table file’s name. cut takes the first column (the URL), tail -n +2 skips the header row, sed strips the protocol and host, and awk keeps the first folder. The final count shows which section of the site dominates. The second command counts URLs containing query strings. Good output points at one folder or parameter you can deal with in a single rule, for example /tag/ archives or ?orderby=. If the exported URLs are spread evenly across your real content, the problem is site-wide, such as server speed or a template issue, rather than a single pattern.
Then compare that list against your sitemap with wp-cli, which tells you whether Google is ignoring pages you actually submitted:
wp post list --post_type=POST_TYPE --post_status=publish --field=url > published.txt
wc -l published.txtRun these over SSH in the site folder. Replace POST_TYPE with post, page or product. --field=url prints just the permalink of each item. Good output is a line count close to the number of URLs in that sitemap. If your exports from “Crawled - currently not indexed” contain a large share of these published URLs, focus on content quality and internal linking for that post type before anything else.
Most of these statuses are yours to fix. Open a ticket when you see Server error (5xx), Page indexed without content, Blocked due to access forbidden (403) that your own settings do not explain, or a large Discovered - currently not indexed pile alongside slow response times in Crawl stats. Send:
curl -sI output for each, including any CDN request or ray ID.Our diagnostic tools can confirm status codes and response headers for example URLs from outside. If the whole site has dropped out of Google at once, the Emergency Room checklist is the faster place to start.
Did this fix it?
Still stuck? Start again from what you can see in the Emergency Room.
Still stuck?
Print a free one-page checklist to keep, or open the Emergency Room if the symptom does not match.
Get the free checklistsKeep reading
Search the field manual
Or jump straight to a symptom
Press / to search from any page, Esc to close