Technical SEO key metrics and where each source's data comes from

What to take away

Own the server first

Crawl data from your own infrastructure is the cheapest reliable metric you have. Response codes, redirect chains, server response time and crawl frequency all sit in access logs you already store. No vendor licence is required.

A team running a 40,000-page retail site can count 404 responses per week from the log file alone. That figure is reproducible and dated. Compare it with a crawler tool's estimate and you will often find a gap, because the crawler samples a subset of URLS.

Log analysis also shows which sections search engines fetch. If a directory of 8,000 filter URLS attracts no crawler requests in a month, that is a finding, not a hunch.

First-party analytics limits

Analytics platforms count sessions, engagement time and conversions, but consent choices shape those totals. Non-essential cookies need consent, so some visitors never appear in your session count, as the ICO's online tracking guidance sets out.

Treat analytics as a directional measure of behaviour, not a census. Report the consent rate next to the traffic figure so readers understand the gap. A 70% consent rate on 100,000 monthly sessions leaves roughly 30,000 visits invisible, and that is an illustrative example, not a benchmark.

For a fuller treatment of how these sources fit together, the technical SEO measurement and reporting guide sets out the reporting cycle around them.

Search Console and field data

Search Console supplies impressions, clicks, average position and indexing status directly from Google. It is a first-party source for a third-party system. That makes it unusually trustworthy for indexing questions.

Field performance data is different. Core Web Vitals field scores come from real user measurements aggregated by Google, not from your own testing. INP is the responsiveness metric to watch, and its thresholds are defined in the web.dev INP guidance. Lab tools such as Lighthouse measure a simulated load, so keep the two apart.

Rendering and crawl signals

For JavaScript-heavy sites, indexing depends on how Google renders the page. Dynamic rendering, where a server serves a prerendered version to crawlers, is documented as a workaround rather than a long-term answer in Google's dynamic rendering guidance.

Track rendered HTML coverage: the share of indexable URLS whose rendered content matches what users see. Pair it with crawl budget figures from logs, so a rendering failure shows up as a drop in fetched URLS.

Vendor dashboards and scoring

Third-party audit tools add value through scoring, prioritisation and historical tracking. Their weakness is that scores are proprietary. A 78 out of 100 in one platform means nothing in another.

Use vendor metrics for trend lines within a single tool, never as an absolute grade. Record the tool name, version and crawl date beside every score. The technical SEO benchmark research in England explains why method matters more than the headline figure.

Glossary

Common questions

Why do crawl tool counts differ from my log files?

Crawlers sample URLS and obey rate limits, while logs record every request including bots. Treat logs as the fuller record and tool counts as a structured subset.

Can I report Core Web Vitals without Search Console?

You can use the public CrUX dataset or your own real user monitoring, but both measure different populations. State which one you used and the collection window.

How often should metrics be refreshed?

Match the cadence to the metric. Log errors weekly, indexing monthly, and field performance over a 28-day rolling window so one slow day does not distort the picture.