Google Search Console sends an email with the subject “New reason preventing your pages from being indexed”. It means Search Console has found pages on your site that are not indexed, for a reason it is now reporting as new.
Indexed means Google has stored the page and can show it in search results. A page that is not indexed cannot appear at all. That sounds alarming, and the email is written to sound like a warning.
Here is what one of those reasons often looks like once you open it.
Reason: Page with redirect
https://example.com/pricing-2024/ 301 to /pricing/
https://www.example.com/about/ 301 to https://example.com/about/
https://example.com/blog/?p=118 301 to /blog/how-we-price/Three URLs, all redirecting on purpose. Google is right that none of them is indexed, and nothing is wrong. The email reports what is new. It does not judge what is bad.
- It names a reason, not a verdict. Search Console found pages it is not indexing for a reason it now reports as new. It is not a penalty.
- Most reasons it names are deliberate. Redirects, alternate pages with a canonical, deleted pages and noindex pages belong out of Google.
- One question decides it. Is any example URL a page you want people to find? If none is, there is nothing to fix.
- Inspect the ones that matter, not all of them. URL Inspection shows the coverage state, last crawl and Google’s canonical for one page at a time. ContextBolt SEO, an SEO toolkit inside the AI agent you already use, runs those inspections over a pasted list for free.
- Validate only what you fixed. Google says validation typically takes up to about two weeks.
Where you are seeing this
If you landed here from the email, this is the screen behind it.
- Open the email and click its button to the indexing report, or open Google Search Console and pick your property.
- In the left sidebar, under Indexing, click Pages.
- Scroll to the table headed “Why pages aren’t indexed”.
- Find the row the email named and click it to see example URLs and a First detected date.
The subject line has more than one wording. With several reasons at once it turns plural, “New reasons preventing your pages from being indexed”, and the body lists each one. Another version reads “New reasons prevent pages in a sitemap from being indexed”. If yours mentions a sitemap, set the report’s filter at the top to All submitted pages, so you only see URLs your sitemap asked Google to index.
What the email actually says
The body is short. It says Search Console found pages that are not being indexed because of a new reason, names the reason, and recommends fixing it if it is not intentional.
That last word is the whole email. Google cannot tell a redirect you planned from one you forgot. Only you can.
Notice what the email leaves out. It does not say how many pages, it does not list the URLs, and it does not say whether any of them earned traffic. You get all three from the report, and the third you have to pull yourself.
The labels can differ from Google’s help page. The email and the report use labels like “Excluded by ‘noindex’ tag” and “Alternative page with proper canonical tag”. Google’s Page indexing report documentation heads the same reasons “URL marked ‘noindex’” and “Alternate page with proper canonical tag”. If a search for the email’s wording finds nothing official, search the help page’s wording instead.
Why “new” does not mean new to you
Google does not publish exactly what sends this email. It does publish what the report counts as new, and it explains a common complaint.
The same documentation says an issue’s First detected date is the first time it was seen during that issue’s lifetime. If an issue comes back more than 90 days after its last instance was fixed, the old issue is closed and the report records a new one, with a new First detected date.
So a reason you cleared in the spring can be new again in the fall. Delete a page, add a redirect or leak a staging URL into a sitemap, and an old reason can come back.
Most of the time the email names something boring. It is reporting the arrival of a reason, not a change in the health of your site.
The Source column tells you who acts
Every row in the table has a Source value, either Website or Google systems. Google’s documentation is blunt about it. In general, you can fix only issues where the source is listed as Website.
Website: something on your side made the call. A redirect, a noindex rule, a canonical tag, a 404, a server that answered with an error. You can change these, and on most sites you chose them.
Google systems: Google made the call. It crawled the page and passed, it has not crawled it yet, or it picked a different URL as the main version. You cannot switch these off. You can make the page a better candidate, give Google the server capacity and links it needs to crawl it, or decide it does not need to be indexed.
Read the Source before you read anything else. It tells you whether the next hour is spent in your CMS or in your content.
Sort the reason into one of three piles
This is the useful part. Every reason the email can name lands in one of three piles, and the pile decides what you do.
Pile one: usually on purpose, confirm and leave
Page with redirect means the URL redirects somewhere else. The redirecting URL is not indexed, and the page it points to can be.
Alternate page with proper canonical tag means the page points at its main version, and the main version is indexed. Google’s own description says there is nothing you need to do.
Excluded by ‘noindex’ tag means your site told Google to stay out. Staging pages, thank-you pages and tag archives belong there. Excluded by noindex tag covers how to find the one that should not be.
Not found (404) is fine for a page you deleted with no replacement. If the page moved, it needs a 301 to its new address instead.
Blocked due to unauthorized request (401) is usually a login page or a staging site doing its job. The fix is often in your sitemap, as the 401 post explains, not on the server.
Pile two: Google’s call, improve the page or let it go
Crawled, currently not indexed means Google read the page and declined it. Discovered, currently not indexed means Google knows the URL and has not crawled it yet. Neither is fixed by asking again. For Discovered, Google’s one documented cause is your server, so check Crawl stats first, as Discovered, currently not indexed explains. Crawled, currently not indexed covers how to tell a page worth improving from one that should stay out.
Duplicate without user-selected canonical means Google found copies, nobody declared a main version, and Google picked one. Duplicate, Google chose different canonical than user means you declared one and Google overruled you. In both, the question that matters is whether Google picked the right URL. The first duplicate post and the second show how to compare the two canonicals.
Pile three: usually a fault, act this week
Server error (5xx) means your server failed when Googlebot asked. Redirect error means a loop, a chain that is too long, or a redirect to a bad URL. Soft 404 means a page that says “not found” while returning a success code.
Blocked due to access forbidden (403) is often a firewall or bot filter refusing Googlebot while the page loads fine for you. The 403 post walks through finding the rule. URL blocked due to other 4xx issue needs the real status code read before you know what it is, which the 4xx post covers.
URL blocked by robots.txt joins this pile when it catches a page you want indexed. A deploy that ships a staging robots.txt to production does exactly that.
For a quick outside look at any URL in this pile, our free Google index checker fetches the page and shows whether Google can index it, which Search Console status the problem causes, and the fix.
Is this email an emergency?
Almost never, and here is my one strong view on it. Most sites should ignore most of these emails. Not because indexing does not matter, but because the email has no idea what you meant, and a site with redirects, deleted pages and a staging environment will keep triggering it.
Three things change that.
A page that earned clicks is in the example URLs. Before you do anything else, check which of the example URLs had traffic before the email. A page that earned clicks and is now out of the index is the real problem, whatever the reason says.
The reason is in pile three and covers a template. One 5xx is a blip. Two hundred product pages returning 5xx is an outage Google noticed before you did.
A noindex or robots.txt block hit pages you want. WordPress has a setting under Settings, Reading, labeled “Discourage search engines from indexing this site”. Ticked on a staging copy and carried to production, it asks search engines not to index any page on the site.
If none of the three applies, write down the reason and the date, and close the tab.
Doing the sort with ContextBolt SEO
ContextBolt SEO is ours, so weigh the bias. It is an SEO toolkit that runs inside the AI agent you already work in, such as Claude or Cursor, with a read-only Search Console connection.
Google does not expose the Page Indexing report through its API, only URL Inspection, one URL at a time. So you copy the example URLs out of the row and paste them in, and the agent handles the rest.
From there, the agent does the slow part. Our inspect_url tool returns, for each URL, the coverage state, the last crawl date, whether robots.txt allowed the fetch, whether indexing is allowed, and Google’s canonical next to yours when they differ. Then one performance call pulls your clicks by page to match against them. The Search Console tools are free and never spend your credits.
Copy this prompt
Search Console emailed me about a new reason my pages are not
being indexed. I'm pasting the example URLs from that row.
Run inspect_url on each one and give me its coverage state,
last crawl date, and whether Google's canonical matches mine.
Then pull my Search Console clicks by page for the last 90
days in one call, and match them to these URLs. List the URLs
that earned clicks first, and tell me which pile each one is
in: on purpose, Google's call, or a fault to fix this week.Here is one result as the tool returns it, from a real run on a retired URL of our own, trimmed of the property line.
URL inspection for https://contextbolt.com/blog/seo-mcp-server/
- Status: Excluded or not indexed (NEUTRAL)
- Coverage: Page with redirect
- Last crawled: 10/9/2026
- robots.txt: ALLOWED
- Indexing allowed: INDEXING_ALLOWED
- Google's canonical: https://contextbolt.com/seo/mcp/That is pile one, read in a glance. The old post redirects on purpose, Google crawled it on October 9, 2026, and it treats the page the redirect points to as the main version. Nothing to fix.
The prompt costs nothing, and every result saves to your SEO Dashboard, so when you come back after a fix the before is already there. If the agent has your site’s code open, it can then prepare the change, such as removing a stray noindex from a template, for you to review.
Plan on about a hundred URLs a sitting, because our server allows 120 tool calls an hour and the Search Console API limits allow 2,000 inspections per site per day. Search Console’s email is still how you hear about a new reason. The agent is how you get through the list in an afternoon instead of thirty tabs.
If inspections are all you need, a free Search Console MCP you set up in Google Cloud can run them too, and ContextBolt SEO vs the Google Search Console MCP lays out what each one covers.
Start with the 7-day free trial, and after that it is $35 a month. The agent earns its keep when a new reason names hundreds of URLs and you need the five that matter, sorted by the clicks they earned.
Should you click Validate Fix?
Only on a reason you fixed. The button asks Google to recheck the affected URLs, and the documentation says validation typically takes up to about two weeks, sometimes much longer. You get emails as it proceeds. Do not click it again until it has passed or failed.
On a pile one reason, there is nothing to validate. The redirect will still be a redirect next week, and Google will report it the same way.
For a single page that you fixed, URL Inspection lets you test the live URL and request indexing. Save it for pages where the cause really changed. For a page Google read and declined, Google’s documentation says there is no need to resubmit.
What this email does not cover
It does not cover speed. A slow page sits in the Core Web Vitals report, and a row like LCP issue: longer than 2.5s (mobile) does not stop a page from being indexed.
It does not cover rankings. An indexed page can rank on page nine. This email only tells you about pages that cannot rank at all.
And it does not cover pages Google has never heard of. A page with no links and no sitemap entry is not in the report, so it never triggers the email. If an important page is missing from both, the fix is a link to it, not a reply to Google.
What I would actually do
Open the row the email named. Read the Source. Read the example URLs and ask the one question. Is any of these a page I want people to find?
If none is, close it. That is most of the time, and it is the correct response, not a lazy one.
If one is, inspect it, check whether it earned clicks, and fix the cause where it lives, whether that is a template, a server rule or a sitemap. Then validate, and leave the report alone for two weeks.
The thing to resist is treating every one of these emails as a fire. It arrives because a reason is new to the report, not because it is bad. Your job is to notice the rare one that landed on a page that pays for itself.
