Ask ten SEO practitioners for their tool stack and you get ten lists of brands. Ask what each tool is actually for, and where its numbers come from, and the answers get vaguer. That second question is the one that matters. A tool is a measuring instrument with a known error. If you do not know the error, you cannot trust the reading.
I organise my stack by the question each category answers, not by vendor. Brands change pricing, get acquired and add features monthly; the categories and their limits have been stable for years. What follows is what I use each for and which outputs I refuse to treat as fact.
The principle: first-party data beats estimates
Every SEO tool sits somewhere on a spectrum from "this is what happened" to "this is what we estimate happened". Search Console and your own server logs are at the first end: they record real events on your property. Third-party keyword volumes, traffic estimates and authority scores are at the other end: they are models built from samples and clickstream panels. Both are useful. Confusing one for the other is how bad decisions get made with confidence.
- Server logs
- Search Console
- Analytics
- Your own crawl
- Third-party estimates
That ordering is how I weight a disagreement. If a rank tracker says position three and Search Console says average position eleven, Search Console wins, because it reports what Google actually served. If a keyword tool says zero volume and Search Console shows impressions, the impressions are real.
Crawlers
A crawler fetches your site the way a search engine would and reports what it finds: status codes, canonicals, titles, headings, internal links, directives, structured data, page depth. It is the single most important tool category for technical work, and the one most people use most shallowly.
What I use a crawler for: finding what is linked but should not be (redirect chains, 404s, parameter URLs), finding what should be linked but is not (orphans, deep pages), checking that directives and canonicals say what the CMS thinks they say, comparing raw HTML against rendered HTML (the JavaScript SEO guide explains why that diff matters), and building the internal-link graph that feeds the internal linking framework.
What a crawler cannot tell you: whether Google has actually crawled, indexed or ranked any of it. A crawl is a model of what could happen, not a record of what did, which is why I pair it with Search Console coverage and, where possible, logs. The orphan pages experiment exists because the crawl and the index disagreed in ways only logs could explain.
Log file analysers
Server logs are the only source of truth for what search engines actually request; everything else, including Search Console's crawl stats, is a summary. A log analyser parses the access logs, verifies which requests are genuinely from Googlebot, and shows which URLs it hit, how often, and with what response.
I use logs for three things: crawl budget on large sites (what is Googlebot wasting requests on), discovering orphan URLs that Google keeps crawling even though nothing links to them, and verifying that a fix actually changed crawler behaviour. Logs are also the fastest way to spot an accidental block, because the bot's requests simply stop.
The caveat is access. Many Indian companies run on hosting or CDNs where raw logs need a vendor conversation and may be short-lived. Seven days is still more real than any estimate; I wrote more on this in the note on technical SEO at scale.
Rank and visibility trackers
A rank tracker runs a fixed set of queries from a fixed location and device on a schedule and records where your URLs appear. It is useful for watching movement on a defined set of queries over time, for competitive comparison on those queries, and for catching a sudden drop on a page type after a release.
What I do not trust: the absolute position on any single day. Results are personalised, localised and interleaved with AI Overviews, shopping blocks and local packs, so "position four" means different things on different days. I look at trends across groups of queries, never one query on one day, and I set the location to the market being targeted; a tracker defaulting to the US is worthless for a Pune business, as the international SEO guide repeats.
Rankings are an intermediate signal; the note on why rankings are not the goal explains why I never report them alone.
Keyword research tools
Keyword tools provide query ideas, estimated search volume, estimated difficulty and sometimes SERP features and intent labels. The ideas are the valuable part. The numbers are the part to be careful with.
Search volume estimates come from advertiser data, clickstream panels and modelling. They are useful for comparing queries against each other and close to meaningless as absolute figures, particularly for Indian regional languages, Hinglish and long-tail B2B terms, where samples are tiny. Difficulty scores are mostly a function of backlinks to the ranking pages, one input among many. I use them as a rough sort, then look at the actual SERP.
My process, described in the keyword research guide, uses the tool for discovery and clustering, Search Console for what already gets impressions, and manual SERP review for intent. The tool's volume column is the last thing I look at, not the first.
Search Console and GA4
These two are the first-party backbone and they answer different questions.
Search Console
It tells you what Google showed and what people clicked: queries, pages, countries, devices, with impressions, clicks, CTR and average position. It tells you which URLs are indexed and why others are not. It covers crawl requests, real-user Core Web Vitals, structured data errors and manual actions. It is the most important free tool in the discipline and most teams use a fraction of it.
Its limits: the query report is filtered for privacy, so the long tail is hidden; average position includes every impression, even at position fifty; data lags; and AI Overview performance is blended in, as I covered in the AI SEO guide. For serious work I export daily through the API into a database, because the interface keeps sixteen months and loses granularity.
GA4
Analytics tells you what people did after they arrived: landing pages, engagement, conversions, revenue, paths. It is where SEO connects to business outcomes. It is also an event-based system that needs to be configured with intent; a default GA4 property measures almost nothing useful for SEO until conversions and channel groupings are defined properly.
Its limits: consent and ad-blockers mean many sessions are never recorded, attribution models change what "organic" gets credit for, and thresholding hides small segments. I treat GA4 as a consistent undercount: good for trends, not a census.
Page speed and Core Web Vitals tools
There are two kinds of speed data and they are often confused. Lab tools run a synthetic test under fixed conditions and give you a diagnostic breakdown: what loads, when, and what is blocking. Field data comes from real users' browsers and is what Core Web Vitals are actually assessed on.
I use lab tools to diagnose and field data to judge. A lab score of 95 on a developer's fibre connection means nothing for a user on a mid-range Android phone on 4G in a tier-2 Indian city, which is the median visitor for many sites I work on. The Core Web Vitals guide covers LCP, INP and CLS; the caveat is that the number to report is the field number, by device, and the lab number is for the engineer fixing it.
Schema and structured data validators
Validators check whether structured data parses and meets the requirements for a specific rich result. They are reliable for syntax and required properties. They say nothing about whether Google will show the rich result, which depends on eligibility, page quality and Google's discretion; my schema markup experiment is about that gap.
The caveat I repeat most: "valid" is not "effective". Marking up content that is not visible on the page passes validation and achieves nothing or worse. Structured data describes what is there; it does not create it.
Spreadsheets, scripts and automation
The most used tool in my stack is a spreadsheet, and the second is a small collection of scripts. Every tool above exports data; the real work is joining those exports. Crawl data joined to Search Console data joined to log data, by URL, is the view none of the tools provide on their own and the one that answers most audit questions.
Scripts handle what must be repeated: pulling Search Console through the API daily, scheduled crawls diffed against the last one, hreflang or internal-link suggestions generated from a database, URL status checks after a release. None of it is sophisticated. It is the difference between an audit that happens once and a system that catches regressions, which is the argument of the implementation problem note.
Two small tools of my own sit in this category. The SERP snippet preview shows how a title and description will truncate on mobile and desktop. The robots.txt tester checks a URL against a robots file for a specific user agent; I run it before every robots change because precedence logic is easy to get wrong by hand.
AI assistants in the workflow
Language models are now part of how I work, and the honest description of where they help is narrower than the marketing suggests.
Where they are genuinely useful: writing and debugging the scripts above, clustering keyword exports by intent as a first pass, drafting regex and XPath for crawler extraction, summarising crawl errors into patterns, and turning a content brief into a first-draft outline.
Where I do not trust them: any claim about how Google works that I cannot verify from documentation or a test; any search volume, ranking or competitor number they produce (they will invent one if asked); and finished content without a practitioner rewriting it. A model reproduces the consensus fluently, and the consensus is what every competitor is also publishing.
Task to tool category, with the caveat
| Task | Tool category | Caveat |
|---|---|---|
| Find crawl errors, redirect chains, canonical conflicts | Crawler | Shows what could be crawled, not what Google did; crawl with and without rendering |
| See what Googlebot actually requests | Log analyser | Needs raw server logs; verify bot IPs; even a week of data is useful |
| Find which pages are indexed and why others are not | Search Console | Coverage states lag; use the URL inspection API for specifics |
| Discover queries and estimate demand | Keyword tool plus Search Console | Volumes are estimates, weakest for Indian languages and long tail; trust impressions over tool volume |
| Track movement on target queries | Rank tracker | Watch trends across query groups; set location to the target market; never report a single day |
| Measure business outcomes from organic | GA4 with configured conversions | Consistent undercount due to consent and blockers; attribution model affects credit |
| Diagnose slow pages | Lab speed tool | Diagnostic only; report field Core Web Vitals by device instead |
| Check structured data | Schema validator | Valid is not eligible; markup must match visible content |
| Join crawl, index and log data by URL | Spreadsheet or script | Needs consistent URL normalisation; this is where the real findings are |
| Preview how a title will truncate | Snippet preview tool | Google rewrites titles when it wants to; preview is a guide |
| Verify a robots.txt rule before deploying | Robots tester | Test each relevant user agent separately; precedence rules differ by bot |
| Cluster keywords, draft scripts, outline content | AI assistant | Verify any fact or number; never publish unedited output |
How I choose and when I stop
The stack for a project is decided by the questions it needs answered, which come from the SEO strategy framework. A ten-page consultancy site needs Search Console, a free crawler and a spreadsheet. A marketplace with a million URLs needs logs, a scheduled crawl, a database and scripts. Paying for every category on every project is the most common waste I see.
The other discipline is knowing when to stop looking at dashboards. A finding only matters if someone implements the fix, and the ratio of findings to fixes on most SEO programmes is the actual problem. If tool output is not turning into changes on the site, the stack is a distraction, however good it is.
Know where every number comes from. If you cannot say how a tool measured something, you cannot say how wrong it might be.
Frequently asked questions
Which SEO tools are essential for a small business?
Search Console, properly configured analytics, and a crawler, which can be a free one for a small site. That answers most questions a small business has. Keyword tools and rank trackers are useful but secondary, and their numbers should be treated as estimates. A spreadsheet to join the exports is the fourth essential.
Why do keyword tool volumes differ so much from Search Console impressions?
Tool volumes are modelled from advertiser data and clickstream samples; impressions are a record of real searches where your page appeared. They measure different things with different methods. Where they disagree, impressions are real. The gap is largest for Indian regional languages, Hinglish and specific B2B terms, where tool samples are tiny.
Are rank trackers still accurate with AI Overviews and personalisation?
They are accurate about what they measured: one query, one location, one device, one moment. That is less representative than it used to be because results vary more. Use them for trends across groups of queries over weeks, set the location to the market you target, and compare with Search Console's average position rather than relying on either alone.
Do I need server logs, or is Search Console's crawl stats report enough?
Crawl stats is a useful summary. Logs are the actual record and show per-URL crawler behaviour, which is what you need to find wasted crawl budget, orphan URLs that Google keeps fetching, and whether a fix changed anything. For sites with more than a few thousand URLs, I consider logs necessary.
Can AI tools replace an SEO consultant?
They replace parts of the work: scripting, clustering, first drafts, summarising error logs. They do not replace judgement about which problems matter, verification of claims against real data, or getting changes implemented. They also invent facts and numbers when asked, so their output needs a practitioner checking it.
What do you use your own tools for?
The SERP snippet preview shows how a title and description truncate on mobile and desktop before I commit to them. The robots.txt tester checks a specific URL against a robots file for a specific user agent, which I run before every robots change because precedence rules are easy to get wrong manually. Both are small, single-purpose and free.
Where this connects
Most of these tools exist to serve technical diagnosis, which is laid out in the technical SEO guide; which tools a project needs is decided in the SEO Strategy Framework. The orphan pages experiment is a worked example of what happens when crawl, index and log data are joined rather than read separately, and the technical SEO and content architecture case study shows that approach applied to a whole site. If you want the measurement set up and the findings turned into fixes, that is the job of my SEO audit service. This guide sits at Level 07 of the SEO Roadmap.