An old bridge-inspection page may still rank well in search results even after its account of inspection intervals, defect categories or reporting practice has become unreliable. Changing the date at the top does nothing to fix it. Start by identifying statements a reader might use to make an engineering or operational decision, then check whether the evidence still supports them.
Some parts of an older page may remain sound while others refer to superseded documents, unavailable datasets or obsolete equipment. Its conclusions may also have gone further than the evidence allowed when it was first published. Reviewing those elements separately makes each change easier to justify.
Start with an inventory, not a rewrite
List each page's title, URL, original publication date, last substantive review date, subject, main purpose and named technical reviewer, where applicable. Record what the page relies on: standards, agency guidance, research papers, project records, manufacturer documentation or monitoring data. A missing review date does not mean the page is wrong; it means its status has yet to be checked.
Group pages by the decisions they could influence. A definition of differential settlement poses a different risk from an interpretation of settlement readings beside an operating railway. A historical account of a bridge project also needs different attention from guidance on assessing corrosion-related deterioration. This grouping helps separate urgent technical review from routine editorial work.
A short triage record is often more useful than page-view figures alone:
- Reader task: What is someone trying to understand or decide?
- Potential consequence: Could an error affect inspection, maintenance, design assumptions or safety communication?
- Change exposure: Does the page depend on requirements, methods, products or datasets that may have changed?
- Evidence condition: Can the editor still examine the material behind important claims?
- Actual use: Is the page regularly consulted, cited internally or sent in response to technical questions?
High readership warrants a look, not necessarily a major rewrite. A little-read page containing an unsupported instruction about tunnel water ingress may need attention first. Use readership and search data to find where people encounter the material; let technical consequence determine the priority.
Decide what kind of update the page needs
Not every old page needs to become a new article. Decide what to do with it before editing, and record the reason.
| Disposition | When it fits | What to check |
|---|---|---|
| Retain with a review note | The explanation remains accurate and its scope is clear. | Verify critical claims, terminology and cited material. |
| Correct specific passages | A limited number of facts, captions or references have changed. | Check surrounding sentences for conclusions that relied on them. |
| Rebuild the page | The reader task is still valid, but the structure or technical basis is no longer adequate. | Reassess the original premise as well as the evidence. |
| Preserve as an archive | The page documents a past project, method or decision and should not be mistaken for current guidance. | Label the period and explain any limits on present-day use. |
| Consolidate or retire | Another page now answers the same task more accurately, or the material cannot be responsibly maintained. | Preserve access to information readers still need. |
Archiving works well for dated case material. An account of a pavement rehabilitation scheme can keep its original observations while explaining which conclusions applied only to that site and investigation period. Rewriting historical measurements as if they had just been collected would misrepresent the record.
Separate age from technical validity
A sound explanation of pore-water pressure does not expire on a calendar date. Its diagram might need a clearer caption, but the mechanism is not obsolete simply because the page is old. A recent article, on the other hand, can be unreliable if it gives a monitoring threshold without identifying the instrument, ground conditions, baseline or decision process.
Watch for phrases such as “current requirement,” “standard practice,” “always,” “safe limit” and “recommended interval.” Their meaning may depend on jurisdiction, asset class and date. Where the evidence permits, replace sweeping claims with explanations that state their limits. Do not swap an old number for a newly found one without qualified technical review.
Recheck claims at the level of the reader's task
A line-by-line fact check can miss a misleading conclusion. Consider an older article that says a single settlement reading determines whether a railway embankment needs intervention. Its descriptions of survey equipment might be accurate, while its account of the decision process is not. The reviewer must look at how the page treats measurement uncertainty, trends, site history and operational context together.
For each consequential claim, record its support and its limits. Ask:
- Is the claim descriptive, interpretive or prescriptive? Prescriptive statements need particular care.
- Does the source support the exact wording, or only a narrower point?
- Do the date, jurisdiction, asset type and site conditions affect its application?
- Would new evidence change the conclusion or merely add context?
- Does the page distinguish observed results from the author's inference?
An inaccessible source does not automatically make a claim false, but it does prevent verification from that source during the review. Find defensible support, narrow the wording or remove the claim. For cited standards and guidance, check the edition and scope; a familiar title does not guarantee that the requirements have stayed the same.
Keep technical review separate from copyediting. An editor can improve headings or clarify a sentence about drainage. Determining whether that sentence accurately describes a site's hydraulic behaviour calls for appropriate expertise. Leave unresolved engineering questions visible in the review record rather than editing them into certainty.
Repair the page around the updated evidence
Once the technical basis is settled, check whether the page still does what readers need it to do. Older posts often acquire additions at the bottom while an outdated answer remains at the top. Put the dependable explanation where readers need it, remove duplication, and place conditions and limitations beside the claims they qualify.
A page on pavement distress, for instance, may mix photographs, possible causes and repair language in a single list. Separate observed symptoms from possible mechanisms, then explain what further investigation could distinguish among them. Cracking alone does not establish one cause; drainage, traffic history, materials and subsurface conditions also matter. That distinction makes the page more useful without prescribing a treatment.
Give tables, diagrams, captions and downloadable files the same scrutiny as body text. A corrected paragraph cannot offset a figure that presents a historic test result as a design value. Check units, axes, legends, dates and abbreviations, along with whether alternative text conveys what the visual shows. State the context near an illustration if it relies on a specific project dataset.
Check how readers reach the page and where it sends them. Navigation labels, excerpts and references from other posts may still promise an answer the revision no longer gives. Link text should accurately describe the destination. For example, a page about revising an article after publication serves a different purpose from competitor research for transport-infrastructure editorial planning.
Keep a visible, proportionate change record
A “last updated” date should mean something. Distinguish a substantive technical revision from a spelling or formatting fix. For a significant update, a brief note can identify the sections changed, the review date and any earlier interpretation that was corrected—especially if readers may have copied the old wording into other documents.
Where practical, keep the previous version in the publication's records, together with the reviewer, source editions checked and outstanding limitations. The public page does not need a full audit trail, but the editorial team should be able to reconstruct why a consequential statement changed. If an error may have affected a past decision, consider whether known users need direct notification rather than only a revision note.
Publish only after a final-context check
Read the revised page as someone arriving through a saved bookmark, without knowledge of the editing history. Is its date and scope clear? Are historical examples identified? Does any heading promise a current procedure the text cannot support? Check on mobile and desktop that tables are readable and captions remain with the right figures.
Check material reused elsewhere, too: search snippets, summaries, newsletters, downloadable copies and translations, if they exist. An old summary saying “settlement above this value requires closure” can keep an unsupported instruction in circulation after the article has been corrected. Record which versions were checked and assign owners where separate technical review is needed.
Set the next review trigger to match the content rather than applying one interval to every page. A publication date may suffice for a stable historical account. An active monitoring page may need review when its dataset or interpretation changes; a method comparison may need another look when cited guidance is replaced. Write the trigger in the editorial record—for example, “recheck this page when the referenced bridge inspection manual changes edition”—so the next editor knows when to bring it back to the desk.
