How to automate technical SEO (and what to keep manual)

What "automating technical SEO" actually means

Technical SEO is a loop: find problems, decide which ones matter, fix them, confirm the fix worked, and notice when something breaks again. Each step can be automated to a different degree:

• Finding problems: almost fully automatable. Crawlers and analyzers are good at spotting missing tags, broken links and blocked pages.
• Prioritizing: mostly automatable. Severity rules get you 90% of the way; business context does the rest.
• Fixing: partly automatable. Mechanical fixes (image dimensions, lazy loading, redirect targets) can be written by a tool. Copy like titles and descriptions can be drafted by AI but should be reviewed.
• Verifying: fully automatable. Re-check the live page after the change ships.
• Catching regressions: fully automatable, and the step with the best return. A single noindex on the wrong template can remove a site from Google in days.

The goal is not a robot that "does SEO". It is a system where machines do the repetitive checking and people only spend time on decisions.

Step 1: Run audits on a schedule, not when you remember

A one-off audit tells you how the site looked on one day. Sites change every week: new templates, plugin updates, content imports, CMS migrations. Put a full crawl on the calendar.

• Small sites (under a few hundred pages): a full audit monthly, and after every redesign or migration.
• Larger or frequently deployed sites: weekly, plus monitoring of key pages between audits (Step 3).

Desktop crawlers like Screaming Frog can schedule crawls if the machine is on. Cloud tools run without your laptop. In SEODevil you start an audit from the dashboard, and it crawls up to 25 pages on Pro and 100 on Agency, runs 11 analyzers on each page and turns every issue into a task with a page URL. You can try the analyzers on a single page with the free meta tag checker or heading checker.

Whatever tool you use, the output should be a list of tasks, not a PDF nobody opens. A task has an owner, a page and a status. A PDF has none of those.

Step 2: Block SEO regressions in CI before they ship

The most expensive technical SEO bugs come from deploys: a staging noindex reaching production, a robots.txt with Disallow: /, a canonical pointing at the staging domain. These are easy to test, so test them where you already test code.

This GitHub Actions job runs after a preview or staging deploy and fails the build if a key page is not indexable:

name: seo-smoke-test
on: [deployment_status]

jobs:
  seo:
    if: github.event.deployment_status.state == 'success'
    runs-on: ubuntu-latest
    steps:
      - name: Check key pages are indexable
        env:
          BASE: ${{ github.event.deployment_status.target_url }}
        run: |
          fail=0
          for path in / /pricing /features; do
            html=$(curl -fsSL "$BASE$path") || { echo "::error::$path did not load"; fail=1; continue; }
            headers=$(curl -fsSIL "$BASE$path")
            if echo "$html" | grep -qiE '<meta[^>]+name="robots"[^>]+noindex'; then
              echo "::error::$path has a noindex meta tag"; fail=1
            fi
            if echo "$headers" | grep -qi '^x-robots-tag:.*noindex'; then
              echo "::error::$path sends X-Robots-Tag: noindex"; fail=1
            fi
            if ! echo "$html" | grep -qi '<title>[^<]\+</title>'; then
              echo "::error::$path has no <title>"; fail=1
            fi
          done
          if curl -fsSL "$BASE/robots.txt" | grep -qiE '^disallow:\s*/\s*$'; then
            echo "::error::robots.txt blocks the whole site"; fail=1
          fi
          exit $fail

Two things to keep in mind:

• Preview and staging environments are often noindexed on purpose. Run the check against a build that uses production settings, or skip the noindex test on preview URLs and run it again after the production deploy.
• Keep the list of paths short: one page per template is enough. The point is to catch template-level mistakes, not to crawl the site on every commit.

For performance, Lighthouse CI can fail a build when Core Web Vitals lab scores drop below a budget. Use it for performance only; its SEO category checks too little to rely on.

Step 3: Monitor your most important pages between audits

CI only sees changes that go through your pipeline. Plenty of SEO damage doesn't: someone ticks "Discourage search engines" in WordPress, an SEO plugin update rewrites canonicals, a CDN rule starts blocking crawlers, a marketing editor deletes a title in the CMS.

Monitoring fills that gap. Pick the pages that bring in most of your traffic or revenue, record a baseline, then compare every check against it. The changes worth alerting on:

