Reconsideration Request Rejected? Why Google Says No, and What to Fix Before You Try Again
A rejected reconsideration request almost never means Google wanted a longer letter. It means a reviewer read your request, opened your site, and still found the problem the manual action names. The fix is not better wording. It is finding the pages the reviewer found, and you can usually do that yourself with Search Console and your sitemap. This page gives the six reasons requests get rejected, how to check each one, and what a request that can be approved contains.
Why was my reconsideration request rejected? Because pages that still break the policy named in the manual action are live on your site. Usually the cleanup covered the pages the team was looking at but not the ones that earned the traffic, the showcase pages were fixed but the rest of the same type were not, or pages were dropped from the sitemap while staying live and indexable.
Before filing again, list every remaining URL by page type, check a random sample of each type the way a reviewer would, and make sure every number in your request matches what is live on the day you file.
What a reviewer does with your request
A manual action is a person’s judgement, not an algorithm’s. When you file a reconsideration request, someone at Google reads it and then looks at your site. Google’s own guidance says a good request does three things: it explains the exact quality issue, describes the steps you took to fix it, and documents the outcome. It also asks you to fix the issue on all affected pages, not some of them.
The practical consequence: assume the reviewer will open pages you did not mention. The examples in your request are where they start, not where they stop. If ten rebuilt pages sit next to three hundred untouched ones of the same type, the untouched ones decide the outcome.
Each rejection also costs you a review cycle, which Google says can take days or weeks, and it costs credibility. A second request that has to admit the first one overstated the cleanup is read more sceptically than the first. So the goal is to file once more, and only when the site would pass a fresh look.
Six reasons requests get rejected
Each one below comes with the check that shows whether it applies to your site.
Teams clean what they think of as the problem: old blog posts, a few weak landing pages. But the pages most likely to have drawn the reviewer’s attention are the ones that brought the most search traffic before the action. Those are often free tools, location pages, tag archives or translated copies that nobody on the team thinks of as “content”.
How to check: In Search Console, open Performance > Pages for the three months before the manual action date and sort by clicks. Every page in the top 50, and every page type it belongs to, needs a decision: keep, rebuild or remove. If your request does not mention the types at the top of that list, it has a gap a reviewer can see.
A request that showcases two excellent rebuilt pages reads well. But if they are two of three hundred pages built from the same template, and the other 298 are unchanged, the reviewer only needs to open a few of those to see the original pattern.
How to check: Group your sitemap URLs by template or folder. Open ten at random from each group, not the ten you are proudest of. If any of them would not be worth reading on its own, the whole group is not done. Either bring every page up to the standard or remove the ones you cannot.
Removing a URL from the sitemap does not remove the page. It still loads, Google can still index it, and internal links may still point to it. A request that says “the sitemap now contains only active pages” is true and beside the point if the old pages are still live.
How to check: Take a list of removed URLs and request each one. They should return 404 or 410, or carry a noindex tag. Then search your own templates and navigation for links to them, and use URL Inspection on a handful to see what Googlebot gets.
A thin page in five languages is five thin pages. The same goes for country versions, filtered copies and near-identical pages that differ by one word. Teams often clean the main language and forget that the language versions are separate URLs a reviewer can open.
How to check: For every page type you removed or rebuilt in your main language, check its language folders and hreflang alternates. If the English version is gone and the Spanish one is live, the cleanup is half done.
A migration, a translation plugin, a theme or a former agency may genuinely explain how the pages came to exist. But the manual action is about what is on the site, not how it got there. A request that leads with the cause, while pages of the same kind are still live, reads as an explanation instead of a fix.
How to check: Read your first paragraph. Does it name the pages and why they gave readers little value? Or does it describe a technical event? Lead with the first. The cause can follow in one sentence.
“All thin pages removed” next to a sitemap that still lists pages of the same kind, or “fully addressed” in one request followed by a later request admitting the cleanup was incomplete. A reviewer who catches one number that does not match the site has no reason to trust the others.
How to check: Write your counts by page type: how many existed, how many were removed, rebuilt or noindexed, how many remain. Then check them against the live sitemap and the Pages report on the day you file. Never say “all” or “fully” unless you have checked all.
What to do after a rejection
- Read the rejection message carefully. It sometimes includes example URLs. Those are the most direct evidence you will get of what the reviewer looked at. Check whether each one is still live, and what kind of page it is.
- Do not file again straight away. A quick resubmission with the same site behind it is very likely to get the same answer.
- Build the inventory. Every URL in your sitemap and every URL in the Pages report, grouped by page type and language. This is the work most teams skip, and it is where the missed pages turn up.
- Make a decision for every group: keep as it is, rebuild to a clear standard, or remove (404, 410 or noindex). Write down the reason for each.
- Check the live site, not your spreadsheet. Sample each group at random and inspect a few URLs as Googlebot. Cached pages, stale sitemaps and forgotten language versions show up here.
- Only then write the request.
What an approvable request contains
Shorter and more specific beats longer and more apologetic. Write it for a busy reviewer who will check what you say.
- The issue in Google’s terms. Name the manual action, then say plainly which kinds of pages fell short and why. “Our 400 city pages repeated the same 200 words with the city name swapped in” is better than “some content was not up to our standards”.
- An inventory by page type. Before, removed, rebuilt, remaining. Numbers that match the live sitemap on the day you file.
- What you did to each type. Removed (with the status code), rebuilt (and to what standard), or kept (and why it already adds value).
- Examples from every type, including ordinary pages. Not only the best ones. A reviewer who sees you chose typical pages trusts the rest of the request more.
- What changed in how you publish. The checks that stop the same pages being created again.
- No claims you have not verified. If something is still in progress, say so and say when it will be done, or wait and file when it is.
After the action is lifted
Approval removes the manual action. It does not hand back the traffic on its own. While the action was in place, Google’s regular quality systems kept evaluating the site, and pages often drop out of the index as “Crawled, currently not indexed” for reasons that have nothing to do with the action. Expect a recovery that builds over weeks as pages are recrawled, and keep the standard you set for the request. Our guides to crawled, currently not indexed and how long recovery takes cover what comes next.
The checklist
- ☐ Rejection message read for example URLs, and each one checked
- ☐ Top 50 pages by clicks before the action date listed, with their page types
- ☐ Every sitemap and indexed URL grouped by page type and language
- ☐ A keep, rebuild or remove decision, with a reason, for every group
- ☐ Ten random pages per group opened and judged on their own
- ☐ Removed URLs return 404 or 410, or carry noindex, and nothing links to them
- ☐ Language versions and variants handled the same way as the main pages
- ☐ Request leads with the pages and the problem, not the cause
- ☐ Every number in the request matches the live site on the day of filing
- ☐ Examples include ordinary pages from every type, not only the best
That is the point to get an outside view before the next filing. We go through the remaining site the way a reviewer would, give you a keep, rebuild or remove decision for every page type, and write the request. Fixed price, in writing, no calls needed. Details are on the manual action recovery page.