Website launch & migration copy QA checklist
A launch or a CMS migration is where copy quietly breaks: content gets re-templated, re-imported, and re-flowed into new components, and the errors land on the pages nobody re-reads. This checklist covers the copy QA pass for a launch or migration — scoped to what proofreading actually catches, with the non-copy checks flagged to run separately.
Last reviewed: 2026-06-21
A launch or migration copy QA checklist should cover six kinds of copy error on every page that moved or changed: spelling and typos, grammar, punctuation and spacing, clarity, style and consistency, and leftover placeholder or template copy. Migrations are where placeholder copy and broken formatting creep in — content gets re-templated into new components and re-imported, and the damage lands on the long-tail pages no one re-reads.
Proofread the new build, page for page, rather than trusting the old copy carried over clean. Run the copy pass across the whole migrated site — Verant crawls every page and proofreads the rendered copy for the six kinds, verifying each correction with a second AI agent. Keep the non-copy launch checks — redirects and broken links, SEO metadata, accessibility — on a separate list, run with their own tools, so neither pass gives a false sense of done.
Why a migration breaks copy
When content moves to a new CMS or theme, it rarely lands cleanly. Copy gets re-imported and re-flowed into new components, rich-text fields lose or mangle formatting, and pages get rebuilt from a fresh template that ships with its own placeholder defaults. A page can look right in the new editor while a footer column, a secondary tab, or a card still holds "your text here" or a leftover lorem-ipsum block from the template.
The pages most at risk are the ones the launch team never opens after the import: deep service pages, older posts, and the templated location or product pages cloned from one starter. The home page gets re-checked a hundred times; the long tail gets imported once and shipped. That is exactly where a launch or migration leaves copy errors behind.
Proofread the new build, not the old copy
The text to check is whatever the new CMS, theme, and components actually rendered — which can differ from the source you migrated and from what shows in the editor. So run the pass against the staging or production build of the new site, and proofread the rendered page, not a content export. A crawl beats clicking through every page: it checks every public URL the same way, instead of relying on the launch team to remember each one.
This is a copy check, not a full migration QA. It catches the six kinds of writing error on the migrated copy. The structural launch checks — that old URLs redirect, that nothing 404s, that metadata carried over, that the site is accessible — matter just as much at launch, but they are separate passes with their own tools. Keep them off the copy list so neither one masks the other.
The copy QA checklist — the six kinds
Copy errors to proofread on every migrated page
These are the six kinds a proofreading pass catches. Run each across every page that moved or changed — not just the home page.
- Spelling and typos. Misspellings, transposed letters, and doubled or dropped words — including any introduced when copy was re-keyed or re-imported.
- Grammar. Subject-verb agreement, tense, and sentence-structure errors in the visible copy after the new page renders.
- Punctuation and spacing. Punctuation and spacing that broke in the move — stray double spaces, smart quotes flipped to straight, mangled dashes from a rich-text re-import.
- Clarity. Sentences that are hard to read or ambiguous to a first-time visitor — including copy truncated or re-flowed oddly into a new component.
- Style and consistency. Awkward phrasing, and copy that now reads inconsistently from page to page because sections were rebuilt from different templates.
- Placeholder and template copy. Leftover lorem ipsum, "your text here", sample copy, and untouched defaults from the new theme or template that shipped during the rebuild.
Also check separately (not part of the copy pass)
These launch and migration checks matter just as much, but a proofreading pass does not cover them — run each with the right tool so neither check gives a false sense of done.
- Redirects and broken links. Confirm old URLs redirect and nothing 404s with a link or redirect checker — proofreading reads copy, it does not validate URLs.
- SEO metadata. Check that title tags, meta descriptions, and canonical/Open Graph data carried over with an SEO tool — that is an SEO check, not a copy check.
- Accessibility. WCAG conformance, contrast, and screen-reader behavior on the new build need an accessibility audit.
- Facts and figures. Prices, dates, and claims that may have gone stale during the project need a human fact-check — proofreading checks how copy reads, not whether it is true.
How to run the copy QA pass on a launch or migration
- 1
Build the full list of pages going live — every URL on the new build, including the templated and re-imported pages where placeholder and copy errors hide.
- 2
Run the pass against the new build (staging or production), not the old site or a content export — the copy being checked is whatever the new CMS and components actually rendered.
- 3
Crawl the whole site instead of spot-checking: paste your URL into Verant and run a full-site scan so every migrated page is proofread the same way for the six kinds.
- 4
Review the flagged corrections in context — Verant quotes your exact text and verifies each fix with a second AI agent — and fix them in the new CMS.
- 5
Run the separate launch checks — redirects and links, SEO metadata, accessibility, facts — with their own tools, then re-scan the copy after edits and ship.
How verification works
Most proofreading agents show you every suggestion and make you sort the good from the bad. Verant runs an adversarial second pass — Claude Sonnet proofreads, then GPT-5 tries to break each correction. What survives is what we show you. Verbatim is sacred: every flag quotes your exact text; we never auto-apply fixes.
Keep going
- Verant for agencies Run the copy pass on every client launch and handoff — proofread the whole site from the URL before it ships.
- Find leftover placeholder text The placeholder line of the checklist, expanded: what counts, why it ships during a rebuild, and how to find every instance.
- Website proofreading software What website proofreading is, the full "what Verant catches" taxonomy, and the explicit list of what it does not do.
Related reading: Verant for agencies, find leftover placeholder text, and website proofreading software.
Frequently asked questions
What should a launch or migration copy QA checklist include?
The six kinds of copy error a proofreading pass catches: spelling and typos, grammar, punctuation and spacing, clarity, style and consistency, and leftover placeholder or template copy. Run each on every page that moved or changed, not just the home page — migrations break copy on the long-tail pages no one re-reads.
Why do migrations introduce so many copy errors?
Content gets re-imported and re-flowed into new components, rich-text formatting breaks in the move, and pages get rebuilt from templates that ship with their own placeholder defaults. The damage lands on the pages the launch team never re-opens after the import — deep service pages, older posts, and cloned templated pages.
Is copy QA the same as full launch QA?
No. Copy QA is the proofreading pass — the six kinds of writing error. A full launch QA also covers redirects and broken links, SEO metadata, page speed, and accessibility, which are separate checks with their own tools. Keep them off the copy list so neither pass gives a false sense of done.
How does Verant fit into a launch or migration?
It runs the copy pass automatically across the new build: crawl every page, proofread the rendered copy for the six kinds, and verify each correction with a second AI agent before showing it — so you review genuine issues with your exact text quoted, not a wall of false positives.