• Critical: page stops loading, noindex appears, canonical points to another domain, robots.txt blocks all crawlers.
• High: page starts redirecting, canonical changes, title disappears.
• Medium: meta description or H1 removed, visible content drops sharply, robots.txt changes.

Send critical alerts somewhere people will see them within the hour, usually Slack, not a weekly digest. SEODevil monitoring does this out of the box: your homepage daily on the Free plan, up to 25 URLs hourly on Pro and up to 100 URLs every 30 minutes on Agency, with alerts by email and Slack.

Step 4: Let the tool rank issues, then apply your own judgment

A 100-page audit can easily produce several hundred issues. Without prioritization, teams either fix the easy ones (rarely the important ones) or give up.

Automate the first pass with severity rules:

1. Indexing and crawling problems first: noindex on pages that should rank, blocked resources, broken canonicals, server errors.
2. Problems on many pages at once: a missing description on a template affects every page using it, and one fix solves all of them.
3. Page-level issues on pages with traffic: use Search Console data to sort by impressions.
4. Everything else, in batches.

Then spend ten minutes on the list yourself. A tool doesn't know that your /pricing page matters more than an old press release, or that a page flagged as "thin" is a login screen that should be noindexed anyway.

Step 5: Automate the fixes that are mechanical

This is where automation has improved the most. Many fixes don't need creativity, only access to the right file or CMS field:

• Internal links that redirect: replace the link with the final URL.
• Mixed content: switch http:// resources to https:// when the secure version loads.
• Images without width and height: measure the image and add the attributes, which prevents layout shift.
• Images below the fold without loading="lazy": add it, while leaving the first images eager so your LCP image is not delayed.
• Missing or broken viewport tags.

Text fixes (titles, meta descriptions, alt text) can be drafted automatically too, but treat them as drafts. AI is good at writing a 150-character description that matches the page; it doesn't know your brand voice or which keyword you're targeting. Review before publishing.

Where the fix lands depends on your stack:

• WordPress: the REST API with an Application Password can update titles, Yoast or Rank Math descriptions and media library alt text. SEODevil's WordPress auto-fix previews each change, writes it, reads it back and keeps the old value so you can undo it.
• Code-based sites (Next.js, Astro, Hugo, plain HTML): changes belong in the repository as a pull request, so they go through review and your normal deploy. SEODevil's GitHub PR fixes find the line in your repo and open a PR, and can fix the same issue across many pages in a single PR.
• Headless CMS: most have a content API, but fields differ per project, so this usually needs a small custom script.

For one-off fixes you can paste yourself, the AI fix generator writes the exact code for a flagged issue.

Step 6: Verify every fix and measure the result

A fix isn't done when the code merges. It's done when the live page no longer has the problem. Caches, CDNs, plugins that override meta tags and templates that ignore a field all cause fixes that "shipped" but never appeared.

1. After deploy, re-fetch the live page and re-run the check that flagged the issue.
2. Only close the task if the issue is gone.
3. Four weeks later, compare clicks and impressions for the page against the four weeks before the change.

The last step is what turns SEO from a cost into something you can report on. SEODevil does it with Search Console fix impact, which compares each applied fix or merged PR before and after.

What you should not automate

• Rewriting content at scale. Mass AI rewrites of page copy tend to make pages more alike, not better, and are hard to undo.
• Redirect decisions. Automatically redirecting every 404 to the homepage hides real problems and Google treats those redirects as soft 404s.
• Canonical and noindex choices. Which version of a page should rank is a business decision. Automate the alert, not the decision.
• Internal linking by keyword. Plugins that link every occurrence of a phrase create unnatural, repetitive links.
• Anything without an undo. If a tool can't show you the previous value, don't let it write to production.

A simple automated technical SEO setup

If you want a starting point, this covers most sites:

1. CI smoke test on every production deploy: noindex, X-Robots-Tag, title and robots.txt on one page per template.
2. Monitoring on your top 10–25 pages with Slack alerts for critical and high changes.
3. A full audit every week or month, depending on how often the site changes.
4. Mechanical fixes applied automatically as pull requests or CMS updates, with review.
5. Text fixes drafted by AI, edited by a person.
6. Automatic re-checks after deploy, and a monthly look at fix impact in Search Console.

Setting this up takes an afternoon. After that, technical SEO becomes a short weekly review instead of a quarterly fire drill.

Frequently asked questions