toolkit

Scenario · Content and search

Change the copy on this page

“Can you update the wording on this page?” — with the new text supplied, or a description of it.

An everyday wording change looks too small to need a process, which is exactly why the same two things go wrong every time: nobody records what the page said before, and nobody checks anything beyond the one paragraph they were asked to fix. This snapshots the page first, then compares it against itself after the edit — catching a dropped heading, a broken link, or a shifted layout that a person scanning just the new paragraph would never notice — and flags whether the same wording actually needs fixing on other pages too.

What to ask for

See it work

A real run of Spelling check:

REVIEW — 1 page(s) · 4 suspected misspelling(s)
      recieve ×1  → receive, relieve
      mesage ×1  → message, menage
      definately ×1  → definitely
      busness ×1  → business, busyness

  report: ./out/spelling-check-spelling-check.html
  text:   ./out/spelling-check-spelling-check.txt

The captured report, exactly as a run hands it to a client —open the full report ↗

The everyday copy edit. It is second only to case galleries by volume and it looks too small to need a procedure, which is exactly why the same two things go wrong: nobody records what the page said before, and nobody looks at anything except the paragraph they were asked to change.

  1. Snapshot the page before the edit. This is the whole safety net and it costs one command. Without a before, “did that change anything else” has no answer — you are comparing the live page against your memory of it.
  2. Check the scope of the request. If the same wording appears on other pages, this is a site-wide change wearing a single-page request’s clothing, and it should follow that procedure instead. One page is one page only when you have checked.
  3. [manual] Make the edit in the CMS. Paste or write the approved copy, keeping the existing heading structure unless the request asks otherwise. Publish, then purge the cache — a client looking at a cached page is the most common “you didn’t do it” reply there is.
  4. Compare after against before. The before/after check reports what actually moved: status, title, meta description, canonical, headings, a word-level diff of the copy, every link’s status code, and screenshots with a pixel diff. Read the diff, not just the verdict — an edit that also dropped a heading level or broke a link shows up here and nowhere else.
  5. Read the copy as copy. Spelling on the new text, and a content-quality pass if the edit was substantial — a rewritten section that now duplicates the H1 or reads three grades harder than the rest of the page is a defect the diff cannot see.
  6. Reply with what changed. The before/after report is the reply. “Updated” invites a second ticket asking what was updated.

The trap in a one-paragraph edit

The request names a paragraph, so the work gets scoped to that paragraph. But a CMS edit is a publish: it can shift a layout, drop a link, re-wrap a heading, or invalidate a cache somewhere else on the page. The before/after comparison is not ceremony for a small edit — a small edit is precisely when nobody would otherwise look.

What this does not cover

Whether the new wording is true, compliant, or better than what it replaces. It proves the edit landed and broke nothing else on the page; it cannot tell you that a claim about a treatment is defensible or that the practice is allowed to say it. A change spanning many pages is a different job — see the site-wide word change — and a change to the title or meta description alone has its own procedure.

← All scenarios