SEO Tools I Actually Use (And What Each One Is For)

Type “SEO tools” into Google and you get the same recycled listicle fifty times, ranked by whoever paid the most for backlinks to their comparison page. I’ve settled on seven tools that earn a permanent spot in my workflow, and each one does a specific job the others can’t replace. This isn’t a “50 best SEO tools” roundup.

I’ve used most of the well-known platforms at some point across iGaming, SaaS, and Fintech projects, and dropped most of them again once the trial ended. What’s left is the stuff I still open every week, plus one category almost nobody outside technical SEO ever touches.

This post covers what each tool actually does, where it overlaps with another one on this list, the one tool most sites never install even though it answers questions nothing else can, and roughly how my own week actually splits across all six.

What “SEO Tools” Actually Means Once You Filter Out the Noise

Most “SEO tools” content bundles together four completely different jobs: crawling your own site, tracking rankings, researching keywords, and auditing backlinks. Treating them as one category is why so many people buy an expensive all-in-one platform and then only ever open two of its twelve modules.

The real question isn’t “which tool is best,” it’s “which job am I actually trying to do right now.” A rank tracker won’t tell you why Googlebot can’t render your JavaScript. A backlink checker won’t tell you your XML sitemap has 4,000 non-canonical URLs in it.

I group my own stack into four jobs: crawling and technical health, keyword and content research, off-page and competitive data, and monitoring after the work ships. Each section below maps to one of those, in roughly the order I’d reach for them on a brand-new project.

I’ve seen this play out the same way more than once on international iGaming and Fintech sites: an all-in-one platform is already running, its rank-tracking graph is the only screen anyone actually opens, and its own crawl module sits unused because nobody scheduled it. A subscription doesn’t audit a site by existing – someone still has to point the crawler at it and read what comes back, and that’s usually the step that quietly never happens.

Google Search Console: Free, Official, and Not Optional

If I could only keep one tool, it’s Search Console. It’s the only source that shows what Google itself actually indexed, actually crawled, and actually served in search results, because Google’s own documentation on the URL Inspection tool confirms it reflects “the most recently indexed version of a page,” pulled straight from Google’s index rather than a simulated crawl.

That distinction matters more than people think. A lot of practitioners still check whether a page is indexed with a manual “site:” search, glance at the result count, and move on. The URL Inspection tool is the only reliable way to check one specific URL’s actual indexing status, because a manual search operator can under- or over-report results depending on personalization and caching, while URL Inspection queries Google’s index directly for that exact URL.

I pull three reports from Search Console every week without exception: the Indexing report, Performance, and Core Web Vitals. I’ve written before about what actually moves rankings in Core Web Vitals, and Search Console’s own field-data report is the same CrUX dataset that feeds that page’s scoring, not a lab simulation.

On multi-market sites, the Performance report’s country filter is where I actually spend most of my time, not the aggregate totals. A site can look healthy overall while one specific market’s click-through rate is quietly collapsing because a competitor just outranked it on a market-specific term, and the global average hides that completely.

The one thing Search Console won’t do is crawl your site the way Google does and hand you a prioritized list of problems to fix today. For that, I open a second tool before I open anything else.

Screaming Frog: Crawling and Technical Audits

Screaming Frog SEO Spider is the tool I run first on any new site, before I even look at Search Console. It crawls your site the way a search engine bot would, and it surfaces exactly what’s broken: redirect chains, missing canonicals, duplicate title tags, orphaned pages, broken internal links.

A full crawl on a mid-sized site takes me under ten minutes and routinely finds problems Search Console never flags, because Search Console only reports on URLs Google has already decided to look at, while Screaming Frog will crawl every URL it can reach regardless of whether Google ever bothered.

The setting I change on almost every crawl is JavaScript rendering mode, since a plain HTML crawl on a React or Vue front end will report a site as empty when Googlebot itself renders it fine. I also set up custom extraction for whatever schema type a site is supposed to be using, so I can see in one export exactly which pages are missing it, rather than checking pages one at a time.

I covered a lot of what this actually catches in my technical SEO breakdown of crawling, indexing, and site health – redirect chains, canonical conflicts, robots.txt blocks. Screaming Frog is the tool that turns those concepts into an actual checklist of URLs to fix, not an abstract topic.

The crawl depth report is the other tab I check before anything else, since it shows how many clicks a page sits from the homepage, and a page buried five or six clicks deep is a page Googlebot is statistically less likely to bother crawling often, regardless of how good the content on it actually is. Fixing that is usually a navigation or internal linking change, not a content change.

Where it falls short: it’s a simulated crawl, running from one machine, on a schedule you control. It tells you what’s crawlable in theory. It says nothing about what Googlebot is actually doing on your live server, on its own schedule, at its own pace. That gap is exactly what the next tool closes.

Log File Analysis: The Tool Almost Nobody Runs

This is the one category missing from almost every “best SEO tools” list, and it’s the one I’d argue is most underused relative to how much it reveals. A log file analyzer (I use Screaming Frog’s Log File Analyser specifically) reads your raw server access logs and shows you exactly which URLs Googlebot requested, when, how often, and what status code it got back.

