SEO Audit Before and After Comparison: How to Do It Right

An SEO audit before and after comparison puts two audits of the same site next to each other. The first is taken before you make fixes and the second one comes after. Each issue gets one of four labels: fixed, improved, unresolved or new. If you run it properly, you learn whether the work actually happened, whether anything broke along the way and what's left to do. One score going up or down can't tell you any of that.

This guide covers how to set up a comparison you can trust and how to read the results. It also covers the follow-up checks in Google Search Console that confirm Google has seen the changes.

What is an SEO audit before and after comparison?

It's a second audit of the same site with the same scope. Each finding in it is matched to the finding it corresponds to in the first audit. You end up with a change list for each issue and each URL, which is more useful than two separate reports, because it shows what happened to every problem you were asked to fix.

Rankings and traffic are what you're ultimately after, but they're outcomes. They move for reasons unrelated to your work, such as seasonality, competitors and algorithm updates. An audit comparison tracks something you control directly: the condition of the site. Did the broken links get fixed? Did the noindex come off the category pages? Did the redirect chains get shorter?

Treat the two as separate jobs:

• Audit comparison: did we fix what we said we'd fix, and did we create new problems?
• Performance measurement: did those fixes change impressions, clicks and conversions? That has its own method, which we cover in how to know if SEO changes are working.

Why isn't comparing the overall SEO score enough?

A score can rise while important problems get worse, and it can fall while the site gets better. Most audit scores are weighted averages across many checks. Fixing 300 missing alt texts can lift the number even if your top landing page still has a noindex tag. The score belongs in a summary, not in your verdict.

Here are three common situations where the score misleads:

1. The crawl scope changed. If the second crawl found 2,000 more URLs, perhaps because a filter or calendar opened up, every count goes up, even on issues you actually fixed.
2. Lab metrics are noisy. Google's Lighthouse documentation says much of the variability in the Performance score is not due to Lighthouse itself. It comes from things like A/B tests, ad changes, network routing, device differences and browser extensions. It also recommends treating performance as a distribution of scores rather than a single number.
3. Easy fixes hide hard ones. A score that improves through dozens of minor fixes can cover up the fact that the one critical issue is still there.

So compare issues and the URLs they affect. The score gets one line in the summary.

How do you set up a fair before-and-after comparison?

Set it up so the only thing that differs between the two audits is the work you did. That means the same start URLs, crawl limits, user agent, JavaScript rendering setting, robots.txt handling and device profile. Save the first audit as a fixed baseline before anyone changes anything, and note the date of every release in between.

Use this checklist before you re-run:

• Freeze the baseline. Export the first audit, including the full URL lists for each issue, not only the summary. You can't compare against a report that only kept the counts.
• Keep the crawl settings identical. That includes whether JavaScript is rendered. A rendered crawl finds links and content that a raw HTML crawl doesn't.
• Keep a change log. List every deploy, plugin update, template change and content batch between the audits, with dates. When a new issue shows up, the change log usually tells you why.
• Map changed URLs. If you changed URL structure, for example by adding or removing trailing slashes or restructuring a folder, the old and new URLs have to be mapped to each other. Otherwise every page looks "missing" and then "new". Screaming Frog's crawl comparison has a URL Mapping feature that uses regex for this.
• Re-check field data separately. Real-user Core Web Vitals need time to catch up (more on this below).

When should you run the "after" audit?

Run it once the fixes are deployed and the site has been stable for a while. Thirty to sixty days after the first audit is usually right for small and mid-size sites. That's long enough to ship the high-priority fixes, and soon enough that you remember what changed. For ongoing cadence, see how often you should audit your website.

How do you read the comparison: fixed, improved, unresolved, new?

Put every issue from either audit into one of four buckets, then check the URLs in each. "Fixed" means the issue is gone from every URL. "Improved" means fewer URLs are affected. "Unresolved" means the issue is unchanged. "New" means it didn't exist in the baseline. The new bucket deserves the closest look, because that's where regressions turn up.

Why do issues show up as "improved" instead of "fixed"?

Most often because a fix was applied to one template but not another. Take an online store that fixed missing H1s on product pages. Collection pages, which use a different template, still show the issue. The number of affected URLs drops but doesn't reach zero. Group the remaining URLs by path or template, and the cause usually becomes obvious within minutes.

What do "added", "removed", "new" and "missing" mean in crawl comparison tools?

Desktop crawlers use their own labels, and they don't line up exactly with the four statuses above. In Screaming Frog's crawl comparison:

