A Google reconsideration request should be written after the cleanup is complete. It should identify the manual action, name the mechanism that caused the violation, show how the genuinely affected set was found, document what changed and identify the control preventing recurrence.
It is not a plea for lost rankings. It is not an apology polished until the uncomfortable facts disappear. It is not permission to promise that the team will finish investigating later. Google says a good request explains the exact quality issue, describes the corrective steps and documents their outcome. It also requires all genuinely affected pages and every listed manual action to be fixed before review is requested (Search Console Help).
That creates a hard release gate: no complete repair record, no request.
TL;DR
- Reconsideration answers a manual action shown in Search Console, not a traffic drop or a tool warning.
- Build the evidence pack outside the submission box: notice, cause, scope method, change ledger, verification, prevention.
- Google's URL patterns are leads, not verdicts; find the genuinely affected set and prove how you found it.
- Write the request in the same order as the evidence, submit once, and hold while any join is open.
Confirm that reconsideration is the right instrument
A reconsideration request responds to a manual action shown in Search Console. It is not a general response to a traffic drop, an algorithm update, an SEO tool warning or a page disappearing from results. Start with the live Manual Actions report. Preserve the property, action type, notice date, stated scope, example patterns and current status. If the report shows no manual action, diagnose the actual visibility problem instead of drafting a letter Google did not ask for.
This sounds elementary. Under pressure, it is often the first distinction lost. Business growth declines, the board asks what happened, and “submit a reconsideration request” feels like an action with a destination. But the instrument cannot resolve a problem outside its scope. I would block the writing task until the notice exists and the affected mechanism has been identified. Better prose cannot make an incomplete repair reviewable.
Build the recovery pack outside the submission box
Do not begin in Search Console’s text field. Build a compact evidence pack that an unfamiliar person can inspect without relying on the memory of the team that did the work.
| Record | What it establishes | What it cannot pretend |
|---|---|---|
| Notice snapshot | Property, action, date, status and displayed scope | That every URL matching an example pattern is affected |
| Cause statement | Practice, code path or process that created the violation | A cause inferred from timing alone |
| Scope method | How every relevant template, account, placement or publishing route was checked | That one example represents the complete site |
| Change ledger | What changed, where, when, by whom and why | That activity equals successful repair |
| Verification record | How representative repairs and the wider mechanism were tested after release | That one screenshot proves every state |
| Access check | That Google can reach pages that should remain accessible | That hiding a problem resolves it |
| Prevention control | Approval, technical, supplier or moderation change stopping recurrence | A promise without owner or operation |
| Remaining limits | Failed removals, inaccessible records and unresolved facts | That inconvenient unknowns are harmless |
The submission should summarise this pack, not paste it indiscriminately. A spreadsheet with ten thousand lines is not evidence communication if nobody can explain what each population means.
Use the reviewer reconstruction test
My readiness test is simple:
Can an unfamiliar reviewer follow the line from notice to cause, to genuinely affected set, to completed change, to verified state, to prevention control? If any join breaks, hold the request.
This is the same handover standard I use elsewhere in website design and technical marketing work. Evidence should survive the absence of its presenter. If the only person who can explain the repair is the consultant sharing their screen, the record is not finished. The test also reveals cosmetic compliance. A prevention policy may exist, but if it has no owner, trigger or retained execution record, it does not close the final join. A list of changed URLs may exist, but if nobody can show how the population was found, it does not close scope.
Name the violation without laundering responsibility
“We may have experienced quality issues” communicates neither cause nor repair. A useful cause statement identifies the mechanism: a supplier placed paid keyword-rich links without appropriate qualification; an unmoderated user-profile template allowed public spam pages; compromised code returned different content under particular request conditions; a publishing workflow generated large numbers of low-value pages.
Match the wording to the exact action shown in Search Console and the evidence recovered. Google’s spam policies describe practices including link spam, cloaking, hacked content, doorway abuse and scaled content abuse (Google Search Central). Do not import a more dramatic offence from a third-party audit tool.
Do not blame an agency and stop. A supplier may have performed the work, but the site owner still needs to show what happened to the pages, links, permissions or code route and why the mechanism no longer operates. This is a branding decision as much as a technical one. Accountability sounds credible when it is specific. “A former agency did it” is reputation management trying to escape the repair record.
Treat Google’s URL patterns as leads, not verdicts
The Manual Actions report may show page patterns covering part or all of a site. Google says not every page matching a displayed pattern is necessarily affected. Separately, it requires the issue to be fixed on all pages genuinely affected. Those obligations must coexist. Do not label every matching URL guilty by association, and do not inspect only the examples Google supplied. Depending on the action, scope recovery may need to cover:
- every URL generated by an affected template;
- every account able to publish the same user-generated page type;
- every placement controlled by a named commercial arrangement;
- every link acquired through the relevant campaign or supplier;
- every redirect, script or rendering state produced by the same code path;
- every structured component emitted by the same plugin or template;
- every directory, locale or subdomain governed by the workflow.
Record the crawl, database query, code search, account export, file signature or manual-review method used. State the observation date and any boundary the method could not cross. “We checked the website” is not scope evidence. The method should let another person reconstruct why the team believes the affected set is complete.
Let the change ledger carry the repair
Words such as “comprehensive”, “rigorous” and “extensive” should be unnecessary. The ledger should do their work. For every material repair, retain the affected object or pattern, the state before repair, the action taken, the release, removal or contact date, the accountable owner or supplier, the verification method, the observed state afterwards, any exception and its treatment, and the prevention control tied to the same cause.
The object changes with the action. Link-related work may need domain, placement, commercial origin, removal attempt, outcome and any justified disavow decision. User-generated spam may need account, route, content disposition, permission change and moderation evidence. Cloaking may require request conditions, code path, before-and-after rendered behaviour and deployment record. The full ledger can remain in the controlled evidence pack. The request should use representative records and defensible totals only where a denominator exists. Do not convert an estimated count into an exact result because exact numbers sound more serious.
Report outcome rather than effort
Hours worked, emails sent and URLs opened are activity measures. A reconsideration request needs observable outcomes:
Google tells site owners to ensure affected pages are reachable and suggests URL Inspection for access checks. One inspected URL still cannot prove an entire template population is clean. Use representative verification across the affected set and document how the sample was chosen. If removal is the legitimate fix, record the resulting status and why it resolves the violation. Do not block an unresolved page in robots.txt and describe the now-hidden problem as repaired.
Performance marketing language is especially dangerous here. “Recovered visibility” may matter later, but it is not proof that the violating mechanism was removed. The first success condition is a defensible repaired state.
Facing a manual action and unsure whether the repair record would survive a stranger reading it? We build the evidence pack and tell you honestly whether it is READY or HOLD.
Prevention requires an owner, trigger and record
“We will be more careful” is not a control. A prevention control might mean paid placements require disclosure and approval before release; suppliers cannot launch link activity without a retained placement register; public profile creation is restricted, rate-limited or moderated; a vulnerable WordPress plugin was removed or patched and assigned an update owner; structured-data changes require agreement with visible content; third-party publishing access has an owner and expiry review; the offending generator was disabled or redesigned; or staff use a current acceptance check for the affected workflow.
Every control should answer three questions: who owns it, when does it run, and what record proves it ran? It must also address the cause in the request. A new content-quality guide does not stop a compromised account. Staff training does not disable a code path. A supplier clause does not remove existing links. AI readiness and ordinary operational readiness meet here. Automation can support monitoring, but no AI marketing system should be allowed to generate or release pages at scale without the controls needed to stop, inspect and reverse it.
Write in the same order as the evidence
Once the repair is complete, the request can be concise:
- Property and action
Identify the property, manual-action type, notice date and displayed scope.
- Cause
State the exact practice, mechanism or failure.
- Scope method
Explain how genuinely affected items were found and the same mechanism checked elsewhere.
- Completed repair
Summarise actions and observed outcomes using supported totals or examples.
- Exceptions
Disclose material items outside direct control and their treatment.
- Prevention
Name the new control, owner and trigger.
- Verification
State how the repaired state and Google access were checked.
Do not add a hardship paragraph about lost revenue as a substitute. Do not call the issue accidental unless the record establishes intent. Do not claim the site has always followed policy when the submission exists because it did not. A plain admission attached to a completed repair is stronger than a persuasive apology that avoids the mechanism. This is not sales copy. It is a technical handover.
Hold when one evidential join remains open
Use HOLD when:
Waiting at this gate is not weakness. It stops the request getting ahead of the site. The cost is real: business growth may remain constrained while the evidence is completed. I accept that cost. Submitting early to create the appearance of action can delay clarity and leave the underlying mechanism available to repeat.
Do not use the review queue as a refresh button
After submission, freeze the exact site state, evidence version and request text. Google says reviews may take several days or weeks, with some link-related cases taking longer, and tells owners not to resubmit before receiving a final decision. Continue essential monitoring around the original mechanism. Avoid unrelated high-risk releases that make the submitted state difficult to reconstruct.
If the request is rejected, do not merely soften the language and resubmit. Reopen the joins: cause, scope, repair, verification and prevention. The website is under review, not the quality of the apology. If the action is revoked, record exactly that. Revocation does not promise former rankings, traffic, customer acquisition or a timetable. Normal crawling, indexing and ranking continue, and the cleanup may have removed pages or links that once contributed to visibility.
The request is a cover note, not a closing argument
Mark the request READY only when an unfamiliar reviewer can reconstruct the complete line from notice to prevention. Freeze the evidence version, write the summary in that same order, submit once and retain the text and timestamp. Otherwise mark it HOLD. Name the missing record, unresolved item or unowned control. Return to the site and change the underlying state before changing the explanation.
There is no clever phrase that can compensate for an unfinished repair. Google does not need the most sympathetic version of the story. It needs a site whose fix the record can already defend.
Good to know
FAQs
Only after the cleanup is complete across every genuinely affected page and every listed manual action. Google requires the issue to be fixed before review is requested. If any evidential join is still open, hold.
No. Reconsideration responds to a manual action shown in the Search Console Manual Actions report. If no manual action is listed, diagnose the actual visibility problem instead of writing a letter Google did not ask for.
Google says not every page matching a displayed pattern is necessarily affected, but it requires the issue to be fixed on all genuinely affected pages. Treat the patterns as leads, find the complete affected set by template, account, supplier or code path, and record how you found it.
In order: property and action, cause, scope method, completed repair with observed outcomes, exceptions outside direct control, the prevention control with owner and trigger, and how the repaired state and Google access were verified. No hardship paragraph, no blame, no promises.
Revocation resolves the manual-action status only. It does not promise former rankings or traffic. Normal crawling, indexing and ranking continue, and the cleanup may have removed pages or links that once contributed to visibility.
Next step
Is your repair record ready for a stranger to read?
We assemble the evidence pack, test every join from notice to prevention and write the request in the same order as the evidence, once.