SEO from the terminal: how I use claude-code-seo for my side projects

I run several small products next to everything else. SeggWat, Stepshots, infra.page, this blog.

None of them can afford an SEO agency. None of them can afford much of my attention either.

SEO tools always lost me at the same point: a dashboard, a subscription, and a score that says my site is a 34 without telling me what to publish on Tuesday.

What finally stuck was a git repo.

The repo

First, credit where it belongs: claude-code-seo is not my work. mxfschr distilled years of r/SEO advice, mostly u/WebLinkr's, into a markdown knowledge base and nine slash commands for Claude Code. I just use it, and adapted a few edges for my setup.

The idea is simple and a little radical: SEO as something you execute, not something you read about.

/seo-analyze mydomain.com

That pulls 90 days of my Google Search Console data over MCP, works out the hardest keywords I already rank top-7 for, and hands me three to five topics that extend that authority. With slugs, titles, and an internal linking plan.

Notice what is missing: a domain rating. The bar for "can this page rank" is what my pages already proved, not what a third-party score guesses.

Two details made it stick where the dashboards did not.

It hands me a plan. /seo-analyze returns three to five candidates with titles, slugs, and internal-link wiring. /seo-next-content turns the one I approve into a publish-ready brief.

It is honest. When there are no quick wins, it prints "0 quick wins" instead of inventing some. When a ranking only exists in a country I do not sell to, it says so. And before a content brief may claim a product feature, /seo-product-facts reads the actual code and cites file and line. No invented features, which matters more than ever now that LLMs repeat whatever you publish.

Running it costs almost nothing. The GSC API is free, DataForSEO is prepaid pay-per-call, and my weekly runs land between zero and eighteen cents.

My cadence

• Weekly: /seo-quick-wins, which finds pages at position 4 to 15 that need exactly one push.
• Per topic I green-light: /seo-next-content for a publish-ready brief.
• Every six weeks or so: /seo-analyze re-maps where the authority is now.

I also avoid touching the same page twice within seven days. Search Console needs time to register each change, and stacked edits make cause and effect unreadable.

What I keep outside the terminal

The Search Console MCP stays because the commands need GSC data. URL submission is separate. For ordinary pages, I submit the sitemap and use Search Console's URL Inspection tool to request indexing on the URLs that matter.

Google's Indexing API only supports pages with JobPosting or livestream BroadcastEvent markup. It is not a general URL-push API for blog posts, so I do not keep a separate indexing MCP server in the config. The terminal analyzes; Search Console handles manual requests.

The checklist that is not in the repo

The repo is Google-first, and that is correct: Search Console is where the feedback loop lives.

But my audience is developers, and developers increasingly ask ChatGPT or Claude before they ever type into Google. Those products use their own crawlers and external search partners, so Google cannot be my only indexing check.

1. Google Search Console. The baseline. Submit the sitemap, and for pages that matter, request indexing on the URL directly. Nothing new here.

2. Bing Webmaster Tools, with IndexNow. OpenAI says ChatGPT Search sometimes works with external search providers and lists Bing among them. OpenAI also runs OAI-SearchBot, so Bing is not the whole pipe. It still matters. Bing Webmaster Tools can import verified sites from GSC. Then set up IndexNow: it immediately notifies Bing and the other participating engines when a URL changes. This blog pings IndexNow on every deploy, straight from the GitHub Actions pipeline. Most developers never open Bing. That habit is now backwards.

3. Brave. Anthropic tells site owners that Claude web search uses search partners, and its government web-search connector explicitly calls the Brave Search API. That does not prove every commercial Claude search comes solely from Brave. It is enough for me to treat Brave's independent index as another discovery surface. Submitting a URL takes a minute.

Ten minutes of submissions, total. If your users ask AI assistants before they search, those ten minutes might matter more than the difference between position 3 and 4 on Google.

Two more things I do that are less checklist and more habit:

Ship open source, and let the platforms rank for you. github.com, npmjs.com, crates.io, docs.rs: these are some of the strongest domains on the internet, and every real project you publish gets a page on them. Those pages rank for your product name and your problem space long before your own young domain does, they link back to you, and LLMs read and cite them constantly. This is not a link scheme, and it does not work as one. It works when the repo or crate is a real thing people star and use. But if you were going to open source it anyway, publish it properly: good README, clear problem statement, link to your site.

Show the workflow instead of describing it. For tutorials, I record step-by-step demos with Stepshots, which is my own project, so calibrate for bias. The reason it belongs in an SEO post: tutorial pages that show every click answer the "how do I actually do this" queries that assistants and searchers both reward, and readers stay long enough to finish them.

What to expect

Indexing is admission, not ranking. Submitting a URL across these discovery surfaces gets you evaluated, nothing more.

The repo's own expectation management is the most honest I have seen in SEO material: new pages index in one to two weeks, reach position 10 to 15 in four to eight weeks if the internal linking is actually executed, and get their real evaluation over about thirteen months of click data. The maintainer took a zero-authority domain to page one in its niche with this exact loop, and still writes "there is almost certainly still some dumb-ass shit in here" at the top of the README.

That sentence is why I trust the repo. SEO compounds slowly, and the only way to survive that is a loop that runs on real data and admits what it does not know.

If you know SEO better than I do, the maintainer explicitly asks you to tear the repo apart. Open an issue. I will keep running the loop in the meantime: publish into proven authority, push what is almost there, and let GSC tell me what actually worked.