The Reach Bureau

SEO Automation: What to Automate and What Not

Ecommerce SEO automation: product cards moving through metadata, links, schema and analytics stages

"Fully automated" is the wrong target. Some SEO tasks should run without anyone watching. Others fail in ways nobody notices for months, and automating them buys you a slow disaster instead of a fast one.

The useful question is not what can be automated — almost anything can. It is what happens when the automation is wrong. That single test sorts the whole workflow.

The test

For any task you are thinking of automating, ask: if this produces a bad result, how long until someone notices?

  • Immediately, and it is obvious → automate it. A broken sitemap generator produces a visibly broken sitemap.
  • Eventually, through monitoring you already have → automate it with an alert attached.
  • Only when someone reads the output carefully → keep a human in the loop.
  • Only when a customer complains, or never → do not automate it. This is where invented product specifications live.

The failure mode that matters in ecommerce is the quiet one. A wrong dimension in a product description does not look wrong. It looks like a product description.

Sort by consequence of failure, not by whether it is technically possible

Automate freely

Sitemap generation and submission. Deterministic, and failure is visible.

Broken link and redirect-chain scanning. Let a crawler find them on a schedule; the fix is a separate decision.

Structured data validation. Check every product page daily; alert on invalid, do not auto-edit.

Index-status monitoring. Page count, coverage errors, robots changes.

Rank and visibility collection. Gathering the data is mechanical; interpreting it is not.

Reporting assembly. Pulling numbers into a template. The commentary is a separate job.

Image compression and format conversion in the upload pipeline.

Internal link suggestion. Generating candidate links is fine; inserting them without review is not — anchor text is editorial.

Automate with review

Meta title and description generation from product data. Rules produce good drafts and occasional nonsense: a 90-character title, a duplicate across variants, a phrase that reads badly. Review a sample of every batch.

Category description generation. Only where the inputs are genuinely different per category. If the only variable is the name, you are generating 400 interchangeable pages.

Product attribute enrichment. The highest-value automation in ecommerce and the highest-risk. Every enriched field needs checking against manufacturer data, because a wrong compatibility claim becomes a return.

Bulk alt text. Fine from real product data; nonsense from a filename.

Content refresh flagging. Automate finding stale pages; keep the decision about what to change.

Never automate

Deciding what to target. Needs to know which products have margin, which have stock, and what the business is trying to sell.

Merging or deleting pages. Irreversible in practice, and it needs judgement about accumulated links and demand.

URL structure changes. One bad automated rule can take out a catalogue.

Publishing without review at scale. The classic failure: 400 generated pages, nobody read ten, none of them rank.

Anything that writes to production without a diff you can inspect. If you cannot see what changed, you cannot undo it.

Disavowing links. Rare, consequential, and needs a human who understands the profile.

Where automation actually breaks

Learned the expensive way, on real stores.

  • Feed changes. A supplier renames a field; enrichment silently starts writing blanks or wrong values.
  • Template deploys. An automation that inserted content into a template stops matching, and injects nothing — or injects into the wrong place.
  • Edge-case products. Bundles, variants, made-to-order items break rules written for standard stock.
  • Out-of-stock handling. Automated generation happily writes a glowing description for something you no longer sell.
  • Language and locale. Rules written for one market produce awkward or wrong output in another.
  • Silent success. The worst case: the job reports success and did nothing. Always assert output changed, not just that the process exited zero.
What breaks in practice, and the guardrail for each

Guardrails worth building

1. Dry-run mode by default. Every automation shows what it would change before it changes anything. 2. A diff you can read. Row counts are not enough; you need to see values. 3. A blast radius limit. Refuse to update more than N pages in one run without explicit confirmation. 4. An assertion on output. "Did the field actually change?" catches silent no-ops. 5. Sample review built into the process, not left to discipline. Ten random items surfaced for approval before the batch commits. 6. A rollback path. Keep the previous values. On a catalogue, that means a snapshot, not a memory of what it looked like. 7. An alert when the automation does not run. Silence usually means broken, not nothing-to-do.

Numbers 4 and 7 are the ones teams skip, and they are the ones that cause the six-month-old problem nobody spotted.

A realistic setup

For a store with a few thousand products:

  • Fully automated: sitemaps, crawl scanning, structured data validation, index monitoring, data collection, report assembly, image processing.
  • Automated with sample review: meta generation, attribute enrichment, alt text, refresh flagging.
  • Human decision, tooling assists: what to target, what to merge, what to write, what to disavow, any URL change.

That is not "fully automated", and a store running exactly this is in better shape than one that is.

The checklist

  • Every task classified by how long a bad result would go unnoticed
  • Nothing that fails silently is fully automated
  • Dry-run mode is the default for every job
  • Diffs show values, not just counts
  • Blast radius capped per run
  • Output assertions catch silent no-ops
  • Sample review built into the batch process
  • Previous values snapshotted for rollback
  • Alert fires when a scheduled job does not run
  • Enriched attributes verified against manufacturer data
  • Out-of-stock and edge-case products excluded from generation rules
  • Feed field names monitored for supplier-side changes
  • Targeting, merging, deleting and URL changes kept with a human

Sources

Frequently Asked Questions

Anything where a bad result is immediately visible or caught by monitoring: sitemaps, broken-link scanning, structured data validation, index monitoring, data collection, report assembly and image processing.
Deciding what to target, merging or deleting pages, URL structure changes, publishing at scale without review, disavowing links, and anything that writes to production without an inspectable diff.
Ask how long a bad result would go unnoticed. Immediately obvious means automate; only-when-a-customer-complains means do not. In ecommerce the dangerous failures are quiet — a wrong dimension looks exactly like a right one.
Product attribute enrichment. It is also the highest-value, which is why it needs every enriched field verified against manufacturer data — a wrong compatibility claim reaches a customer and becomes a return.
Usually a supplier renames a feed field, a template deploy stops matching, or edge-case products break rules written for standard stock. Worst of all is a job that reports success and did nothing, which is why you assert that output actually changed.
No, and it is not the goal. A store that fully automates monitoring and data work, keeps sample review on generation, and keeps targeting and structural decisions with a person is in better shape than one claiming full automation.

Want this run against your store? Book a call with The Reach Bureau.

Share with AI

One-minute takeaway Summarize Explain like I'm a kid

Share this article

LinkedIn X Facebook Pinterest Email

Related articles

View all articles

Ready to scale your e-commerce?

Let's discuss your project and how we can help you achieve your growth goals.

Book a discovery call
Book a call with me, here is my schedule →