A Holistic SEO article on log file analysis makes the distinction precisely: simulated crawling tools show you what a site’s structure allows, while server logs show you what search engine bots actually did, because that tracking happens at the server level, not through a script that can be blocked or filtered the way JavaScript-based analytics can.

In practice, this is how I catch crawl budget being wasted on parameter-heavy URLs, faceted navigation combinations, or old redirect targets that Googlebot keeps hitting years after a migration. Search Console’s crawl stats report gives you an aggregate count of total requests. Log files give you the actual URL list behind that number, which is the difference between knowing there’s a problem and knowing exactly which template is causing it.

I don’t run this constantly – it’s a periodic deep-dive, not a weekly checklist item. On a site over roughly 10,000 pages, I’ll pull three to six months of logs once a quarter and look specifically for bot activity on URL patterns that shouldn’t be getting crawled at all: session IDs, sort parameters, or a legacy folder structure from before a migration two years ago that Googlebot apparently never forgot about.

RankMath: Where the Strategy Actually Gets Implemented

Everything above is diagnostic. RankMath (or Yoast, depending on the site) is where fixes actually get implemented on a WordPress site, which is why I don’t treat it as optional tooling even though it’s “just a plugin.”

I’ve laid out the actual tradeoffs between RankMath and Yoast as WordPress SEO plugins in detail elsewhere, so I won’t repeat the comparison here. What matters for this list is narrower: a plugin like this is the only practical way to manage titles, meta descriptions, redirects, and schema at scale without editing template files for every single post.

The schema piece deserves its own mention. I’ve written separately about how to actually implement structured data on a page, and a plugin’s schema generator is genuinely useful there, but it’s not a substitute for understanding which schema type actually applies to a given page. I still see sites auto-generating Article schema on category pages because the plugin defaulted to it and nobody changed the setting.

The redirect manager is the other feature I use constantly and rarely see mentioned. Every time Screaming Frog’s crawl turns up a broken internal link or an old URL still getting hits in the log files, the fix happens in the same plugin panel, without needing server-level access or a developer to touch .htaccess.

PageSpeed Insights: Reading Lab Data Correctly

PageSpeed Insights sits in an odd spot because most people misread what it’s showing them. The top score is a lab test, run once, on Google’s own simulated conditions. The field data section underneath, when it’s available, is real Chrome User Experience Report data from actual visitors.

I treat the lab score as a diagnostic checklist and the field data as the actual grade that matters for rankings, since that field data is the same CrUX-based dataset Search Console’s own Core Web Vitals report pulls from. A site can score 45 in the lab test and still pass Core Web Vitals in the field if real users on decent connections load it fine.

The reverse happens just as often – a site that scores well in the lab but gets hammered by real-world mobile connections on slower networks.

What I actually read first is the three individual metrics, not the composite score: Largest Contentful Paint for loading speed, Interaction to Next Paint for responsiveness, and Cumulative Layout Shift for visual stability. A page can fail on just one of these while passing the other two, and the fix for each is completely different – LCP usually means a slow server response or an unoptimized hero image, while CLS almost always means an ad slot or web font loading without a reserved space.

This is really the same dataset from two different windows, not two competing tools. I open Search Console for the trend over time across a whole site, and PageSpeed Insights when I need to diagnose one specific URL right now and see exactly which resource is blocking rendering.

Google Analytics 4: Where It Fits (and Where It Doesn’t)

GA4 doesn’t replace Search Console, and treating them as interchangeable is a mistake I still see constantly, usually from teams that assume “we have analytics covered” means SEO reporting is already solved. Search Console tells you how Google sees your site: what’s indexed, what ranks, what gets clicked. GA4 tells you what a visitor did after they landed.

The clearest practical difference is attribution: Search Console will tell you a page ranked position 4 for a keyword and got 200 clicks; GA4 will tell you what those 200 people did next – bounced immediately, converted, or browsed three more pages before leaving. Neither number replaces the other, and pulling only one usually means missing half the real story about whether a ranking is actually worth anything to the business.

I use GA4 for one thing specifically on SEO work: segmenting organic-channel sessions by landing page, to see which pages that rank well also convert, versus which ones rank well and go nowhere. A page in that second category usually isn’t a technical SEO problem at all – it’s a content or conversion problem that happens to be wearing a good ranking as a disguise, and no crawler or rank tracker will ever surface that distinction.

Ahrefs: Backlinks, Rankings, and Keyword Data

Ahrefs is the one paid, all-in-one platform I keep, mainly for backlink data and competitive keyword research, because building that index requires crawling the entire web continuously, which isn’t something a single-site crawler like Screaming Frog is built to do.

One caveat worth being upfront about: no third-party tool’s search volume or keyword difficulty number is a precise measurement, it’s a modeled estimate, built from clickstream and ranking data rather than Google’s actual query logs, which only Google itself has. I use these numbers to compare keywords against each other, not as an exact forecast of traffic.

