How to Check Content After Moving to a New CMS

Key takeaways

Compare the new page with an agreed old version.
Test useful content and actions, not just the design.
Record missing items separately from approved changes.
Repeat failed checks on the public release.

A CMS migration content checklist should compare the new page with the old version that the team agreed to preserve. Check the answer, headings, media, files, and useful actions. Record what changed, whether it was approved, and who must fix any gap.

A page can look tidy while losing a table, a download, or the form a customer needs. A successful import message is a starting point for review, not proof that the content still works. This guide focuses on that comparison after a platform move. Use the website migration SEO guide for the wider release plan.

Start your CMS migration content checklist with a clear baseline

Use the agreed old-to-new URL map to compare the right pair of pages.

Keep a dated copy of the old page and the approved change notes. Use the version that the team meant to move. If an editor updated the old site during the project, record that change rather than comparing against an outdated copy without knowing it.

Name the old URL, the new public URL, and the reviewer for each case. Keep a test-site reference separate from the public address. A result from staging does not by itself approve a later public release.

Agree on what must stay and what can change. A new layout may be planned. A lost service condition may not be. This small step prevents reviewers from treating every difference as a fault or every missing section as a design choice.

Choose pages that exercise the changed content types

Use the migration URL inventory to select cases and keep their source records attached.

Pick examples from the templates and features touched by the move. Include a long article, a service page, a page with a table, and one with downloads or a form if those exist. Add the languages and layouts the site uses.

For a small site, the team may review every important page. For a larger site, record what the sample covers and what it leaves open. A clean result on one plain article cannot prove that every custom block moved correctly.

Note recurring faults by template or content type. If three tables lose their header row, give the developer the shared pattern as well as the page examples. That may support a broader fix and a larger retest.

Read the text and headings side by side

Compare the main answer before counting words. Check names, figures, conditions, lists, quotes, and the next step offered to the reader. A similar word count can hide a missing answer and an extra footer.

Follow the heading order through the page. Check that a section title still describes the text below it. A CMS may import a styled line as a plain paragraph or leave an empty heading behind. Read the published output, not only the editor fields.

Open tabs, accordions, and other controls that hold useful text. Confirm that the answer is present and can be reached. A screenshot of the first view will miss content that no longer opens further down the page.

Keep editorial changes separate from transfer faults. If the new offer has different terms, get the business owner to confirm them. Do not restore an old claim merely to make two versions match.

Check images, captions, tables, and downloads

Open the actual assets used by the page. Check that each image is the intended version, that captions still belong to the right image, and that useful alternative text survived. Review small screens as well as the wide layout.

Read tables row by row where the data matters. A shifted column can change the meaning even when every word is present. Check labels, units, and any note needed to understand the values.

Follow download links and inspect the files. A button that opens a file is not enough if it serves an old menu or a blank PDF. Ask the content owner to confirm the version and purpose of the file.

Google’s site-move guidance includes transferring images and downloads and checking URL references. Keep those assets in your review, not in a separate folder everyone assumes was handled.

Test the actions the content promises

For old links that reach this page, check the redirect route as well as the task at the end.

Walk through the reader’s task. Can someone reach the quote page, open a checklist, use the menu, or complete a permitted form test? Ask the feature owner how to test without sending real orders or unwanted messages.

Check what happens after the action. A form may display success while the message never reaches the expected place. Record what was verified and ask the responsible team to confirm any step you cannot observe.

Use the same visitor state for the comparison. A signed-in reviewer may see controls or content that a public reader does not. Record consent choices, language, and device size when they affect the case.

Turn each gap into a specific fix

Send unexplained missing pages to the review for pages with no replacement so accidental loss stays separate from an approved retirement.

Write the expected result, actual result, page, and affected item. Assign an owner and a review state. Keep approved differences visible so the next person does not spend time reporting them again.

For example, “the current menu PDF should open from this button, but the link opens the prior edition” gives the owner a testable task. “Downloads broken” does not tell them which file or version needs attention.

Ask the release owner which faults block sign-off. A failed booking action may need a different response from a misplaced caption. Use the business impact and agreed launch rules, rather than treating every check as equal.

Example: compare a moved catering guide

Imagine a fictional catering site moving a guide to a new CMS. The old guide includes a planning table, a menu PDF, and a quote button. This is a review example, not a measured client result.

The reviewer finds the main text intact, a missing table note, and a quote link leading to the wrong service area. Each issue gets its own row. The table owner restores the note; the business owner confirms the correct quote path.

The reviewer repeats the same checks after release. A good-looking new page does not close either row until the note and the correct task path are present. The test record makes the sign-off about reader use rather than appearance alone.

Verify the public version and close the review

Escalate a launch-blocking fault under the agreed rollback plan instead of making an unplanned return from the editor.

After the fix, open the public page and confirm that it shows the intended release. Repeat failed checks and related cases if a shared template changed. Keep unresolved gaps assigned to an owner.

DEX Health can review public-page quality and SEO, including on the free plan. Use it alongside this content comparison. It does not know every item your business meant to preserve or prove that a form completed its full path.

Close the review when the required content and actions work, approved changes are clear, and remaining issues have an agreed next step. Keep a useful summary for the next release instead of relying on the memory of whoever performed the import.

FAQ

Does the same word count prove content survived?

No. Read the answer, headings, tables, and linked files. Equal totals can hide missing or changed material.

Can I check only the home page?

No. Choose examples from the page types, languages, and features affected by the move.

Does DEX Health replace a before-and-after comparison?

No. Use its public-page review alongside the saved source and direct function checks.

Sources

How to move a site · Google Search Central

Dex SEO

Dex SEO is an AI SEO agent for small businesses. Every article here is planned from search data, drafted by Dex, fact-checked against the sources it cites, and reviewed by the team before it is published.

How this article was made: planned and drafted by Dex from search data, fact-checked by Dex (5 claims checked), then approved by the Dex SEO team.