• Added: URLs that were in the previous crawl and have moved into an issue filter in the current one.
• New: URLs that weren't in the previous crawl at all and are in the filter now.
• Removed: URLs that were in the filter before and aren't in it now.
• Missing: URLs that were in the filter before and weren't found in the current crawl at all.

The difference between "removed" and "missing" matters. A URL that left the "404" filter because it now returns a 200 has been fixed. A URL that dropped out because nothing links to it anymore hasn't been fixed. It just can't be seen now. Check that the second kind was removed on purpose. The same documentation says the comparison needs database storage mode and a paid licence.

How do you confirm Google has seen the fixes?

An audit shows the current state of your site. Search Console shows whether Google has recrawled it and accepted the change. Once you've confirmed a fix in your own comparison, use the validation tools in Search Console. Expect them to take weeks, not days.

Page indexing issues. After fixing something like a server error or an unintended noindex, click "Validate fix" in the Page indexing report. Google's help page says validation typically takes up to about two weeks, but can take much longer. The states are Started, Looking good, Passed and Failed, and Failed means a certain number of pages still have the issue. The same page notes that new instances found during normal crawling are counted as additional instances of the existing issue. In other words, a regression can bring a "passed" issue back. For specific fixes, see how to fix website indexing problems.

Core Web Vitals. Field data trails behind your deploys. The Core Web Vitals report uses data from the last 28 days, and "Start Tracking" begins a 28-day monitoring period. The issue counts as fixed only if it doesn't appear on any URL in that window. If your "after" audit runs a week after a speed release, the lab numbers may look better while the field data still shows the old state. Note that in the comparison rather than calling it a failure.

What should a before-and-after audit report include?

A useful comparison report answers four questions at a glance: what's done, what's partly done, what's stuck and what broke. It does this with URL-level evidence, so anyone can check the claims. Totals with no URLs behind them are a red flag. You can't verify them, and you can't hand them to a developer.

Look for, or build, these parts:

1. A summary by status. Counts of fixed, improved, unresolved and new issues, sorted by severity, not alphabetically.
2. Per-issue detail. For each issue: the before and after URL counts, example URLs and the fix that was planned.
3. A regressions section. New and worsened issues listed first, each with its likely trigger from the change log.
4. Changes in scope. How many URLs were crawled each time, and why that number changed.
5. The next plan. Unresolved and new items moved into the next 30/60/90-day priority list. If that list is long, how to prioritize SEO fixes explains how to order it.

You can see what this looks like in practice in SEORecheck's sample comparison report, which matches every issue from the previous audit and labels it fixed, improved, unresolved or new. The full sample report shows the baseline it compares against.

Should the comparison cover AI search checks too?

Yes, if your baseline included them. AI crawler access in robots.txt, snippet controls, content that only appears after JavaScript runs, and Organization markup are all site-level settings, and a deploy can change them silently. For example, a security plugin might add a blanket bot block. Compare these the same way you compare other issues: did each check pass before, and does it pass now? Score-like "AI visibility" numbers can't show you what changed.

Which mistakes make before-and-after comparisons misleading?

Most bad comparisons come down to one of these: different crawl settings, a baseline with no URL lists, or treating a temporary dip in a metric as a regression. Each one sends you chasing a problem that doesn't exist or makes a real one look solved.

• Comparing a rendered crawl with a non-rendered one. Link counts and content checks will differ for reasons that have nothing to do with your work.
• Using a different tool for the second audit. Each tool defines issues and thresholds its own way. Mixing tools turns the comparison into guesswork.
• Ignoring URLs that dropped out of the crawl. "Missing" isn't the same as "fixed".
• Reading one Lighthouse run as the verdict. Run it several times, or rely on 28-day field data.
• Leaving the before-and-after comparison until a traffic drop. If traffic has already fallen, diagnose that first. Our website traffic drop guide covers it, and you can audit afterwards.

If you never kept a usable baseline, start one now. Request a free audit and you'll get a dated snapshot of your site's crawl, indexing, on-page, performance and AI-search issues, with example URLs, to compare against later. Recheck pricing depends on the site and country and is listed on the pricing page.

Key takeaways

• Compare issues and URLs, not overall scores. Scores mix many checks and hide regressions.
• Keep the scope, crawl settings and tool the same in both audits, and save the baseline with full URL lists.
• Label every issue fixed, improved, unresolved or new (or worsened), and review new issues first.
• "Missing" from a crawl isn't the same as fixed. Check why the URL disappeared.
• Confirm fixes in Search Console. Indexing validation usually takes up to about two weeks, and Core Web Vitals tracking runs for 28 days.
• Measure traffic and ranking results separately, after the site's condition has improved.