How does an SEO company measure technical improvements?
By recording the specific problem before the fix, measuring the same thing again afterwards, and using the reports in which Google shows how it actually treats the site. Technical work happens in code and server settings, so rankings and traffic are too indirect to show whether a particular fix worked. The direct evidence is a count that changed: fewer pages excluded for a given reason, fewer server errors, better field data for page speed. A credible report also separates what the data proves from what it only suggests.
Start with a dated baseline
Before any fix, the company records the current state of each issue it plans to address: how many pages are excluded from the index and for which reasons, how many crawl errors occur, how pages perform on Core Web Vitals, how many pages have missing or duplicate titles. Each item needs the starting number, the target, and the date the fix was made. After the work, the same numbers are taken again from the same source. Without that pairing, “improved” is an opinion.
Indexing: the Page indexing report
Search Console’s Page indexing report shows how many pages are indexed and groups the others by reason, using labels such as Crawled – currently not indexed, Discovered – currently not indexed, Duplicate without user-selected canonical, and URL blocked by robots.txt. If the work targeted one of these reasons, the count under that reason is the measure. For individual pages, the URL Inspection tool confirms whether a repaired page is now indexed and how Google renders it.
Crawling: the Crawl Stats report
Search Console’s Crawl Stats report shows, among other things, total crawl requests, average response time, host status, and crawl responses, with example URLs for each. A fall in server errors or not-found responses, or a faster average response time after a server change, is direct evidence. Google is clear about who needs it: “If you have a site with fewer than a thousand pages, you should not need to use this report or worry about this level of crawling detail.” On a small site, a company presenting crawl statistics as a main result is measuring the wrong thing.
Page speed: field data over a 28-day window
For speed and stability, the measure that counts is the Core Web Vitals report in Search Console, which is based on real visitors’ experience rather than a lab test. Its figures describe “75% of page requests” over “the last 28 days” in each case. An improvement therefore takes time to show. When a fix is complete, the company can start Google’s own check: “Click Start Tracking to start a 28-day monitoring session to check for instances of this issue in your site.” If the issue does not appear during that window, Google considers it fixed. A lab test run the same day can show that a page is faster, but the field data is what confirms it for real visitors.
Separating proof from plausibility
Some results are proven by the data: a count of excluded pages fell from one number to another after a dated fix; Google’s monitoring marked an issue as fixed. Others are plausible but not proven: traffic to repaired pages rose afterwards, but other changes happened at the same time. A report should label each. That keeps the record honest and lets you see which fixes are worth repeating.
Asking for before and after figures for each fix
Ask for each technical fix to be reported with its starting number, the date of the fix, the new number, and the report it came from, and for Google’s own validation to be started where it exists. A report built this way can be checked by anyone with access to your Search Console.