24 SEO Tasks Worth Automating, and 6 That Are Not
Most writing about SEO automation is written by people who have not run much of it. The tell is that the failure modes are missing. Real automation does not fail by producing nothing; it fails by producing something wrong, quietly, for three weeks, while a dashboard says everything is fine.
We recently finished an audit of 20,232 Indian online stores, sampling up to 30 pages each and scoring every one against eight weighted pillars. Almost all of it was automated, because at that scale there is no alternative. A good deal of it also broke in instructive ways. So this is a list of what is genuinely worth automating, what to use for each - an AI model or an ordinary script - and what we would not automate at all.
Key takeaways
- The test is not "can AI do this". It is "if this goes wrong, will I find out". Automate tasks whose output you can check, and instrument the ones you cannot.
- Most of the durable wins are ordinary scripts, not models. Fetching, comparing, counting and alerting have been solved for decades and do not hallucinate.
- Use models where the input is messy language and the output is checkable: classification, clustering, extraction, first drafts.
- Never automate anything whose failure is irreversible or public. Publishing, outreach and anything that emails a client stay manual.
- Automation has a running cost. If nobody owns the script, it will drift, and a drifted script is worse than no script.
The rule we use before automating anything
Two questions, in this order.
Is the output verifiable? A script that flags broken internal links is trivially verifiable: open the link. A model that "analyses search intent" for 400 keywords is not, which is why those outputs tend to be accepted unread.
Is failure visible? This is the one people skip. During our crawl, a backfill job ran to completion and reported success while doing nothing at all, because it queried a data set that permissions were hiding from it. Zero rows is not an error. If your automation can succeed at doing nothing, it will eventually do nothing.
Technical monitoring: automate all of it
This is the category with the least debate. The work is mechanical, the output is checkable, and humans are bad at doing it consistently.
- Uptime and status-code monitoring. Script. A page that starts returning 404 or 500 should reach you before it reaches your client.
- Redirect chain checks. Script. Especially after any migration, where chains appear quietly and never resolve themselves.
- robots.txt and meta robots diffing. Script. A staging
Disallow: /reaching production is the classic catastrophic deploy. Diff the file daily and alert on any change. - Sitemap validity and freshness. Script. Does it parse, does it 200, does it contain the pages published this week.
- Core Web Vitals sampling. Script, against the PageSpeed Insights API. Run it on a schedule against a fixed page set so the numbers stay comparable.
- Structured data validation. Script. Parse the JSON-LD and assert the fields you care about exist, rather than eyeballing a testing tool once a quarter.
Note that none of these need AI. They need a scheduler and somewhere to send an alert.
Crawling and site analysis: automate, with a leash
- Scheduled crawls. Script. The value is in the diff between crawls, not in any single crawl.
- Orphan and thin page detection. Script. Compare what the sitemap claims against what is actually linked.
- Internal link opportunity finding. Script for the candidate list, human for the decision. Which pages mention a phrase and do not link to the page about it is a query; whether the link belongs is a judgement.
- Duplicate and near-duplicate detection. Script, using shingling or embeddings. This is a genuine model use case where the output is still checkable by reading two pages side by side.
- Log file analysis. Script. Which pages crawlers actually fetch is one of the few honest signals available, and it is pure aggregation.
The leash matters. In our crawl, six sites hung workers indefinitely - each responded slowly enough to stay under the per-request timeout while never finishing. The fix is a per-site budget, not a longer timeout. Any crawler you run unattended needs a hard ceiling on total time per target, or one pathological site will stop the whole job while looking healthy.
Content operations: automate the checking, not the writing
- Internal link validation at build time. Script. Ours runs on every build and refuses to ship a broken internal link. It has caught more mistakes than any review process we have tried.
- Metadata length and uniqueness checks. Script. Titles too long, descriptions missing, two pages sharing a title.
- Content inventory and decay detection. Script. Pages losing impressions quarter on quarter, ranked by how much traffic is at stake.
- Brief generation from SERP analysis. Model, reviewed. A model is good at reading ten ranking pages and listing what they all cover. It is not good at deciding what your page should say instead.
- First-draft outlines. Model, reviewed. Useful for structure. Treat the prose as a starting point, never as output.
- Translation and localisation drafts. Model, reviewed by someone who speaks the language. The failure mode here is confident fluency in the wrong register.
We do not automate publishing itself. On our own site a post carries a word count in its metadata, and the build recounts the body and fails if the two disagree. That check caught four stale counts the day we added links to old posts. The point is not the word count. The point is that an automated check is worth more when it can stop a release than when it files a warning nobody reads. Our view on model-written content is in does Google punish AI content.
Research and analysis: models earn their place here
- Keyword clustering. Model or embeddings. Grouping thousands of queries by meaning is exactly what this technology is for, and a human can spot-check any cluster in seconds.
- Query classification by intent or stage. Model. Same reasoning: messy language in, structured label out, cheap to verify by sampling.
- Entity extraction from competitor pages. Model. What products, brands and attributes a page names, pulled into a table.
- Search Console reporting. Script. Pull the data through the API on a schedule. We do this for our own properties and for client accounts, and it takes the argument out of every conversation about whether something moved.
GEO and AI-visibility work: automate the measurement
This is newer, so the tooling is thinner, but the shape is the same as ranking reports were twenty years ago.
- Prompt-set monitoring. Script, calling assistant APIs. Fix a set of prompts a real buyer would type, run them on a schedule, record whether the brand is named and which sources were cited. Presence, not position, because there is no position.
- Citation source tracking. Script. Often the cited source is a directory or marketplace rather than the client's own site, which changes what you work on next.
- Machine-readability audits. Script. Whether a page declares what it is - a product, an organisation, a price - is a parsing question with a yes or no answer. Our whole India E-commerce GEO Index is this check, run 20,232 times.
That index is also the argument for automating measurement: at that sample size the patterns stop being anecdotes. 77% of stores showed a price on the page while only 56% declared it in markup. You cannot see that by looking at ten sites by hand. The GEO checklist covers what to do about it.
The six we will not automate
| Task | Why not |
|---|---|
| Publishing without review | The cost of one wrong published page is higher than the time saved on fifty right ones |
| Outreach and link requests | Automated personalisation is obvious to the recipient and burns the domain it is sent from |
| Anything that emails a client | A scheduled report that fires during an outage reads as negligence |
| Disavow files | Irreversible, rarely necessary, and easy to make things worse |
| Bulk redirect creation | The mapping is a judgement about intent; generate the candidate list, approve it by hand |
| Anything that writes to a live site unattended | Automation that only reads is recoverable. Automation that writes is a deploy. |
What automation actually costs
The pitch is always time saved. The bill arrives as maintenance, and it is worth stating honestly.
During our crawl, a monitoring script we wrote to restart stalled workers matched its own process when it went looking for them, decided the system was unhealthy, and restarted healthy jobs 71 times before we caught it. The crawler itself leaked about 30MB a minute, so it needed a supervisor to restart it from a progress file. A summary that had been computed correctly for months stopped fitting inside its time limit once the data set crossed twenty thousand rows, and the page went on serving the last good numbers without complaint.
None of that is an argument against automating. We would not have finished 20,232 sites otherwise. It is an argument for three habits: make every job resumable, make it refuse to run on empty input, and give someone the job of reading its output once a week. An unowned script does not stay correct - the site changes underneath it, and it keeps reporting on a world that no longer exists.
Where to start
Pick the task your team does every week and dislikes most. If it involves fetching something, comparing it to last week, and telling someone what changed, it is a script and you will have it working in an afternoon. If it involves reading messy language and putting it into categories, it is a model, and you should sample twenty outputs before you trust the other four hundred.
Everything else - the judgement, the decision about what to publish, the conversation with the client - is the job. Automation is for clearing the way to it. Our own process is written up in how we run SEO.
Send us the task your team repeats every week and dreads. We will tell you honestly whether it is worth automating, or whether it is just badly scoped.
Tell us what you do weeklyOr email hello@tikbo.in