How to decide what technical SEO metrics to measure and report

Choose evidence for the situation

These cases show why measurement choices depend on site needs, rather than on whichever tool a team happens to buy.

A 200-page site and a two-million-page site share little beyond SEO terminology. The table is deliberately broad: an enterprise crawler for a 400-page brochure site may amount to a spreadsheet with extra steps.

Small sites

For a site with under 1,000 URLs, combine Search Console performance and coverage reports with manual spot checks and server log sampling. Enterprise crawlers with six-figure licence fees and log analysis suites are listed as avoidances, rather than default requirements for this smaller case.

Large sites

For a site with over 100,000 URLs, log file analysis, crawl budget reporting and segmented Search Console data via API suit the scale. Avoid a single blended average for the whole domain, since that can conceal differences between sections and make the reported picture less useful.

Migration periods

Before migration, use before-and-after URL mapping, index coverage tracking and redirect error monitoring; rankings alone can miss structural damage. After migration, follow the index coverage recovery curve, crawl error rates and Core Web Vitals by template. Traffic totals from the first 48 hours are too noisy to interpret.

Content and commerce

A content-led site can track query-level impressions, click-through rate and cannibalisation checks, rather than using domain-level authority scores as a primary measure. Ecommerce measurement can focus on category and product template performance, faceted URL indexation and revenue per session, not site-wide average position.

Decide what a measure should change

Start by naming the decision a metric could influence. Teams that connect a crawler and analytics property, then chart whatever appears, can end up with a dashboard that answers questions nobody asked.

If a change in the number would lead to no action, the measure is decoration rather than useful evidence.

For example, a migration risk score can change a release date, a crawl waste figure can prompt a robots.txt rule change, and a Core Web Vitals pass rate can alter a front-end sprint. The GOV.UK service manual, Measuring the success of your service, recommends defining user success before collecting data, rather than reporting whatever a tool outputs.

Applied to SEO, that means user success is finding the right page and completing a task. Search visibility is not the ultimate goal, but one input. A defensible metric should be defined in writing, have one source of truth and a known refresh cadence, and include a threshold that prompts action.

For index coverage, define the measure as the number of URLs Google reports as indexed for a given property. Search Console is its source and weekly is its cadence. A drop greater than 5% week on week can trigger an investigation, rather than being treated automatically as a crisis.

A site falling from 40,000 indexed URLs to 37,500 in one week has crossed that trigger, so the response is diagnostic. By contrast, a crawler vendor's site health score can change when its rules change and has no user-facing meaning. It can help SEO-team triage, but should not appear in a board report.

Keep Google-reported figures separate from site-level crawl and server-log measures, because their sources answer different questions. Decide which evidence supports each decision before adding a metric to a report. Give each measure one named owner and an agreed source; conflicting numbers damage trust faster than missing numbers.

Assemble the evidence chain

A measurement stack has three parts: collection, storage and presentation. Teams often spend too much effort on presentation and too little on the first two, then face figures that disagree. Collection begins by choosing authoritative sources, each of which has its own bias and answers a different question.

Search Console supplies query and indexing data, server logs show crawl behaviour, rendering tools show what Google sees, and field data sources report real-user Core Web Vitals. Lab and field data answer different questions, so display them in separate charts rather than blending them into one score.

Storage is where dates, URL formats and device categories are normalised. Trailing slashes and http versus https variants can cause reporting problems; resolve them at this layer so that downstream charts are consistent. Presentation is straightforward when collection and storage are sound, but conflicting spreadsheets create ongoing maintenance work.

A working set of technical measures

Use Google Search Console for Google's view of search and indexing, and a crawler for page-level checks. Screaming Frog SEO Spider and Sitebulb are crawler options. Lighthouse and PageSpeed Insights support lab checks; PageSpeed Insights can also show Chrome UX Report (CrUX) field data when available. Keep Lighthouse lab results separate from CrUX field results.

For every metric, set an owner, source, cadence and action. Read field Core Web Vitals against their 28-day rolling window, and use published thresholds where they exist.

Do not invent a universal threshold for every crawl issue. Google's Search Console documentation is the starting point for its Performance, Page Indexing, Core Web Vitals and Crawl Stats reports, plus Enhancements and Sitemaps where available.

Google reports that its API can return up to 50,000 rows per request, making sampling decisions important early. Search Console data is sampled in some views, so large sites pulling query data need pagination and a stated date window. Log files are complete only when every request is captured, which many CDNs do not do by default.

