Auditing workflow, tools and Search Console monitoring

0:00 Auditing workflow and monitoring

Most technical SEO disasters aren't discovered by audits. They're discovered by traffic graphs, weeks too late. A noindex left on a template. A robots.txt copied from staging. A canonical that suddenly points at the home page. In this lecture you'll learn a repeatable audit workflow, the Search Console reports that matter most in twenty twenty-six, how to read the data without fooling yourself, and how to build a lightweight monitoring layer that catches problems in days.

0:33 The audit sequence

Senior technical SEOs work from a consistent sequence, so nothing important is skipped and findings are comparable over time. Context: business goals, priority templates, recent releases, markets and stack. Access: a Search Console Domain property, Bing Webmaster Tools, analytics, logs and staging. Crawl: with JavaScript rendering where relevant, a mobile user agent, and sitemap and Search Console integrations. Indexation review by sitemap segment. Template review. Logs. Prioritise by impact, effort and confidence. Report and ticket. Then verify and monitor.

1:07 The tool stack

The tool stack, vendor-neutral. Crawling: Screaming Frog, Sitebulb, Lumar, JetOctopus or Oncrawl. Google data: Search Console's interface, API and bulk export to BigQuery. Bing data: Bing Webmaster Tools, which now includes AI citation reporting. Performance: PageSpeed Insights, CrUX, Lighthouse, DevTools and web-vitals RUM. Structured data: the Rich Results Test and Schema Markup Validator. Logs: log analysers, BigQuery or your CDN's analytics. The tool matters less than the configuration, so record your crawl settings in every audit.

1:40 Core Search Console reports

Search Console reports that matter most. Page indexing, filtered by sitemap for segment views, with Validate fix after you resolve an issue. URL Inspection, for index status, Google-selected canonical, last crawl and rendered HTML. Performance, for clicks, impressions, CTR and position by query, page, country, device and appearance. Crawl stats, hidden under Settings, for response codes, response times and host status. Plus Sitemaps, Core Web Vitals, HTTPS, Enhancements, Manual actions, Security issues, Removals and the robots.txt report.

2:13 New in Search Console

And what's new in twenty twenty-five and twenty twenty-six? A branded queries filter in Performance, which splits branded and non-branded queries using Google's own classification, rolled out to eligible properties. Query groups, for organising queries into custom categories. Custom annotations, so you can mark releases and incidents directly on charts. And the generative AI performance report, showing impressions in AI Overviews, AI Mode and AI Overviews in Discover, without clicks or queries. Use regex filters too, for example to exclude brand terms in a way you control.

2:51 Reading the data

Reading Search Console data correctly. Performance data omits anonymised queries, so query totals won't sum to page totals. Average position is an impression-weighted average, and mixing many queries hides detail, so analyse query and page pairs. Report timelines lag by a few days, and indexing reports update less often than performance data. And compare like with like: same weekday mix, and seasonality such as Ramadan, Eid, Christmas or summer holidays.

3:21 The monitoring layer

Now monitoring. Make sure the right people are verified users and receive Search Console emails. Schedule weekly crawls of key templates and compare with the previous run for new noindex, canonical, status or title changes. Monitor robots.txt and a set of critical URLs for changes. Build dashboards by page group, with release annotations. Alert on spikes of five hundreds to Googlebot, or drops in Googlebot hits, in your logs. And add an SEO check to every release that touches templates, routing or robots directives.

3:58 Hands-on: change monitor

Hands-on. The lesson text includes a small Python change monitor. It fetches a list of critical URLs, including robots.txt, records the status, X-Robots-Tag header, title, canonical and meta robots, and hashes robots.txt. It saves the state, and on the next run compares and prints every change. Run it weekly, or daily, from cron or your CI system, and send the output to email or chat. It's deliberately simple, and that's the point: it will catch the expensive mistakes.

4:32 Example 1: the forgotten subdomain

Worked example one, simple. A Liverpool e-commerce store only verified a URL-prefix property for https www. Its old blog lives on a subdomain, and nobody noticed that subdomain had thousands of spam pages injected after a plugin was compromised. A Domain property would have shown it. The fix: verify the Domain property through DNS, review Security issues, clean the subdomain, close the vulnerability, and request a review.

5:01 Example 2: the Tuesday noindex (illustrative)

Worked example two, with illustrative details. A Manchester agency runs the change monitor for a client. On a Tuesday, it reports the product template's meta robots changing from empty to noindex, nofollow. A staging flag was left on in a CMS release. The fix ships the same afternoon, before Google recrawls most products. Without monitoring, the first sign would have been a traffic drop two weeks later, and weeks more to recover.

5:32 Watch me do it: weekly change monitor

Watch me do it. I'll set up the weekly change monitor for a client in fifteen minutes. Step one: I pick ten critical URLs: robots.txt, the home page, two category pages, three product pages, the main guide, the contact page and the sitemap index. Step two: I paste them into the monitor script and run it once to create the baseline state file. Step three: I schedule it. On a small server, that's one cron line to run Monday at seven a.m. In CI, it's a scheduled workflow. Step four: I pipe the output to a chat channel the marketing and development leads both read. Step five: I test it. On staging, I ask the developer to add a noindex to one product template and run the monitor against staging. The alert appears: product robots, empty to noindex. Good. Step six: in Search Console, I check that both leads are verified users with email notifications on, and I add a custom annotation for today: monitoring started. Step seven: I add the branded queries filter to the default Performance view, so the Monday review shows non-brand trends straight away. Fifteen minutes now saves weeks of silent damage later.

6:58 Mistakes and measures

Common mistakes. Running a crawler with default settings on a JavaScript site and reporting no content. Delivering a two-hundred-row spreadsheet with no priorities. Auditing once a year instead of monitoring continuously. And only verifying a URL-prefix property, missing subdomains and protocol variants. Measure success with time to detect, which should be days, and the number of issues caught before they affected traffic.

7:25 Recap and try this now

Recap. Work from a repeatable sequence. Master the core Search Console reports, including the new branded filter, annotations and AI report. Read the data carefully. And build a monitoring layer so problems are cheap to fix. Try this now. Set up the change monitor for ten critical URLs, including robots.txt, schedule it weekly, and send its output somewhere your team actually reads.