How to Compare Rendered HTML Before and After a Migration

The most useful migration audit is often not a screenshot comparison.

Screenshots tell you whether the new page looks roughly like the old one. They do not tell you whether the title changed, the canonical points somewhere else, body copy disappeared, headings lost structure, schema no longer matches visible content, or internal links became buttons.

For search, accessibility, and answerability, rendered HTML is the evidence that matters.

That means comparing the old and new page output after the browser has rendered the page, but before you make assumptions from source code. Source files explain root causes. Rendered output proves the issue exists.

Choose Representative Templates

Do not compare every URL by hand.

Pick representative URLs from each important template:

• homepage
• service page
• article
• category page
• product page
• filtered listing
• location page
• campaign page
• contact or enquiry page
• high‑traffic legacy URL

Include pages that matter commercially, pages that earn search traffic, and pages that have awkward data. The route that behaves badly is rarely the polished homepage.

If you are debugging an existing drop, start with the affected route family. If you are auditing before launch, start with the templates that carry the most traffic or conversion value.

Capture Old and New Rendered Output

For each URL pair, capture:

• final URL
• status code
• redirects
• document title
• meta description
• canonical
• robots directives
• h1
• heading list
• visible body text
• internal links
• images and alt text
• structured data
• hreflang where relevant
• pagination links
• response headers where relevant

You can collect this with a crawler, browser automation, or a small script using a real browser context. The important thing is consistency. Compare the same fields for the old and new versions.

Google's guide to site moves with URL changes is useful context, but a rendered HTML comparison gives you a more detailed template‑level view.

Compare Titles and Descriptions as Intent

Title and description changes are not automatically bad.

A migration is often a good time to improve weak metadata. The question is whether the new metadata still matches the page intent.

Look for:

• generic titles replacing specific ones
• brand suffixes missing or duplicated
• title tags too long or too short
• meta descriptions copied across templates
• descriptions no longer matching visible content
• article titles changed without redirects or slug decisions
• service pages using internal language instead of user problems

This is especially important when moving from a CMS plugin to a custom metadata system. The old metadata may not have been perfect, but it may have contained deliberate editorial work.

Compare Headings as Document Structure

Headings are not just visual text.

Check:

• one sensible h1
• h1 matches page intent
• no empty headings
• no skipped levels without reason
• headings describe the following content
• repeated headings are not confusing
• component headings do not dominate the document outline

Many redesigns accidentally turn meaningful headings into styled divs, or promote card titles into heading noise. Both can weaken structure even if the page looks cleaner.

For more on the underlying principle, see HTML markup for SEO.

Compare Body Content and Visible Entities

Rendered body text is where a lot of migration damage hides.

Check whether the new page preserves:

• main explanatory copy
• product or service details
• pricing or availability where relevant
• author and date information
• location or market detail
• proof and case‑study references
• FAQs if they existed visibly
• editorial caveats and qualification

Do not only compare word count. A shorter page can be better. A longer page can be worse. Compare meaning.

For service and technical pages, check whether the new copy still names the real entities: Next.js, React, Vercel, CMSes, performance, structured data, migration, or whatever the page actually covers. Entity loss can make a page harder for search engines and answer systems to place in context.

Compare Links as Crawl Paths

Internal links are often damaged during component rebuilds.

Check:

• navigation links
• breadcrumbs
• related articles
• related services
• pagination
• product or category links
• article body links
• call‑to‑action links
• footer links

Then inspect anchor text and href values. A clickable card with no descriptive anchor is not equivalent to a useful text link. A JavaScript click handler is not always a crawl path. A duplicated "Read more" label across the whole page may be less helpful than a specific link.

This is also where migration work can strengthen the site. If the new platform exposes better related content, service links, or case‑study references, capture that as an improvement.

Compare Structured Data Against Visible Content

Structured data should not survive a migration as a copied blob.

Parse the old and new JSON‑LD and compare:

• schema types
• names and descriptions
• canonical URLs
• breadcrumbs
• authors
• dates
• images
• offers or services
• FAQs only where visible
• product data only where visible

Google's structured data guidance is clear that markup should describe page content. If the new schema describes old content, hidden content, or a different page type, fix the model.

Decide Whether Each Difference is a Regression

Not every difference needs fixing.

Classify differences as:

• intentional improvement
• harmless change
• needs editorial review
• technical regression
• launch blocker

Examples of launch blockers:

• production noindex
• canonical to the wrong host
• important pages 404ing
• missing body content
• broken internal navigation
• schema contradicting visible content
• old high‑value URLs without redirects

Examples of acceptable differences:

• improved title
• removed thin tag links
• consolidated duplicate page
• simplified heading structure
• better service copy

The comparison is evidence. The judgement still needs a human.

Wrapping Up

Rendered HTML comparison turns migration anxiety into a concrete review.

Instead of asking whether the new site "looks the same", you check whether it still exposes the same or better meaning: titles, descriptions, headings, content, links, schema, media, directives, and route behaviour.

That is the evidence you need before launch, and the evidence you need after a traffic drop. Source code can wait until the rendered problem is visible.

Key Takeaways

• Compare representative templates, not just the homepage.
• Capture rendered output consistently before judging the migration.
• Treat metadata, headings, body copy, links, media, and schema as migration evidence.
• Classify differences as improvements, harmless changes, regressions, or blockers.
• Use source files to explain issues only after rendered output proves them.