The most useful thing to understand about a reconsideration request is that it is not a letter. It is a claim, and somebody is going to check it.
Teams spend days on the wording. They rewrite paragraphs, soften phrases, add context. Then a reviewer opens the site, looks at the pages, sees the same pattern still sitting there, and denies it in a minute. The prose was never the variable.
That is the frame worth holding: you are not persuading anyone. You are reporting completed work, and it either happened or it did not.
The five reasons requests come back
Submitted before the fix was live. By a distance the most common. The team decides on a plan, writes the request describing the plan, and submits while the work is still in progress. A reviewer arrives, finds the pattern intact, and has nothing to approve.
Only the named URLs were fixed. Google lists examples, not the full set. If four location pages were named and they came off a template, the action applies to every page built from that template. Fixing the four and submitting is the second most common denial, and it is the one that costs the most time because teams repeat it.
Rewritten so lightly it is recognisably the same. New vocabulary, identical substance. The pages read better and say exactly what they said before. A reviewer opens two of them and sees one document with different place names, which is the finding that started this.
Pages removed without proper redirects. Deleting the problem is fast and looks like action. What a reviewer then sees is a wall of errors where content used to be, which reads as a site falling apart rather than a site being repaired.
Written defensively. Explaining why the practice seemed reasonable at the time, describing how much revenue is being lost, or emphasising that a former agency did it. All of it reads as somebody who has not yet accepted what went wrong.
Why a denial is expensive
There is no formal penalty for a rejected request, and that leads teams to treat submissions as free. They are not.
Your first submission arrives with no history. It gets read at face value.
Your second arrives with one denial behind it, so the claims need to be visible on the site rather than taken on trust. Your third establishes a pattern of appealing prematurely, and attention drops accordingly.
By the fourth, the reviewer opens the case expecting to find the same problem again, because three times out of three that is what they found. Nothing about that is unfair. It is what any of us would do.
The recovery I get asked about most had four rejected appeals before it reached me.
Nothing in the wording was wrong. The team had fixed the eleven URLs Google listed and left the other two hundred and thirty pages matching the same pattern untouched, then argued the point four times. Finding the full set before writing anything is the part of recovery that decides the outcome.
By the fifth submission we were not just fixing a site. We were fixing a site and a record, and the second one is slower.
What a request that works actually contains
Four paragraphs. Sometimes five. Anything longer is usually explanation, and explanation is what gets requests denied.
1. Name what was wrong, plainly. “Our location pages were produced from a single template across 241 stores, with only the city name varying.” No hedging, no “may have been perceived as”. The reviewer already knows what the problem was; watching you avoid saying it is not reassuring.
2. State what you changed, with counts and dates. “241 pages were rebuilt from store-level information gathered between 3 February and 14 March. 38 pages were consolidated into 12 with 301 redirects. 6 pages were removed and return 410.” Numbers and dates are checkable, which is what makes them worth including.
3. Explain how you found the full set. This is the paragraph most people skip and it does more work than any other. “Google’s notice named 11 URLs. We identified the shared template and queried our crawl for every page built from it, which returned 241.” It answers the reviewer’s real question, which is whether you understood the scope or just addressed the symptoms.
4. Say what prevents a repeat. A process change, not an intention. “Location pages now require a completed store information sheet before drafting, and no page ships until it passes a similarity check against the existing set.” “We will be more careful” is not a control.
What to leave out, and why each one hurts
Why it seemed reasonable at the time. Every explanation of context reads as partial disagreement with the finding. You can hold the view privately. It does not belong in the request.
What the outage is costing the business. It is genuinely painful and it is not a factor in the decision. Including it signals that you want sympathy rather than a review.
How long you have been waiting. Same problem, and it also suggests you may submit again out of impatience.
Blame aimed at a former supplier. State it once as fact if it is relevant, then take responsibility for not auditing the work. The site owns those links or those pages regardless of whose hands built them.
Anything you cannot show on the site. If you claim it, a reviewer can check it. A single unverifiable claim casts doubt across everything else in the request.
Do not submit a second request while the first is under review.
It does not accelerate anything. It puts two cases in the queue for the same site, and it tells the reviewer you are working from anxiety rather than from a completed plan.
The link cases need one extra thing
If the action is for unnatural links, the outreach log is often the most persuasive item you have, and it is regularly missing.
Google expects genuine removal attempts before a disavow. A submission consisting of a disavow file and nothing else reads exactly as the shortcut it is.
Build the log as you go, not afterwards. A spreadsheet with the domain, the date you contacted them, the method, and the outcome including “no response”. The entries that never replied are as valuable as the successful removals, because together they demonstrate effort at scale.
Then disavow at domain level what would not come down, and say in the request how many you contacted, how many were removed, and how many were disavowed. Three numbers that a reviewer can weigh.
Find out whether you are ready to submit
The reconsideration request builder covers nine manual action types and asks the questions a reviewer will effectively be asking. If your answers show the fixes are not live, or that only the named pages were touched, it stops rather than handing you a request that will fail.
Open the reconsideration request builder
Timing, honestly
Nobody outside Google can tell you how long the review takes, and anyone quoting a number is guessing. What I can tell you is the shape of it.
On a mid-sized chain, remediation typically runs four to eight weeks before anything is submitted at all. That figure surprises people, and it is the single most useful expectation to set early, because the alternative is a team that submits at week two and then spends four months recovering from the denial rather than from the action.
If your request is denied, the correct response is not to rewrite it. Read the reply, find what the reviewer still sees, fix that, and only then submit again. A denial is information about your site, not about your prose.
The uncomfortable question worth asking
Before you submit, ask one thing: would I be comfortable walking a Google reviewer through how these pages were produced?
Not through the finished pages, through the process. Who gathered the information, what they started from, how the set was checked.
If the honest answer is no, the work is not finished, whatever the pages look like. That discomfort is the same signal the reviewer is going to act on, and you have the advantage of noticing it first.
If you take one thing away
A reviewer checks your site, not your letter. Finish the work, then report it in four paragraphs with counts and dates.