Set reporting to the pace of decisions

Engineering teams need weekly views of crawl errors and Core Web Vitals regressions, because those issues can be fixed in a sprint.

Marketing leadership needs monthly reporting tied to organic sessions and conversions. The board needs a quarterly view connected to revenue and risk, with the cadence matched to when someone can act.

A single metric can appear at every level, but its framing changes with the audience. For engineering, a CLS regression can become a bug ticket; for marketing, a user experience risk; and for the board, a commercial risk if it affects a high-revenue template.

CLS thresholds from web.dev provide a shared standard: 0.1 or below is good, and above 0.25 is poor. These thresholds allow a pass-or-fail report instead of a vague score. For a worked example of a live view, see this technical SEO reporting dashboard, which covers layout and data plumbing.

Record limits and consent alongside results

Every source has limits, and stating them demonstrates competence rather than weakness. Core Web Vitals field data uses a 28-day rolling window, so a fix deployed today will not appear in the numbers immediately.

Put sampling limits, date windows and other caveats in a methodology note instead of repeating them beside every figure.

The ICO's guidance on online tracking says analytics cookies and similar technologies are subject to consent requirements, unless a valid exemption applies. Consent rates therefore affect the size and shape of a measurement dataset. Record the lawful basis for analytics as part of the plan, not as an afterthought.

If only 60% of visitors accept analytics cookies, session counts are a biased sample, not a census. A reported 10% traffic fall alongside a change in consent rates is a classic, avoidable error. Show consent rate on the same dashboard as traffic, so readers can judge whether the comparison remains meaningful.

The Data Protection Act 2018 is the primary UK legislation here, alongside the UK GDPR. For cookies and similar technologies, cite the Privacy and Electronic Communications Regulations 2003 (PECR), regulation 6, which governs storing or accessing information on a user's device.

PECR's strictly necessary exception is limited to activity needed to provide a service the user requested. Do not assume analytics qualifies; check the ICO's current guidance for any other applicable exemption. Keep a record of the lawful basis for each analytics tool, do not load non-essential tracking before consent, and make withdrawal as easy as acceptance.

Segment by consent status where the tool allows it, and compare like with like, such as months with similar consent rates. If consent rates have shifted, report the change explicitly rather than burying it. Asymmetric consent banners attract regulatory attention and distort data. Cite the ICO guidance and the Data Protection Act 2018 in the methodology note or appendix.

Keep comparisons meaningful

A figure on its own says little; comparison with last month, a benchmark or a control group adds context. For year-on-year reporting, hold the methodology constant.

If the analytics vendor changed in March, annotate the chart because it now reflects the vendor change as well as SEO work, and report a bridged series where possible.

For comparisons between teams, agree definitions before discussion begins. Write down what counts as an indexed page and what counts as a crawl error, then place each definition beside its chart. Public benchmarks are harder to use because much of the available data is modelled rather than observed.

A structured approach to technical SEO benchmark research helps distinguish observed data from estimates, which matters when a benchmark is used to justify budget. Attribution is another challenge: organic search rarely gets sole credit for a conversion, and the chosen model changes the account of its value.

A guide to technical SEO attribution methods describes common models and their trade-offs, which can help when marketing and finance disagree about the value of a fix. When assessing tools, compare the metrics they support rather than feature lists; SEO tool reviews and comparison provides a method that requires each tool to justify itself against a measurement question.

Resolve common reporting decisions

There is no single authoritative source for every SEO measure. Search Console is authoritative for Google's view of indexing and queries, server logs for crawl behaviour, and field data for real-user experience. Name the source beside each figure so disagreements can be resolved by checking its definition.

Consent requirements make measurement incomplete, not unreliable, when consent rates are reported alongside traffic. A stable consent rate with a traffic change is a real signal. If a traffic change follows a consent-rate change, it may be a measurement artefact; stating that distinction protects credibility.

A methodology note should include definitions, sources, date windows, known sampling limits, consent basis and methodology changes during the reporting period. One page is enough. It lets a new stakeholder understand exactly what a reported number represents and what it does not.

The right reporting frequency depends on how quickly someone can act: weekly for engineering measures such as crawl errors and Core Web Vitals, monthly for marketing measures such as organic sessions and conversions, and quarterly for board reporting.