The version of this post that used to sit here recommended a stack costing about $45 a month and told you to rent an enterprise suite for one month a quarter. I have never paid for a single one of those tools. That is the whole reason this page got rewritten from scratch: I was handing out opinions about software I had not opened, which is a fast way to be confidently wrong in public.
So here is the smaller, duller, true version. Five things, all free, that I open in a normal week of running two blogs, an agency site and a small SaaS. Three of them are Google’s. The other two are the WordPress REST API and a command-line tool that nobody markets as SEO software, and the command-line tool is the one that has found the most real problems on my own sites.
Search Console: two screens, not twelve
Search Console is the only tool in this list that reports what Google actually did with your pages rather than what some crawler thinks it should have done. It is also the one people bounce off, because the interface has about fifteen reports and only two of them matter most weeks.
The first is the performance report, filtered to the last 28 days and sorted by queries. On a site my size the click numbers are too small to draw conclusions from, and I try to say that out loud rather than dress up noise as a trend. What the query list is genuinely good for is finding the gap between what I wrote about and what people typed. The second is URL inspection: paste a URL, see whether Google has it, when it last crawled it, and which canonical it decided on. That last field has caught more of my mistakes than anything else, because the canonical Google picks is not always the one you declared.
Everything else in there I open when something specific breaks. The sitemap section in particular has a habit of remembering files you deleted years ago, which is its own small saga. I go through the parts that repay attention in the guide to the Search Console screens that actually matter.
PageSpeed Insights, and the 429 that taught me something
PageSpeed Insights runs a Lighthouse audit in Google’s lab and, separately, shows the field data Google has collected from real Chrome users on that page, when there is enough of it. Those are two different things wearing one page, and confusing them is the single most common mistake I see in speed advice.
There is an API behind it, which is how you would collect the same numbers across a set of pages instead of clicking through them one at a time. I wrote a small script to do exactly that on 19 September 2026 and it came straight back with HTTP 429: too many requests. The keyless endpoint shares a daily quota with everyone else using it without a key, and that day the quota was gone. The fix is a free API key from the Google Cloud console with the PageSpeed Insights API enabled, which takes about four minutes (PageSpeed Insights API documentation).
I mention the 429 because it is the kind of detail that only turns up when you actually run the thing, and because it is why this site does not yet publish lab scores for its own pages. I would rather have an empty column than a number I did not collect. What I can and cannot conclude about hosting from the measurements I do have is in the post on Core Web Vitals on a cheap shared plan.
The Rich Results Test, for the ten minutes after you touch a template
The Rich Results Test does one job: it fetches a URL, parses the structured data, and tells you which rich result types Google can recognise and what is missing or malformed. It is not a scoring tool and it does not grade your SEO. It answers a yes-or-no question about machine-readable markup.
The moment it earns its place is right after you change a theme template, swap an SEO plugin, or edit the block that renders the author and date on a post. Those are exactly the changes that silently drop a field from your JSON-LD, and you will not notice from looking at the page, because the page still looks fine. Test one post, one page and the homepage after any template change, and you catch it in the same session instead of six weeks later in a coverage report.
One honest limit: the tool tells you the markup is valid and eligible. It does not promise Google will show anything, and eligibility has never been a guarantee of a rich result.
curl, which is not sold as an SEO tool at all
This is the one I would keep if I had to throw the rest away. curl makes an HTTP request and shows you exactly what came back, with no rendering, no plugin, and no opinion. Four things I check with it constantly:
- Status codes and redirect chains.
curl -sI -o /dev/null -w "%{http_code} %{redirect_url}\n" https://example.com/old-page/tells you in one line whether that URL is a 200, a 301 to the right place, or a 404 you did not know about. - What the HTML really contains.
curl -s https://example.com/ | grep -i canonicalshows the canonical tag as served, which is not always what the plugin settings screen claims. - Bytes, not characters.
curl -s https://example.com/robots.txt | od -c | head -1prints the first bytes of the file. On my own site that command showed357 273 277before the word User, which is a UTF-8 byte order mark sitting in front of the first directive. That file had been wrong, silently, and no browser view would ever have shown it to me. The wider clean-up of that domain is in the case study on retiring an old site from the same domain. - Response headers.
curl -sI https://example.com/reveals the server, whether anything is caching your pages, and whether compression is on. On 20 September 2026 that command told me neither of my WordPress blogs returns a page-cache header at all.
None of this requires you to be a developer. It requires you to be willing to look at the raw response once in a while instead of trusting a dashboard that is summarising it for you.
The WordPress REST API, when the job is ninety posts wide
This one is situational, but it saved me weeks on this very site. Every WordPress install exposes its content over a REST API, and you can read it without logging in. /wp-json/wp/v2/posts?per_page=100 hands you every published post as JSON: titles, slugs, dates, categories, full HTML. Pull that into a file and you can answer questions the admin screen will not, like which posts share an identical structure, which ones are under 400 words, or which ones contain a broken placeholder link.
That is how I audited this blog before rewriting it: export everything, sort by word count, and look at what the pattern says about the site rather than about any single post. With credentials the same API writes as well as reads, which is how you fix ninety posts without ninety trips through the editor.
The same openness has a sharp edge. The users endpoint will happily tell a stranger the login name behind your author account, and mine did exactly that when I checked. That is a security job rather than an SEO one, and I cover it in the post on hardening WordPress after finding my own site wide open.
Where the free tools run out
Ahrefs, Semrush, Surfer, and the rest of the paid research market: I am not a customer of any of them, so there is no ranking, no scoring table and no “best for” verdict here. I am not going to reprint their feature lists and call it a review, which is precisely what the old version of this page did.
What I will say is what the free tools genuinely cannot do, because pretending otherwise would be just as dishonest. Search Console only shows queries you already appear for. It cannot tell you what a competitor ranks for, size up a keyword you have never touched, or show you who links to anyone but you. That gap is real, and it is the gap the paid suites fill. Whether it is worth a subscription depends on whether you are publishing enough for the research to pay for itself, and that is a question about your calendar, not about software.
Plugins, free tiers and rank tracking
Do I need an SEO plugin on top of this? Something has to write your titles, meta descriptions, canonical tags and structured data. A plugin is the usual way, and modern WordPress generates a sitemap on its own at /wp-sitemap.xml with no plugin at all. What I would not do is install one and assume the job is finished: verify the output with the Rich Results Test and curl, because the settings screen and the served HTML are two different things.
Is free really enough? For monitoring, fixing and verifying your own site, yes, and it is not close. For prospective research into topics you do not yet rank for, no. Those are separate activities and it helps to stop calling them both “SEO tools”.
What about rank tracking? I do not track daily rankings, and on a site with this little traffic I could not learn anything from them that would not be noise. If I ever do start, I will say what I used and for how long, in this post, with dates.
My week, in roughly forty minutes
- Monday, ten minutes. Search Console performance for the last 28 days, then the indexing report if anything moved.
- After publishing or editing, five minutes. URL inspection on the changed page, plus a curl check that the canonical and status code are what I intended.
- After any template or plugin change, ten minutes. Rich Results Test on one post, one page and the homepage.
- Monthly, fifteen minutes. A curl pass over the redirect list and robots.txt, and a PageSpeed Insights run on the pages that changed most.
That is the entire stack. It costs nothing, it produces numbers I can defend, and it found a byte order mark, a set of zombie URLs and a cache that did not exist, none of which a keyword tool would ever have mentioned. If I add something paid later, it will show up here with the price, the date I bought it and what it told me that the free ones did not.