The backlink index is the part I trust more directly, because a link either exists on a crawled page or it doesn’t – there’s less room for a modeling assumption to distort the number the way there is with estimated search volume. I use the Content Gap report mostly for competitor comparison work: which domains link to three competitors and not to the site I’m working on, which is a faster starting point than building an outreach list from nothing.

On international projects specifically, I filter Site Explorer by country before drawing any conclusion, since a competitor’s overall backlink count means very little if almost none of it comes from the specific market I’m actually trying to compete in.

Keyword research follows a similar filtering habit. I pull the initial keyword list from Ahrefs, but I cross-check the shortlist against actual Search Console query data before committing to any of it, because Search Console shows queries the site is already getting real impressions for, including long-tail phrasing no keyword tool ever surfaces on its own. The tool generates the wide net; Search Console tells me which parts of it are already working.

The Tools I Stopped Using

I dropped two categories of tool entirely over the last few years: standalone rank trackers and generic “SEO score” checkers that grade a page out of 100 based on surface-level factors like keyword density in headings.

Rank position on its own, without click and impression context, tells you almost nothing actionable – Search Console gives me that same ranking data alongside the click-through rate it actually produced, for free, which is the number that actually pays the bills. And a 100-point score from a generic checker measures conformity to a template, not whether the page actually deserves to rank, which is the same trap I’ve argued against in my breakdown of the on-page elements that actually move rankings.

A high score from one of these checkers mostly confirms that keyword placement and meta tag length look correct – it says nothing about how competitive the actual top-ten results are for that query. A page can pass every item on a generic checklist and still lose on content depth against ten competitors that go further into the topic, and no automated score is built to catch that particular gap.

A Realistic Weekly Workflow

None of this matters if it just sits as a list of tool names, so here’s roughly how a normal week actually splits across the six: Search Console gets checked two or three times, quick five-minute passes rather than a deep session. Screaming Frog runs a full crawl once a week on an active project, or immediately after any deploy that touched templates.

The log file analyzer only comes out during a quarterly technical review, or the moment something in Search Console’s crawl stats looks off and I need to know exactly which URLs are behind the spike. RankMath gets opened per-page, as content ships, not on a schedule. PageSpeed Insights gets used reactively, whenever a specific page’s Core Web Vitals report flags a problem worth diagnosing individually, and GA4 gets a monthly pass specifically for the ranks-well-but-doesn’t-convert segmentation, since that pattern rarely shifts meaningfully week to week.

Ahrefs is the one true weekly-session tool – I block out time for competitive and keyword research rather than checking it reactively, because that kind of research needs uninterrupted focus, not five minutes between other tasks. None of these seven runs on the same schedule, and forcing them onto one calendar is how half of them end up ignored.

Which Tool for Which Job

Here’s the same seven tools mapped against the job I actually reach for them to do, since the job you’re trying to do decides the tool, not the other way around:

Tool	Primary job	Cost
Google Search Console	Official indexing, ranking, and Core Web Vitals data	Free
Screaming Frog SEO Spider	Simulated crawl and technical audit	Free up to 500 URLs, paid beyond that
Screaming Frog Log File Analyser	Real Googlebot behavior from server logs	Free up to 1,000 log lines/month, paid beyond that
RankMath	On-page implementation: titles, redirects, schema	Free tier, paid Pro tier
PageSpeed Insights	Per-URL speed diagnosis, lab and field data	Free
Google Analytics 4	Post-click behavior on organic landing pages	Free
Ahrefs	Backlink index and competitive keyword research	Paid

If you’re starting from zero and budget is the constraint, here’s the actual order I’d install these in:

• Google Search Console first, always, no exceptions – it’s free and it’s the ground truth for indexing and rankings.
• Screaming Frog’s free tier next, for a first technical crawl of anything under 500 URLs.
• PageSpeed Insights whenever a specific page feels slow, no installation needed.
• RankMath (or Yoast) if the site runs on WordPress, before you touch anything paid.
• GA4 once there’s actual organic traffic worth segmenting by landing page, not before.
• A paid platform like Ahrefs only once you actually need competitive backlink or keyword data, not on day one.
• A log file analyzer once the site is large enough, roughly five figures of URLs, that crawl budget becomes a real question worth investigating.

My Actual Take

If I’m honest about it, four of these seven are genuinely optional depending on the size of the site: Ahrefs, the log file analyzer, GA4’s SEO-specific segmentation work, and arguably RankMath’s Pro tier if the free version already covers what a smaller site needs. Search Console, Screaming Frog, and PageSpeed Insights are not optional for me on any project, regardless of budget.

The mistake I see most often isn’t picking the wrong tool, it’s assuming one all-in-one platform will replace the other five. It won’t, because crawling your own site, reading Google’s actual index data, and reading raw server logs are three fundamentally different data sources, not three views of the same one. The best SEO tools stack I’ve found is the smallest one that still covers all four jobs from the start of this post – not the biggest subscription I can justify to myself.