To review a large Webflow migration before launch, compare the migrated site on staging against the current live site. Focus on the pages that changed.
Check for missing or unexpected pages, visual differences on desktop and mobile, broken links, planned redirects, SEO changes, and performance issues on key pages. Fix the issues, then run the same review again before launch.
Why spot-checking does not work for large migrations
A large Webflow migration can look successful even when problems are hiding underneath.
The homepage loads. A few landing pages look right. The navigation works. The team checks the main CMS templates and prepares to move on.
But a site with over 1,000 pages cannot be reviewed by opening a few examples and hoping the rest followed the same pattern.
A shared component may have shifted on mobile. A CMS page may be missing. Links may still point to old URLs. Metadata may have disappeared from pages nobody opened. A page removed intentionally may not redirect anywhere.
Spot-checking gives you a sample.
A large migration needs broader coverage.
Your team should not have to inspect over 1,000 pages manually. A good review process narrows the work down to the pages that disappeared, appeared unexpectedly, or changed. Your team can then decide what was intentional and what needs to be fixed.
The list should get shorter with each review. Review the issues, fix what needs attention, run the comparison again, and repeat until the remaining changes are expected.
This guide walks through that process: what to capture before launch, what to compare, how to spot repeated issues, and why the review should be run again after fixes.
This review process does not replace the full migration plan. For redirect strategy, DNS, SSL, analytics setup, Search Console updates, performance benchmarks, and the complete before, during, and after workflow, use the website migration checklist.
Before the review, know what should exist
What should be present on the new site?
A sitemap is useful, but it is not the complete answer.
Some pages may sit outside the sitemap but still receive traffic. A sales team may rely on a campaign landing page that marketing no longer remembers. A regional team may know about localized pages that are easy to miss. Older CMS sections may contain pages that are still linked internally even though nobody has touched them recently.
Before comparing the old and new sites, bring together the sources that help you understand the current one:
- sitemap
- Google Search Console
- analytics
- CMS exports
- important campaign URLs
- stakeholder knowledge
- pages reachable through the site’s internal links
This is not a full migration-planning exercise. It is a review prerequisite.
You need a practical reference for what should still exist, what was intentionally removed, and which pages matter enough to inspect closely.
Sitepager helps with one part of this groundwork by following internal links from the URL you provide and capturing reachable pages. That can surface pages linked somewhere on the site, even if they do not appear in the sitemap.
It does not replace analytics, CMS exports, or stakeholder input.
Those sources tell you what matters. Sitepager helps you capture the current site so you can compare the migrated site against it later.
Capture the current site as your reference version
Once you understand what should exist, capture the current live site as a baseline before launch.
A baseline is a captured version of your live website that you use as the reference for later comparisons.
A baseline removes the guesswork from the review.
Without it, teams end up asking questions like:
- Was this image always cropped this way?
- Did this page exist on the live site?
- Was this link already broken?
- Did this heading disappear during the migration?
- Was the mobile spacing always this tight?
With a baseline, the team can compare the staging Webflow site against the captured live version.
The process is simple: capture the live site, compare the staging version against it, review the differences, fix the issues, and run the same review again.
Instead of opening thousands of staging pages manually, your team reviews the smaller set of pages where something actually changed.
For the exact Sitepager setup steps, see the guide to testing a website migration.
Compare the staging site against the current live version
Once the staging site is ready, compare it against the current live version.
Sitepager puts the differences and issues into one report, so your team can focus on the pages that need attention before launch.
Not every difference in the report is a problem.
The report’s job is to narrow the review list.
Your team decides what is intentional.
That distinction matters because migrations often include deliberate changes:
- refreshed layouts
- updated typography
- new images
- different navigation
- redesigned sections
- consolidated pages
- retired content
A visual difference may be completely expected.
A missing CMS page, broken link, or mobile layout issue may not be.
The team no longer has to rely on memory or randomly sample pages. It can work through the pages that actually changed.
Review four types of changes
A large migration becomes easier to review when you separate the findings into four buckets.
| Review area | What to look for | What to do |
|---|---|---|
| Page coverage | Missing or unexpected pages | Restore, remove, or redirect |
| Visual changes | Layout, spacing, images, and mobile issues | Mark expected changes or fix problems |
| Links and redirects | Broken links, old URLs, and pages that need redirects | Update links and prepare redirects |
| SEO fields | Missing or changed titles, descriptions, headings, and canonicals | Review and correct unexpected changes |
1. Missing or unexpected pages
Start by checking whether pages disappeared or appeared unexpectedly between the live site and staging.
A missing page may mean:
- it was dropped during the migration
- it was intentionally retired
- it needs a redirect
- it exists in the new CMS but is no longer linked from the site
- it was created in the CMS but was not published correctly
An unexpected page may mean:
- a draft page was published accidentally
- a CMS collection created extra pages
- a duplicate version exists
- it is a staging artifact that should not go live
Sitepager highlights added and removed pages between runs, so your team reviews a smaller list instead of comparing spreadsheets manually.
Your team decides whether each change is correct.
2. Visual differences on desktop and mobile
Visual differences are often the first sign that something went wrong.
A page may still load correctly while looking wrong:
- a button moves out of place
- a hero image crops differently
- text overlaps another element
- spacing changes across a shared template
- mobile navigation breaks
- translated copy pushes a layout beyond its original width
Desktop checks alone are not enough.
A page that looks fine on a laptop may still break on a phone. Mobile layouts are especially vulnerable when content has been imported into new templates or rebuilt in a different CMS.
Pages that look unchanged need less attention. Pages with differences become review items.
Sitepager can compare screenshots of the staging site with the live site and highlight the changes for your review. For a detailed explanation of how screenshot comparison helps teams spot visual changes between website versions, see visual testing for websites.
3. Broken links and planned redirects
A migration can leave links pointing to old destinations even when the visible page looks fine.
Before launch, review:
- broken internal links
- broken external links
- links that still use old URLs
- removed or renamed pages that will need redirects
Fix broken links before launch and make sure the redirect plan covers pages that are moving or being retired.
After launch, confirm that those redirects work correctly on the live domain.
4. Missing or changed SEO fields
A page can look right on staging and still lose important SEO information during the migration.
Review changes to:
- page titles
- meta descriptions
- heading structure
- Open Graph tags
- canonical tags
Sitepager flags missing SEO fields so you can inspect anything unexpected. It also flags missing or invalid canonical tags and highlights canonical mismatches before launch.
Focus on basic SEO fields that disappeared or changed unexpectedly during the move.
Add a performance check for key pages
A migration can also make key pages slower, even when staging looks fine visually.
New templates, larger images, third-party scripts, and platform changes can affect load time even when the visual comparison is clean.
Performance should be treated as an additional review layer, especially for key landing pages, high-traffic pages, and important templates.
Sitepager can run optional Lighthouse audit reports alongside the migration review. Use them to spot pages that need a closer look.
Use this as an early warning before launch. If a key page became slower on staging, investigate the cause before going live.
Look for patterns across templates, mobile layouts, and languages
The biggest migration problems are often not isolated.
They repeat.
Look for the same issue appearing across shared components, templates, mobile layouts, and language versions before treating any single page as a one-off fix.
One broken image on one page may be a small fix.
The same image issue across 200 CMS pages usually means the template needs attention.
The same is true for:
- headers
- footers
- navigation
- shared sections
- CMS templates
- button styles
- mobile layouts
- language versions
Multilingual websites add another layer of complexity.
A page may look correct in one language and break in another because the translated text is longer. A menu label may wrap unexpectedly. A button may become too narrow. A regional page may keep an older link or miss an updated image.
For global sites, see how a trading platform reviews 5,800+ pages across 18 languages in one workflow.
When reviewing differences, do not treat every page as an isolated item.
Ask:
Is this one page, or is this a repeated pattern?
That question helps the team find the underlying cause faster.
Use a shared review report to involve the right teams
A large migration touches too many corners of the website for one team to review alone.
Marketing may know which campaign pages matter most.
Sales may rely on campaign pages that never appear in the sitemap. Regional teams may know about localized versions that the rest of the team has not thought about since they were first built.
Developers may know which integrations, forms, or custom components deserve closer attention.
A large migration review works better when those teams have one shared place to inspect what changed.
Sitepager gives teams a shared report for reviewing visual differences, missing pages, broken links, and SEO changes.
Different teams can work through one review list instead of sending screenshots and notes back and forth.
Fix the issues and run the same review again
Fix a batch of issues, then run the same comparison again.
The first review tells you what needs attention.
The next review tells you whether the fixes worked.
That second run matters because a fix can create a new issue, especially when it affects a shared component or template.
After making a batch of fixes:
- Run the same comparison again.
- Confirm the original issue is gone.
- Check whether anything new appeared.
- Review the remaining differences.
- Repeat until what remains is intentional.
A migration review is a loop, not a one-time scan.
That is the difference between checking the staging site once and building a repeatable review step your team can trust before launch.
For interactive elements such as dropdown menus, tabs, modals, or mobile navigation, Sitepager supports optional hover and click selectors. These checks need to be set up separately. They do not run automatically.
After launch: check the live site again
Once the migrated site is live, check it again on the live domain.
Confirm that:
- redirects work
- links still work
- analytics and tracking are recording correctly
- the updated sitemap has been submitted to Search Console
- key pages and user journeys still work as expected
Keep monitoring the site over the following weeks:
- indexing: are the right pages appearing in search?
- rankings: are key pages holding position?
- traffic: is organic and direct traffic tracking as expected?
- conversions: are forms, CTAs, and key user journeys working?
Some issues only become visible after search engines recrawl the site or real visitors move through important pages.
Keep the same review step for future website updates
After a successful migration, the site often moves faster: more people publishing, more pages going live, fewer gatekeepers.
It also means the website changes more often.
The same baseline-and-comparison workflow used during the migration can become the regular review step after future website updates.
Run the review after meaningful changes:
- new campaign pages
- CMS updates
- template changes
- navigation updates
- redesigns
- localization rollouts
- major content releases
The migration may be the first time the process matters.
It should not be the last.
Make the same review step part of every meaningful website update.
Frequently asked questions
Do you have to check every page before a Webflow migration goes live?
You should review the full website before a Webflow migration goes live, but you do not need to open every page manually. Compare the staging site against the current live site to find missing pages, visual differences, broken links, pages that need redirects, and SEO changes. Your team can then focus on the pages that need attention before launch.
How do you find pages that are missing after a website migration?
Start with the sitemap, analytics, Search Console, CMS exports, and stakeholder input. Then compare the pages reachable through the live site’s internal links against the staging version. Pages that exist on the live site but are missing from staging should be restored, intentionally removed, or redirected before launch.
How do you know a Webflow migration is ready to go live?
A Webflow migration is ready to go live when the staging site includes the expected pages, removed pages have redirects planned, layouts look right across desktop and mobile, links work, and key SEO fields are intact. Compare staging against the current live site one final time and confirm that any remaining differences are intentional.
What should you check after a website migration goes live?
After a website migration goes live, confirm that redirects work on the live domain, links still work, analytics and tracking are recording correctly, and the updated sitemap has been submitted to Search Console. Then monitor indexing, rankings, traffic, and conversions over the following weeks.
