Limitations and counterexamples
Test the case that could make the advice wrong.
A limitation explains where advice stops working. A counterexample tests an overbroad rule with a plausible case that fails. Both help readers choose the right action under their own conditions.
Write the claim precisely before testing it.
Record the recommendation, intended reader, task, prerequisites and outcome. “Add deeper coverage to improve the page” hides different possible jobs: teaching a new subject, resolving one error, finding a contact number or confirming eligibility. State which job the advice is meant to serve before looking for exceptions.
Keep the claim separate from its reason. “Readers need a version-specific recovery step” is a task diagnosis; “the page is too short” is a different hypothesis. More length cannot prove the first. Identify the page passage, source, date, version and owner so a later repair can be traced to the real statement.
Find plausible exceptions and explain why they fail.
Choose a case close enough to the intended audience that it could be mistaken for a valid use. Vary a meaningful condition: version, access rights, urgency, available evidence, reader knowledge, location or desired outcome. Explain the missing condition rather than dismissing the case as unusual.
An exception may narrow a recommendation while leaving its central usefulness intact. A genuine counterexample to an absolute claim requires revising or rejecting that absolute claim. A fanciful scenario with no plausible reader relevance is weak evidence for changing a practical rule. Do not assume that listing one counterexample proves how common it is.
Separate uncertainty from an alternative explanation.
Uncertainty means the available evidence does not settle a question. An alternative interpretation explains the same observation differently. For example, a visitor leaving after reading one line could have found the answer or abandoned the page; the exit alone does not establish either interpretation. Do not turn an ambiguous metric into a confident story.
Write what is observed, what is inferred and what evidence would distinguish the explanations. If the source conflicts with another source, compare date, scope, subject and method first. Hold a strong claim when the unresolved difference would change the recommendation. A hypothetical mechanism can explanation further checks but cannot be reported as an observed outcome.
Worked example: deeper coverage misses the real task.
Imagine a fictional product-support page titled “Recover an account”. The visitor already understands account security and needs the approved recovery route for an account with a lost second factor. The draft opens with a long history of authentication, then discusses every login method. It never tells that visitor which official recovery process applies.
The proposed rule is “add more topic coverage to make support content useful”. The near-miss is this reader: additional authentication background expands the subject but still cannot resolve the missing recovery decision. The failure is task fit, not insufficient background. Do not invent recovery instructions; the real product’s current official policy must supply them.
| Audit field | Populated teaching record |
|---|---|
| Claim | More authentication coverage will solve the support-page problem |
| Plausible exception | Returning account holder who lost the second factor and needs the authorized recovery route |
| Missing condition | Exact product/version and official account-recovery eligibility |
| Alternative interpretation | The problem may be a missing route, poor placement or unavailable evidence rather than insufficient depth |
| Revision | Put the verified recovery route and eligibility boundary first; retain only background needed to understand it |
| Evidence needed | Current official recovery policy and a task test using the applicable account state |
| Owner and next review | Support editor; recheck on policy or recovery-flow changes |
Repair the answer without losing necessary context.
A qualified replacement is: “Add depth when it supplies information needed for the reader’s task. For a narrow recovery question, first give the current official route, eligibility limits and next action; place broader background afterward when it helps.” This replaces a universal length rule with a condition a reader can inspect.
Before applying it, confirm that the destination exists and actually handles the stated account condition. If eligibility is unknown, say which input is missing and send the reader to an authorized help route. Do not promise that access will be restored, prescribe bypasses or imply that a longer article proves service quality. The example changes the content decision; no performance outcome is claimed.
State the risk beside the decision it affects.
Ask what happens if someone applies the advice outside its scope. Risks may include wasted time, wrong purchases, privacy exposure or a consequential factual error. The seriousness determines how strong the evidence and review must be. A minor editorial preference and an account-security instruction should not receive the same treatment.
Place the relevant qualifier close to the recommendation. A general footer disclaimer is easy to miss and cannot repair a misleading opening. Name the condition and its consequence in ordinary language: “This route applies only to organization-managed accounts; personal accounts use a different support process.” Use that wording only when the real source supports the distinction.
Keep a useful record of the test and its result.
Store the original claim, test case, failure reason, evidence, revised wording, unresolved uncertainty and accountable editor. Mark the record as retained, narrowed, rejected or held. Preserve a historical version when it explains why the advice changed; update every reused summary that carries the overbroad rule.
Review definitions, examples, comparison tables and link labels together. A qualified body paragraph does not help if the headline still promises a universal result. Do not build another page for every exception when a short qualification or contextual link resolves it within the existing owner.
Know what a counterexample cannot establish.
Counterexamples expose scope failures; they do not by themselves measure frequency, prove causation or choose the best option for every audience. Seek representative evidence when prevalence matters and specialist review when consequences require it. Keep both the supporting case and the strongest relevant contrary case visible.
Google’s people-focused guidance asks if readers can achieve their goal. This audit translates that concern into an editorial test, not a Google ranking formula. Accept the revised advice only when its conditions, evidence and practical next route match the reader’s real question.
Sources and related learning
Google content quality documentation.
Teaching scenarios are labelled in the article. The dated Google feature change is a real documented event; no search or client performance is claimed.
Continue with semantic SEO learning and evidence and useful contribution. Explain evidence and authorship. Maintain the corrected claim.