Content audits and rewrites
Choose the repair from the observed problem.
A rewrite should preserve accurate information and fix a documented defect. Keep the source version, explain each change and compare the final answer with the evidence before release.
Free learning from Semantec SEO.
Diagnose the problem before choosing a rewrite.
A content audit should identify an observed defect and the reader task it affects. Examples include a claim with no source, a missing prerequisite, contradictory answers, an outdated condition or a page that repeats another answer without serving a distinct need. “The copy feels old” is a prompt for inspection, not a sufficient reason to replace everything.
Keep the evidence separate from the proposed repair. A screenshot can show a crowded heading at one size; it does not prove the underlying explanation is wrong. A source comparison can reveal an unsupported number; it does not establish that the whole page should be deleted. Match each decision to what was observed.
Write an issue record containing the passage, defect, evidence, consequence for the reader and proposed action. Prioritize defects that change the answer before polishing style. If the page’s job itself is unclear, resolve its ownership and scope before producing a more fluent version of the same confusion.
Freeze the source version and define the allowed scope.
Save the complete original content and the relevant media, tables, tools, links and metadata before editing. Record the URL, date and version or file hash. Inspect material that appears through a template as well as the editable body, because a rewrite can accidentally remove useful information that is not stored in the expected field.
Define what the rewrite can change. A bounded repair might correct one factual statement and restore its qualification. A broader repair may reorganize the explanation while preserving the task, evidence and useful examples. A change of audience, service scope, page owner or URL needs its own explicit decision rather than being hidden in a copy edit.
Create a protected-information list: verified facts, exact names, conditions, source references, meaningful original media and necessary next routes. Protected does not mean permanently immune to correction. It means the editor must record the evidence and reason before removing or altering something another reader may rely on.
Choose keep, remove, rewrite or hold for evidence.
Choose repair depth separately from the action on each passage. A refresh updates limited information while keeping the page’s job and structure. A focused rewrite repairs a bounded answer; a full rewrite rebuilds the explanation for the accepted task. A merge moves useful material into another answer owner. A redirect changes the route after an ownership decision and needs its own technical checks. A new brief is appropriate when the current page cannot support the required task. These choices must keep their reasons and protected information.
Keep a passage when it answers a relevant question accurately and clearly. A new vocabulary preference is not a reason to discard a useful explanation. Remove text that serves no accepted task, repeats an answer without adding a needed condition or makes a claim the page should not be making.
Rewrite when the answer is supported but its structure, wording or placement prevents understanding. Hold a statement when the necessary source is absent or conflicting. A more cautious sentence can sometimes preserve the useful part of an answer, but it must not imply that missing evidence has been verified.
| Observation | Decision | Evidence or acceptance needed |
|---|---|---|
| Accurate explanation with a relevant worked example | Keep, with any bounded language repair. | Compare against the source and the current reader task. |
| Same paragraph repeated under three headings | Combine or remove the redundant copies. | Confirm that distinct conditions are not lost. |
| A claim about results with no supporting record | Remove or hold the claim. | Obtain the real record before making a result statement. |
| Correct prerequisite appears after the action it limits | Rewrite the reading order. | Reader encounters the condition before the dependent action. |
| Conflicting versions of a product limit | Hold the affected answer. | Responsible owner resolves the applicable version and source. |
Preserve evidence integrity through the edit.
Retain the relation between a claim and its source. A study about a different population, product version or task cannot support a broader claim just because the subject sounds similar. Keep quotation boundaries, dates, units and uncertainty attached to the information they qualify.
When you condense a passage, check for changes in modality: “can” becoming “will,” “in this sample” disappearing, or an observed association becoming a cause. When you move it, make sure its qualifying sentence moves with it. A polished summary can misrepresent a source without adding a single new number.
Do not create a citation from a plausible title or trust a reference supplied by a drafting tool until the source has been opened. If a link has moved, identify the correct destination and confirm that it still supports the claim. Mark unavailable evidence as unavailable instead of treating a broken reference as proof.
Worked rewrite: an unsupported architecture promise.
The following source paragraph and project conditions are fictional. The purpose is to show an auditable repair, not to describe a client result. The accepted task is to explain how a team should choose page ownership for distinct service questions. The project has a content inventory but no search performance study.
Before
Give every service question its own page and Google will rank the site faster. Separate URLs eliminate overlap. Our method doubled traffic for every client. Put all the related terms in each introduction, then add a comparison table at the end.
After
Give a service question a separate page when it needs a distinct answer and the content can support that answer fully. Check the existing inventory first so another page does not already own the task. A new URL does not remove overlap by itself. Keep relevant terminology in a clear explanation, and use a comparison table only when the reader needs to compare options under stated conditions.
| Source claim or instruction | Observed problem in the example | Repair and reason |
|---|---|---|
| Every service question needs a page | Assumes that different wording always needs a separate answer. | Replace the universal rule with a decision about the task and evidence. |
| Google will rank the site faster | Claims a performance effect with no study or applicable support. | Remove the ranking promise; explain the editorial decision instead. |
| Separate URLs eliminate overlap | Treats a location change as proof of distinct page purpose. | State that ownership and answer overlap still need inspection. |
| Doubled traffic for every client | No client records were supplied in the fictional source pack. | Remove the result claim entirely. Do not replace it with a softer invented result. |
| All related terms in each introduction | No task-based reason for repeating every candidate term. | Retain useful terminology within an explanation. |
| Always add a comparison table at the end | Specifies a format without a comparison task. | Make the format conditional on a stated choice and its criteria. |
The repair preserves the useful subject, page ownership, and the next decision, inspecting the inventory. It deliberately removes unsupported outcomes. It does not claim that the revised page is complete for every service; a real brief would still require the distinct tasks, conditions and evidence for the relevant organization.
Compare the revised answer with the source line by line.
Use a change log that records what moved, changed or disappeared and why. Compare factual statements separately from editorial additions. A new example may improve understanding, but its invented status must remain clear. A newly added procedural instruction needs evidence; it cannot be justified by the fact that the original was incomplete.
Check for losses as well as improvements. A concise rewrite can remove an exception, flatten two different audiences into one or drop a useful video. A longer rewrite can repeat information, add unrelated topics or imply services the organization does not offer. Length alone is not an acceptance criterion.
When original media or tools are omitted, record the reason and the replacement, if any. Do not claim a tool worked merely because its source code exists, or delete useful information without reading it. Where the owner authorizes removing an old tool, retain pertinent instructions or fields as normal text when they help the page’s task.
Set acceptance conditions before release.
Acceptance should describe observable content properties: the opening answers the stated task; material facts are supported; conditions remain attached; the example is complete; links reach the right owner; headings follow a meaningful order; and any omitted source material has a recorded reason. A general “looks better” judgment cannot settle these checks.
A separate reviewer should compare the final candidate with the source and the issue log. Record the reviewer, exact version, remaining uncertainties and decision. If the repair changes the claim or layout after review, reopen the affected checks. Existing publication authority does not prove that a changed answer passed factual review.
Check the deployed output separately from the draft. Confirm that the correct content, metadata, images and necessary links were served, then inspect rendering and function through available evidence. A saved editor field alone does not prove that a custom template displays it, and a source check does not establish keyboard or mobile behavior.
Keep the repair reversible and maintainable.
Preserve the original, issue log, revised version, evidence and release record. A rollback needs to respect later edits rather than blindly restoring an old copy. If a source or service condition changes, reopen the affected claims instead of treating the rewrite’s earlier acceptance as permanent.
After release, review suitable evidence for the original problem. A factual correction can be confirmed through the current source; a navigation repair needs the served route checked. Search changes or reader outcomes require their own observations and should not be attributed to the rewrite without an appropriate basis.
Google’s content usefulness questions can support a broad editorial assessment. The keep/remove/rewrite process here is an inspectable working method, not a search formula. Continue with the writing hub, evidence and useful contribution or the learning overview.