DEV Community: Aaron VanSledright

One Deep Audit for $12: Full Report, No Subscription

Aaron VanSledright — Mon, 05 Oct 2026 17:47:19 +0000

You can now buy a single Deep Audit for $12. There is no plan to sign up for and nothing to cancel. Open a report, look at the free version, and pay only if you want the rest.

What you see for free

Every hosted report at seoscoreapi.com/report/yourdomain.com opens as a free look. It shows the overall score and grade, how many issues were found at each severity, and the title of the most important one. The remaining issues and their fixes are hidden until the report is unlocked.

That is enough to answer the first question most people have, which is whether the site has a problem worth paying to understand.

What $12 unlocks

The single purchase does two things:

It unlocks the full hosted report for that domain. Every issue, every fix, and a plain-English sentence for each one that says what is wrong and who should fix it.
It gives you one Deep Audit credit. A Deep Audit is the long-form audit: thousands of checks from a public catalog of more than 14,000, scored across nine sections, with an AI analysis pass on top. It takes about 90 seconds and runs in the background.

You also get the exports. The unlocked report downloads as a PDF, as Markdown, or as a CSV, so the fix list can go straight into a ticket tracker or a client email.

A free API key is created for the email address you pay with. You don't need to use it, but it is there if you later want to run audits from code.

Who this is for

A site owner who wants one answer. You don't run audits every week. You want to know what is wrong with one site, once.
An agency checking a prospect. Run the audit before a pitch, export the PDF, and bring real findings to the first call.
A developer about to take on a rebuild. Get a baseline before you touch anything, so the improvement is measurable afterwards.

When a pack or a plan costs less

The single is the right buy for one report. If you need more, the price per audit drops:

Option	Deep Audits	Price	Per audit
Single	1	$12	$12.00
3-pack	3	$29	$9.67
10-pack	10	$79	$7.90
Pro plan	20 a month	$39/mo	$1.95
Ultra plan	100 a month	$99/mo	$0.99

Pack credits are valid for 12 months. Pro and Ultra also include the standard audit API (5,000 and 25,000 audits a month), so anyone auditing regularly is better off on a plan. Details are in Buy Deep Audit Credits and on the pricing section.

How to buy one

Open https://seoscoreapi.com/report/yourdomain.com.
Enter your email in the unlock box and pay by card.
You land back on the full report. A button on the receipt starts the Deep Audit.

If you want to know what a Deep Audit scores before you buy, Reading a Deep Audit Report walks through each section, and the check catalog lists every check by name.

Frequently asked questions

Is the $12 a subscription?

No. It is a one-time charge. Nothing renews.

Does the unlock cover more than one site?

No. One purchase unlocks the full report for one domain and includes one Deep Audit credit.

Do I need an account?

No. You pay with an email address. A free API key is created for that address so the unlock follows you if you sign in later.

Replacing Screaming Frog with an API: A 10,000-URL Agency Workflow

Aaron VanSledright — Mon, 05 Oct 2026 14:00:07 +0000

Screaming Frog SEO Spider is the most-installed SEO tool in agency workflows. Most audits we've seen referenced over the past decade started with a Screaming Frog crawl. It's a good piece of software. It is also a desktop application that has to be running on someone's laptop, that has to be configured per-project, that has to be re-run when anything changes, and that produces a CSV which then has to be opened in Excel and triaged by hand.

This post is for agencies and in-house teams asking the obvious question: what does the API equivalent look like, and is it actually cheaper? The short answer is yes, with a different shape of workflow. The longer answer is below.

What Screaming Frog is good at

Crediting where credit is due. Screaming Frog does several things well:

Crawl discovery. Point it at a URL and it walks every internal link. You don't need to know your sitemap, your sitemap doesn't have to be correct, you'll find pages the sitemap forgot.
Per-page detail. It pulls headings, meta tags, internal/external links, response codes, redirect chains, and a long tail of properties.
One-off depth. Configure once, crawl once, walk away.

If you're doing a single deep audit of a single site and never re-running it, Screaming Frog is fine. Pay the £199/year and move on.

What it isn't good at

Where it breaks down for an agency or in-house team running ongoing audits:

It's a desktop app. Someone's laptop has to be on, awake, and not crashing. For a 50,000-URL site that's a 6-hour crawl on a tuned machine.
Crawls don't compose. Last week's crawl is a CSV on someone's hard drive. There is no built-in "what changed since last week" view that isn't manual diffing.
No native scoring or grading. It tells you a <title> is 67 characters long. It does not tell you "this page scores 84 and your competitor scores 91 and here's why."
No API surface. You cannot trigger it from a CI pipeline, schedule it from a server, or hand a button to a non-technical colleague.
Per-seat licensing. Each analyst needs their own license, their own configuration, their own copy of the CSV.

For a team of three doing weekly audits across twelve clients, those constraints stop being theoretical and start eating real hours.

The API-equivalent workflow

Same outcome — a scored audit of every URL on the site — restructured as a server-side job:

import requests, csv, os
import xml.etree.ElementTree as ET

API_KEY = os.environ["SEOSCORE_API_KEY"]
BASE = "https://api.seoscoreapi.com"

def crawl(site):
    """Pull URLs from the sitemap, recursing into indexes."""
    ns = {"sm": "http://www.sitemaps.org/schemas/sitemap/0.9"}
    def _collect(url):
        root = ET.fromstring(requests.get(url, timeout=20).text)
        if root.tag.endswith("sitemapindex"):
            urls = []
            for child in root.findall(".//sm:sitemap/sm:loc", ns):
                urls.extend(_collect(child.text))
            return urls
        return [l.text for l in root.findall(".//sm:url/sm:loc", ns)]
    return _collect(f"{site}/sitemap.xml")

def audit_all(urls):
    rows = []
    for i in range(0, len(urls), 50):
        r = requests.post(
            f"{BASE}/audit/batch",
            headers={"X-API-Key": API_KEY},
            json={"urls": urls[i:i+50]},
            timeout=300,
        )
        r.raise_for_status()
        rows.extend(r.json()["results"])
    return rows

urls = crawl("https://client.com")
print(f"Discovered {len(urls)} URLs")
results = audit_all(urls)
print(f"Audited {len(results)} pages")

Sixty lines, end to end. Run it on a server. Output a CSV. Hand the CSV to the analyst, or pipe it into a dashboard, or post it to Slack.

The crawl-discovery gap (and how to close it)

The honest tradeoff: a sitemap-based crawl is not a true crawl. If a page exists but isn't in the sitemap, you won't find it. Screaming Frog walks every link and finds those orphans.

For most sites this matters less than you'd think. Marketing sites publish complete sitemaps. Shopify, WooCommerce, WordPress with Yoast — all generate exhaustive sitemaps automatically. If you've audited the sitemap, you've audited the site that Google can see.

For sites where it does matter (legacy CMS, fragments of static HTML hand-rolled into Apache, archives that nobody linked into the nav), a one-time Screaming Frog crawl to generate the URL list, plus the API for ongoing scoring, is a perfectly reasonable hybrid. The API doesn't have to replace every part of the workflow to be a 10x improvement on the parts it does replace.

What the API does that the desktop can't

The interesting tradeoff isn't "what we lost" — it's "what we gained that wasn't possible before."

Historical comparison. Every audit's score is stored against your key. Run the same audit weekly and you have a per-URL trend line, with deltas surfaced automatically. The historical tracking post has the full API. There is no equivalent in Screaming Frog without manually saving and diffing CSVs.

Composability. The audit results are JSON. Pipe them into anything. We've seen teams build:

Slack alerts that fire when any tracked client drops 3+ points.
HTML dashboards generated from /history/domains for monthly client reviews.
Re-audits triggered automatically when a new deploy lands in production.

Side-by-side comparisons. /compare audits two URLs in parallel and returns a diff. Use it for client-vs-competitor pitches, before/after migration checks, or A/B preview/production validation. The Stripe/Square/Adyen comparison post shows the format.

AI readability and GEO scoring. SEO Score API runs the same 55 SEO checks Screaming Frog covers plus an additional layer specifically for how LLMs read your content. That's not in Screaming Frog at all and isn't going to be — it's a different category of analysis. The GEO optimization guide and AI readability post cover what's in there.

Shareable reports and badges. Every audited URL gets a publicly shareable report at /report/{domain} and an SVG score badge. Drop the badge in client decks; drop the report URL in emails. There's no Screaming Frog equivalent — its outputs are CSVs that only the analyst sees.

Cost comparison, honestly

Screaming Frog SEO Spider: £199/year per seat (~$250/year).

SEO Score API:

Tier	Audits/mo	Annual cost	Use case
Basic	1,000	$180/year	Solo SEO, 3-5 small clients
Pro	5,000	$468/year	Agency with 10-20 clients, weekly audits
Ultra	25,000	$1,188/year	Agency with 30+ clients or one large enterprise site

A two-person agency replacing two Screaming Frog seats (~$500/year) gets the same audit coverage on Pro for less money, plus everything in the "what the API does that the desktop can't" section. A larger agency replacing 4-5 seats (~$1,200/year) lands on Ultra and gets unlimited history retention, which on its own is worth the difference.

The break-even is rough but real: somewhere around 3 seats of Screaming Frog, Ultra is cheaper and strictly more capable.

What we keep Screaming Frog around for

We don't pretend the API replaces 100% of use cases. Where Screaming Frog still wins:

Crawling sites with broken or missing sitemaps.
Following redirect chains across external links to figure out what an old domain ended up redirecting to.
One-shot deep audits where you want every property of every page in a single CSV and you'll never re-run the audit.
Legacy site migrations where you need to map old URLs → new URLs by content hash.

Use the right tool for the job. The point isn't to eliminate Screaming Frog — it's to stop using it for the weekly and per-deploy and cross-client work that it was never designed to do, where its constraints turn into real cost.

The migration path

If you're an agency moving from Screaming Frog-only to API-first, the order we'd suggest:

Pick your three highest-effort clients. Audit their sites with the API. Compare the output to your most recent Screaming Frog audit. Confirm the coverage is equivalent for your purposes.
Stand up a weekly job. Cron + a Python script + Slack webhook. The agency monitor setup post has the full walkthrough.
Move quarterly client reports onto the API output. The HTML report at /report/{domain} is shareable; the badge is droppable; the history endpoint generates trend charts.
Use Screaming Frog only for the deep one-off audits where its discovery wins. That's roughly twice a year per client, not weekly.

Most agencies that do this end up shifting 80–90% of their crawler-hours to the API and keeping Screaming Frog around for the long-tail cases. Total cost drops, total throughput goes up, and the analyst time freed up goes into actual fixes instead of running spider crawls overnight.

Getting started

If you're a solo or small agency, Basic ($15/mo) covers 3-5 sites at weekly cadence. If you're running an agency at scale and Screaming Frog has become a bottleneck, Pro ($39/mo) is the sweet spot. For the largest agencies with 30+ clients, Ultra ($99/mo) replaces the seat-licensing math entirely.

One SEO Tools API, Five Workflows Your Team Probably Already Needs

Aaron VanSledright — Mon, 28 Sep 2026 14:00:03 +0000

The phrase "SEO tools API" gets searched a lot, and it usually means something different to whoever's typing it. Some people mean "an API that audits one page." Some mean "an API that pulls multiple SEO tools together." Some mean "an API I can wire into my existing tools."

SEO Score API is the first of those, but it functions as the second and third — because once you have a structured audit response, it slots into existing tooling without much glue. This post walks through the five workflows engineering and agency teams build on top of the same endpoint, all from one API key.

Workflow 1: CI gates

The most common first integration. You hit /audit?url=... against your preview deploy in GitHub Actions and fail the build if the score regresses.

- run: |
    SCORE=$(curl -s -H "X-API-Key: $KEY" \
      "https://seoscoreapi.com/audit?url=$PREVIEW" | jq .score)
    [ "$SCORE" -lt 85 ] && exit 1

That's the whole gate. Detailed walkthrough in Wiring an SEO analyzer API into a Next.js build and the published GitHub Action.

Workflow 2: Scheduled monitoring

Same endpoint, different schedule. Instead of one audit per PR, run a list of URLs nightly or weekly and alert on regressions.

# nightly_monitor.py
from seoscoreapi import audit
import os, requests

URLS = ["https://site.com/", "https://site.com/pricing", ...]
for url in URLS:
    r = audit(url, api_key=os.environ["KEY"])
    if r["score"] < 80:
        requests.post(os.environ["SLACK_HOOK"], json={
            "text": f"⚠️ {url} scored {r['score']} ({r['grade']})"
        })

Cron it, point it at Slack, ship it. SEO Monitor API: score tracking with webhooks and Slack alerts has the production-grade version with deduplication and SLA windows.

Workflow 3: AI agents

LLMs are bad at reading screenshots and good at reading JSON. The same /audit response that powers a CI gate is what you hand an agent when you want it to fix SEO issues autonomously.

findings = audit(url, api_key=KEY)
agent_prompt = f"""
You're an SEO engineer. Here's the audit JSON for {url}.
Fix the top 3 failing checks. Return a unified diff.

{json.dumps(findings, indent=2)}
"""
diff = claude.messages.create(model="claude-opus-4-7", ...)

That's it. The structured response is the contract; the agent just acts on it. Build an AI SEO Agent walks through the full loop with Claude, and we ship an MCP server so Claude and Cursor can call the API natively.

Workflow 4: Client and stakeholder reports

The audit response is structured to be rendered as well as acted on. Three rendering options, in order of effort:

Lowest-effort: link clients to /report/{domain} — that's our hosted report URL, auto-refreshed when the audit re-runs. Zero code, branded enough for most.

Medium-effort: wrap the /audit JSON in a Jinja template, send as HTML email via your SMTP of choice. ~80 lines. Full walkthrough in Generating weekly client SEO reports automatically.

Highest-effort: build your own white-label dashboard on top of the API. The white-label SEO reports post covers this.

Same endpoint, three different report surfaces.

Workflow 5: Status badges

Useful for open-source projects, public marketing pages, and internal dashboards. Embed an SVG that reflects the current score:

![SEO Score](https://seoscoreapi.com/badge/your-domain.com)

The badge re-renders from the most recent audit. Run a weekly cron that audits your domain and the badge stays current. Free tier covers this for one domain forever.

Why one endpoint instead of five

Some SEO APIs split their product across endpoints — one for "audit," one for "monitor," one for "report." That's a UX choice with a real cost: every new endpoint is a new response shape your code has to learn, a new error model to handle, a new SDK method to remember.

We deliberately built around one endpoint (/audit) returning one response shape. The five workflows above all consume the same JSON. That means:

The Jinja template you write for the weekly client report works on a CI gate's output too.
The Slack alert format you wrote for nightly monitoring works on PR-blocking failures.
The agent prompt you tuned against last Tuesday's audit still works against tomorrow's.

The endpoint is the API. Everything else is glue you write once and reuse.

What ties the workflows together

One API key. One endpoint. One response shape.

If you're evaluating SEO tools APIs and the comparison matrix gets complicated — "this one has 6 endpoints, this one has 12, this one has webhooks but not batches" — that's a signal that the surface is too wide. The narrower the API, the more workflows it actually fits.

Sign up for free and see if a single /audit response slots into more places than you'd expect. The free tier (2/day, no card) is enough to prototype any of the five workflows above.

The SEO Checker API: Pass/Fail SEO Checks for Code, Not Dashboards

Aaron VanSledright — Mon, 21 Sep 2026 14:00:05 +0000

An SEO checker API is an SEO checker that returns its results as machine-readable JSON instead of a dashboard. Every check returns a structured pass/fail, a numeric score, and the value found — so the next thing in your pipeline can act on it without a human in the loop.

That distinction is the entire reason to use an API over a tool like Screaming Frog or a SaaS dashboard. The dashboard is for humans clicking through findings. The API is for code that already knows what to do once it has the answer.

What "pass/fail per check" actually means

When you hit GET /audit?url=https://example.com against SEO Score API, you get back a response that looks like this (trimmed):

{
  "score": 78,
  "grade": "B",
  "audit": {
    "meta_content": {
      "score": 92,
      "checks": [
        {"id": "title_present", "status": "pass", "value": "Example Domain"},
        {"id": "title_length", "status": "pass", "value": 14, "ideal": "30-60"},
        {"id": "meta_description_present", "status": "fail", "value": null}
      ]
    },
    "technical_seo": { "...": "..." }
  }
}

status is one of pass, warn, fail. That single field is the whole product surface for code-driven workflows: filter the array, count the failures, threshold on category sub-scores, write a diff against last week's run. None of that requires reading the dashboard.

Three workflows the pass/fail shape unlocks

1. CI gates. Pull the score in a GitHub Action and fail the build if it drops below 85. Twenty lines of YAML and a single API call. We publish a GitHub Action that does exactly this, but you can roll your own with curl.

- name: SEO checker
  run: |
    SCORE=$(curl -s -H "X-API-Key: ${{ secrets.SEO_KEY }}" \
      "https://seoscoreapi.com/audit?url=https://preview.example.com" \
      | jq '.score')
    if [ "$SCORE" -lt 85 ]; then exit 1; fi

2. Regression diffs. Store yesterday's audit JSON, run today's, diff the checks arrays. Any check that flipped pass → fail is a regression you can name. We do this in the historical tracking endpoint and it's also trivial to do client-side with two JSON blobs and a dict comparison.

3. Agent loops. An AI agent doesn't want a screenshot, it wants structured findings to act on. Hand the agent the checks array and let it decide which failures to fix in which order. See Build an AI SEO Agent for a worked example.

Why structured pass/fail beats a score-only API

A lot of "SEO score" APIs return a number and nothing else. That's not actually useful in code — you can't fix a problem you can't name. The minimum useful response for an SEO checker API is:

An overall 0–100 score (for thresholding)
A category breakdown (for routing fixes to teams)
Per-check results with stable IDs (for diffs and remediation)

SEO Score API returns all three. Every check has a stable string ID (title_length, canonical_present, og_image_dimensions) that you can match against across audits without parsing display text.

How it relates to dashboard tools

A dashboard tool — Ahrefs Site Audit, Screaming Frog, Sitebulb — is built to give a human the full picture of a site so they can prioritize. An SEO checker API is built for the moment after prioritization, when you already know what "good" looks like and want code to enforce it.

The two are complementary. Big agencies typically run a dashboard for human-driven discovery and an API for the production guardrails (CI gates, weekly client diffs, monitoring). How SEO Score API sits alongside Ahrefs and Moz goes into more detail on the split.

Getting started in five minutes

curl -H "X-API-Key: YOUR_KEY" \
  "https://seoscoreapi.com/audit?url=https://your-site.com"

That's the full first interaction. You'll get back the same response shape your CI gates and monitoring will eventually consume — which means the prototype you write today is the production code you ship tomorrow.

If you're evaluating SEO checker APIs against each other, the questions worth asking are: does it render JavaScript pages (we do, via headless Chromium)? Does it return stable check IDs (yes)? Does it have SDKs in your language (Python, Node, n8n, and a GitHub Action ship today)? And does the free tier let you actually evaluate the response shape before committing? All four of those are table stakes for a checker that's going to live in your pipeline.

Pre-Deploy SEO Gates: Catch Score Regressions Before You Ship

Aaron VanSledright — Mon, 14 Sep 2026 14:00:04 +0000

The pattern that costs teams the most SEO traffic is the one nobody can post-mortem: a regression that shipped a month ago, that nobody noticed because traffic only dipped 8%, that nobody can attribute to a specific deploy. By the time someone runs an audit, twenty commits have landed and the cause is buried.

The fix is to audit every PR before it merges and fail the gate when the score drops materially. This post walks through that gate end-to-end — what to compare, what threshold to use, and the actual GitHub Actions / GitLab CI / generic Python implementation.

What a pre-deploy SEO gate actually checks

There are three distinct comparisons worth running on a PR, in order of how strict they should be:

PR preview URL vs production. Most teams have preview deploys (Vercel, Netlify, Cloudflare Pages). Audit the preview, audit prod, fail if the gap is wider than threshold. This is the strictest, most useful check.
Preview vs last preview. If you don't ship to production from main, or you want a check on a feature branch before it touches prod, audit this branch's preview vs the previous branch's preview.
PR preview vs all-time best. Useful as a soft warning, not a hard gate — "this PR isn't bad, but the homepage was at 94 in February and you're at 89."

We'll focus on #1, which is what 90% of teams want.

The minimum viable gate

# .ci/seo-gate.py
import os, sys, requests

API_KEY = os.environ["SEOSCORE_API_KEY"]
PREVIEW_URL = os.environ["PREVIEW_URL"]   # e.g., https://pr-142-foo.vercel.app
PROD_URL = os.environ["PROD_URL"]         # e.g., https://yourdomain.com
BASE = "https://api.seoscoreapi.com"
THRESHOLD = -3.0

r = requests.post(
    f"{BASE}/compare",
    headers={"X-API-Key": API_KEY},
    json={"urls": [PREVIEW_URL, PROD_URL]},
    timeout=120,
)
r.raise_for_status()
data = r.json()

# /compare returns sites[] in submission order
preview_score = data["sites"][0]["score"]
prod_score    = data["sites"][1]["score"]
delta = preview_score - prod_score

print(f"Preview: {preview_score}  Prod: {prod_score}  Delta: {delta:+.1f}")

if delta <= THRESHOLD:
    print(f"::error::SEO regression of {delta:+.1f} points (threshold {THRESHOLD})")
    sys.exit(1)

That's the entire gate. Twenty lines. One API call (the /compare endpoint audits both sides in parallel on our side). 30 seconds wall time.

Pick a useful threshold

-3.0 is the threshold we've landed on for most teams after watching this run on real PRs for a year. It's:

Tight enough to catch real regressions. A 3-point drop is roughly "you broke a category" — typically performance from an unoptimized asset, or accessibility from a new component shipped without alt text.
Loose enough to avoid false positives. SEO Score has some run-to-run noise of ~1 point (LCP timing, network variance). -3.0 is comfortably outside that band.

For high-stakes pages (homepage, top landing page), tighten to -2.0. For experimental routes, loosen to -5.0. For categories you care about specifically, gate per-category:

prod_cats = data["sites"][1]["categories"]
prev_cats = data["sites"][0]["categories"]

for cat, threshold in {"performance": -4, "accessibility": -2, "seo": -3}.items():
    d = prev_cats[cat] - prod_cats[cat]
    if d <= threshold:
        print(f"::error::{cat} regressed {d:+.1f} (threshold {threshold})")
        sys.exit(1)

Per-category gates are what turn this from "the gate fails sometimes" into "the gate tells me exactly what's wrong before I open the PR."

GitHub Actions wiring

# .github/workflows/seo-gate.yml
name: SEO regression gate
on:
  deployment_status:
jobs:
  gate:
    if: github.event.deployment_status.state == 'success'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with: {python-version: "3.11"}
      - run: pip install requests
      - name: Run SEO gate
        env:
          SEOSCORE_API_KEY: ${{ secrets.SEOSCORE_API_KEY }}
          PREVIEW_URL: ${{ github.event.deployment_status.target_url }}
          PROD_URL: https://yourdomain.com
        run: python .ci/seo-gate.py

The deployment_status trigger waits for Vercel/Netlify/etc. to finish building the preview, then runs the gate against the preview URL it provides. That timing matters — running on pull_request instead would audit a preview that hasn't deployed yet and either error or audit stale content.

GitLab CI and CircleCI versions look essentially identical; see the generic CI/CD post for those.

What about multi-page gates?

A single-URL gate misses regressions on routes that didn't change in this PR but were affected by a global change — a layout shift, a font swap, a navigation rewrite. The fix is to audit a list of "critical pages" in batch:

CRITICAL_PAGES = [
    "/", "/pricing", "/blog", "/docs",
    "/blog/your-top-post", "/your-top-product",
]

prev_urls = [f"{PREVIEW_URL}{p}" for p in CRITICAL_PAGES]
prod_urls = [f"{PROD_URL}{p}" for p in CRITICAL_PAGES]

prev = requests.post(f"{BASE}/audit/batch", headers=h,
                    json={"urls": prev_urls}).json()["results"]
prod = requests.post(f"{BASE}/audit/batch", headers=h,
                    json={"urls": prod_urls}).json()["results"]

failures = []
for prev_r, prod_r in zip(prev, prod):
    delta = prev_r["score"] - prod_r["score"]
    if delta <= THRESHOLD:
        failures.append((prev_r["url"], delta))

if failures:
    for url, d in failures:
        print(f"::error::{url} regressed {d:+.1f}")
    sys.exit(1)

Batch audit is paid-only — this is where the gate stops being a Free-tier experiment and starts being part of your shipping process. For a team shipping 5–10 PRs a day and auditing 8 critical pages each, that's ~2,000 audits a month, which is exactly the Pro tier ($39/mo) target.

Posting results back to the PR

The failure message in CI is fine. The team will see it. But a comment on the PR with the actual scores is much more useful — it turns the gate from "the build is red" into "the homepage went from 92 to 87 because LCP regressed by 1.2s."

gh pr comment $PR_NUMBER --body "## SEO gate
| URL | Previous | This PR | Delta |
|-----|----------|---------|-------|
| / | 92 | 87 | -5.0 ❌ |
| /pricing | 88 | 88 | 0.0 ✅ |
| /docs | 84 | 84 | 0.0 ✅ |
"

Wire that up with the GitHub CLI inside the action and you've got the full pattern. The github-actions-seo-audit post has a more elaborate version with collapsed details and per-category breakdowns.

Using `/history` instead of `/compare`

/compare is the right call for a PR gate — both sides are audited fresh, no historical data needed, works on any plan with batch access. But for a post-merge check ("did main just regress from where it was yesterday?"), the history endpoint is cheaper:

hist = requests.get(
    f"{BASE}/history?url={PROD_URL}",
    headers={"X-API-Key": API_KEY},
).json()

today = hist["history"][-1]["score"]
yesterday = hist["history"][-2]["score"]
if today - yesterday <= -3.0:
    notify_slack(f"main regressed from {yesterday} to {today}")

Run that as a scheduled job after deploys merge. It uses one audit (today's) instead of two and gives you the same answer as long as you're already auditing the URL regularly.

What this catches that humans miss

A non-exhaustive list from real PRs we've seen the gate flag:

A "loading skeleton" component that shipped without an aria-label, knocking accessibility by 4 points sitewide.
A font swap from a local woff2 to a Google Fonts CDN, regressing LCP by 800ms and tanking performance.
A new "trust banner" with three external images, all 1.2MB JPEGs that should have been ~80KB WebP.
A Markdown→HTML refactor that dropped <h2> semantics inside blog posts.
A new "share to social" widget that injected six tracking scripts before paint.

Every one of these would have shipped silently and been discovered weeks later in a quarterly audit if anyone ran one. With a PR gate, they fail the build and get fixed before merge.

Cost of the gate vs cost of the regression

Two pricing observations:

The gate costs ~10 audits per PR (one batch of critical pages × pre/post). For a team shipping 100 PRs a month, that's 1,000 audits. Basic ($15/mo) covers it.
The regression it catches costs you weeks of organic traffic to a top page. One catch pays for the next several years of Basic.

We've yet to talk to a team that turned a pre-deploy SEO gate on and then turned it off again. It's the single highest-leverage piece of API tooling for a team that ships frequently.

Getting started

Copy the script, drop it in .ci/, wire it to your deployment platform's preview hook, set the threshold to -3.0, and ship a no-op PR to verify it runs. The first time it fails on a real regression — and it will, within a month — you'll know it was worth it.

For per-category gates and history-based deltas, grab a Basic key. For multi-page batch gates on a team shipping daily, the math points at Pro.

Catching SEO Regressions in Vercel Preview Deploys

Aaron VanSledright — Mon, 07 Sep 2026 14:00:05 +0000

Vercel preview deploys are the most underused SEO QA surface in modern frontend teams. Every PR gets a unique, real URL that loads in a real browser. That's exactly the environment an SEO audit needs — and it's a few minutes of YAML away from being a hard PR check.

This post is the production setup for catching SEO regressions on Vercel previews using SEO Score API. It's a sibling of Wiring an SEO analyzer API into a Next.js build but focused on the Vercel-specific gotchas.

The shape of the workflow

Three steps:

Wait for the Vercel preview to be live (it takes 30s–3min after PR push).
Audit the preview URL with SEO Score API.
Fail the PR check if the score is below the threshold.

The first step is where most teams get it wrong on the first try. The Vercel preview URL is available in the PR comment within seconds, but the deploy isn't ready for several minutes. Audit too early and you'll audit a 404 or an in-progress build.

The workflow

.github/workflows/seo-preview.yml:

name: SEO Preview Check
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  seo:
    runs-on: ubuntu-latest
    steps:
      - name: Wait for Vercel preview to be ready
        uses: patrickedqvist/wait-for-vercel-preview@v1.3.1
        id: preview
        with:
          token: ${{ secrets.GITHUB_TOKEN }}
          max_timeout: 600  # 10 min — Next.js builds can be slow

      - name: Audit preview
        id: audit
        env:
          KEY: ${{ secrets.SEO_KEY }}
        run: |
          URL="${{ steps.preview.outputs.url }}"
          RESP=$(curl -s -H "X-API-Key: $KEY" \
            "https://seoscoreapi.com/audit?url=$URL")
          SCORE=$(echo "$RESP" | jq '.score // 0')
          echo "score=$SCORE" >> $GITHUB_OUTPUT
          echo "## SEO Score: $SCORE" >> $GITHUB_STEP_SUMMARY
          echo "$RESP" | jq -r '.priorities[] | "- \(.issue)"' >> $GITHUB_STEP_SUMMARY

      - name: Threshold check
        run: |
          [ "${{ steps.audit.outputs.score }}" -ge 85 ] || exit 1

The wait-for-vercel-preview action listens for the Vercel deployment status webhook on the PR. It returns the URL only once the preview is actually serving traffic — that's the part you can't skip.

What we learned the hard way

A few things that bit us in production on the first version:

1. Don't audit immediately. Even after Vercel reports the preview is live, the CDN propagation takes another 5–10 seconds for global routes. Insert a sleep 15 after wait-for-vercel-preview if you see intermittent 502s from the audit.

2. Branch URLs change on rebase. The Vercel preview URL incorporates the branch name and commit SHA. After a force-push, the URL changes. wait-for-vercel-preview handles this if you call it fresh in every workflow run.

3. Auth-gated previews are invisible to us. If your Vercel preview deploys are behind Vercel Authentication (paid plans default to on), SEO Score API sees the auth wall, not your app. Turn off Vercel Authentication for previews, or use Vercel's protection-bypass-for-automation token and pass it as a header — we accept a ?bypass_token query parameter.

4. The first audit cold-starts the page. Next.js with on-demand rendering means the first request to a route compiles it. The audit will include that cold-start time. If your performance score is consistently 8–10 points lower than production, this is why. Run a warmup curl $URL step before the audit step and the numbers settle.

5. Set the threshold against main, not against the score you wish you had. A gate that fails every PR teaches developers to bypass it. See Pre-Deploy SEO Gates for how to pick the right threshold.

Multi-page auditing

The example above audits one URL. Most teams want to audit a small list of routes — the ones that matter for SEO, like /, /pricing, /signup, and the top 3–5 product pages.

URLS=("$URL/" "$URL/pricing" "$URL/signup" "$URL/docs")
FAIL=0
for u in "${URLS[@]}"; do
  S=$(curl -s -H "X-API-Key: $KEY" "https://seoscoreapi.com/audit?url=$u" | jq '.score // 0')
  echo "  $u → $S"
  [ "$S" -lt 85 ] && FAIL=1
done
exit $FAIL

Four URLs × ~10 PRs/day × 22 working days = ~880 audits/month. That fits in the Basic plan ($15/mo, 1,000 audits) with margin.

Posting the report back to the PR

GitHub's STEP_SUMMARY works, but a sticky PR comment is better — same content, doesn't get buried. The marocchino/sticky-pull-request-comment action handles the dedup:

- uses: marocchino/sticky-pull-request-comment@v2
  with:
    header: seo-score
    message: |
      ### SEO Preview Score: ${{ steps.audit.outputs.score }}
      Top issues:
      ${{ steps.audit.outputs.priorities }}

That comment updates in place on every push to the PR, so the latest score is always at the top of the conversation thread. Developers actually read those.

When to skip the gate

A seo-skip PR label that makes the workflow exit 0 is a one-line addition and it dramatically improves adoption. There are legitimate cases — intentional title changes, A/B test pages, copy experiments — where the gate should be silenced for one PR. Make that explicit and the rest of the team will stop disabling the workflow file when they're under deadline pressure.

What this gives you

Three months in, the win isn't the headline number going up — it's the absence of regressions. The gate catches the accidentally-deleted <title> tag, the broken canonical, the meta description someone overwrote in a CMS migration. Those don't show up in the metrics dashboard until traffic drops weeks later. The gate catches them before the PR merges.

That's the whole case for the Vercel preview audit.

Wiring an SEO Analyzer API into a Next.js Build

Aaron VanSledright — Mon, 31 Aug 2026 14:00:04 +0000

The most useful place to run an SEO analyzer API against a Next.js app isn't production — it's the preview deploy. By the time a regression hits production, you've already shipped it. By the time you find it in production, three more PRs have landed on top.

This post is the end-to-end setup for running SEO Score API against every Vercel preview deploy of a Next.js app, with a GitHub Action that fails the PR check if the score drops below a threshold. ~30 lines of YAML and one secret.

Why preview URLs and not production

Three reasons preview-deploy auditing beats production-deploy auditing:

You can block bad changes. A failed check on a preview is a PR you don't merge. A failed check on production is an incident.
Each PR is a clean diff. The score on main is a moving target; the score delta between main and feature/new-pricing is a number you can argue about in a PR review.
JS-rendered pages need a real URL. SEO Score API renders pages in headless Chrome, which means the preview deploy needs to actually be live. Vercel previews are. Local builds usually aren't.

The Vercel side

Vercel comments the preview URL on every PR. The format is stable enough to parse:

This pull request is being deployed to Vercel.
✅ Preview: https://your-app-git-feature-branch-team.vercel.app

We're going to grab that URL via the Vercel API instead of parsing the comment — same data, more reliable.

The GitHub Actions workflow

Save this as .github/workflows/seo-check.yml:

name: SEO Check
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  seo:
    runs-on: ubuntu-latest
    steps:
      - name: Wait for Vercel preview
        id: wait
        uses: patrickedqvist/wait-for-vercel-preview@v1.3.1
        with:
          token: ${{ secrets.GITHUB_TOKEN }}
          max_timeout: 300

      - name: Audit preview URL
        env:
          KEY: ${{ secrets.SEO_KEY }}
          URL: ${{ steps.wait.outputs.url }}
        run: |
          RESP=$(curl -s -H "X-API-Key: $KEY" \
            "https://seoscoreapi.com/audit?url=$URL")
          SCORE=$(echo "$RESP" | jq '.score')
          GRADE=$(echo "$RESP" | jq -r '.grade')
          echo "Score: $SCORE ($GRADE) on $URL"
          if [ "$SCORE" -lt 85 ]; then
            echo "::error::SEO score $SCORE is below threshold (85)"
            echo "$RESP" | jq '.priorities'
            exit 1
          fi

That's it. The action waits for the Vercel preview to be live (up to 5 minutes), audits it, and fails the check if the score is below 85. The failing case dumps the priorities array into the log so the PR author can see what to fix.

Setting the threshold

85 is the default we recommend, but it depends on your baseline. The right way to pick a threshold:

Run the audit against main to get your current baseline.
Set the threshold 2 points below that baseline.

If your main scores 92, threshold at 90. That way the gate fails on real regressions but tolerates the ±1 noise from network conditions and external API variance.

For sites that haven't been optimized yet (main scores 65), threshold at 65. Hold the line, then ratchet up as you improve. The pre-deploy SEO gates post has more on threshold strategy.

Auditing more than the homepage

The example above audits one URL — the preview root. Most apps have at least pricing, signup, and a handful of feature pages that matter just as much. The fix is a small bash loop:

URLS=(
  "$URL/"
  "$URL/pricing"
  "$URL/signup"
  "$URL/docs"
)
FAIL=0
for u in "${URLS[@]}"; do
  S=$(curl -s -H "X-API-Key: $KEY" "https://seoscoreapi.com/audit?url=$u" | jq '.score')
  echo "  $u → $S"
  [ "$S" -lt 85 ] && FAIL=1
done
exit $FAIL

That'll burn one audit per URL per PR. On the Basic plan ($15/mo, 1,000 audits), that comfortably covers a team shipping ~10 PRs/day audited against 3 URLs each.

What this catches that Lighthouse doesn't

Lighthouse runs in your CI by default if you use Vercel — but Lighthouse is Web Vitals first, SEO second. SEO Score API runs 83 checks specifically about SEO: title structure, meta description presence, canonical tags, schema validity, OpenGraph completeness, internal linking, AI-readability signals, robot directives.

You can run both. They overlap maybe 10% — there's no good reason not to gate on both.

What to do when a developer's PR fails the gate

Two things help adoption:

Print the priorities array in the failure log. The default response includes a sorted list of top remediation suggestions. Show them in the GitHub check output and you've turned the gate from "no, your PR is bad" into "yes, and here's what to fix."
Allow override via PR label. Add a seo-skip label that makes the workflow exit 0. There are legitimate cases (intentional title changes, A/B test pages) where the gate should be silenced. Don't make it impossible — just make it explicit.

Both of those keep the gate from becoming the kind of CI check that everyone learns to ignore.

How to Automate SEO Audits with n8n and SEO Score API

Aaron VanSledright — Mon, 24 Aug 2026 14:00:03 +0000

n8n is an open-source workflow automation platform — think Zapier but self-hosted and developer-friendly. Combined with the SEO Score API, you can build powerful SEO automation workflows without writing backend code. Schedule audits, route results to Slack or Google Sheets, and trigger alerts entirely through a visual editor.

What is n8n and how does it relate to SEO automation?

n8n is a self-hostable, node-based workflow automation tool that connects APIs, databases, and services without custom glue code. For SEO automation, it means you can schedule audits, route results to Slack or Google Sheets, and trigger alerts — all through a visual editor, with no backend server to maintain. Unlike hosted tools like Zapier, n8n runs on your own infrastructure, which means no per-task pricing and no data leaving your environment.

How does the SEO Score API n8n node work?

The SEO Score API n8n node is a purpose-built community node that wraps the /audit and /audit/batch endpoints. You configure your API key once in the node credentials, then connect it into any workflow. It handles authentication, passes your URL, and returns the full audit JSON — score, grade, and issue list — as node output data for downstream nodes to consume. Every field in the response is addressable using n8n's expression syntax.

Where do you install n8n-nodes-seoscoreapi?

Install the official community node directly from the n8n UI under Settings > Community Nodes > Install, entering n8n-nodes-seoscoreapi. On a self-hosted instance, you can also run npm install n8n-nodes-seoscoreapi and restart the n8n process. Once installed, the SEO Score API node appears in your node palette alongside other integrations. You only need to enter your API key once — n8n stores it in the node credentials and reuses it across every workflow that calls the node.

How do you set up an automated SEO audit workflow in n8n?

The three most common SEO automation workflows are weekly reports, bulk client audits, and competitive monitoring. Each follows the same pattern: a trigger node fires on a schedule, the SEO Score API node runs the audit, and downstream nodes route the results.

Weekly SEO Audit Report — audit your site every Monday and send results to Slack. Add a Cron node set to run at 9am on Mondays, connect a SEO Score API node with your target URL, add an IF node to check whether the score is below your threshold (for example, 80), then add a Slack node to post results to your channel.

Bulk Client Audits — import client URLs from a Google Sheet, audit each one, and write results back. Use a Google Sheets node to read URLs from column A, loop through them with a SEO Score API node, and write score and grade back to columns B and C. This workflow replaces hours of manual auditing with a single scheduled run.

Competitive Monitoring — track competitor SEO scores over time and alert on significant changes. Set a Cron node to run daily at midnight, audit competitor URLs with the SEO Score API node, use an IF node to check for score changes greater than 5 points, and send an email alert when something shifts.

What does the SEO Score API n8n node output?

The node returns the full audit JSON object as its output data, including score (0–100), grade (A+ to F), priorities (an array of issues with severity and description), and all 28 individual check results. Downstream nodes can reference any field using n8n's expression syntax — for example, {{ $json.score }} to branch on score or {{ $json.grade }} to include in a notification message. The structured output makes it easy to filter issues by severity, extract specific checks, or aggregate results across multiple URLs in the same workflow run.

Using the HTTP Request Node as an alternative

If you prefer not to install a community node, the built-in HTTP Request node works directly with the SEO Score API. Set the method to GET, enter https://seoscoreapi.com/audit as the URL, and add your target URL as a query parameter. Include your API key in the X-API-Key request header. The response is identical to the community node output — you get the same score, grade, and check data, and can reference it downstream using the same n8n expression syntax. The community node is slightly more convenient for credentials management, but the HTTP Request approach works on any n8n instance without additional packages.

Get Started

The free plan gives you 2 audits per day — enough to build and test your first workflow. Create a free account at seoscoreapi.com, install the n8n community node or configure the HTTP Request node, and connect your first workflow in under 5 minutes. For agencies auditing 10 or more client sites, the Pro plan at $39 per month includes batch auditing across multiple URLs in a single workflow step, along with monitoring and historical score tracking.

Frequently Asked Questions

Here are the most common questions about automating SEO audits with n8n and SEO Score API.

What is n8n and how does it relate to SEO automation?

n8n is an open-source, self-hostable workflow automation platform that connects APIs and services through a visual node editor. For SEO, it lets you schedule audits, route results to Slack or Sheets, and trigger alerts — without writing or maintaining custom backend code. Because n8n is self-hosted, there are no per-task fees and your audit data stays in your own environment.

How does the SEO Score API n8n node work?

The n8n-nodes-seoscoreapi community node wraps the SEO Score API endpoints. You enter your API key in the node credentials once, point it at a URL, and it returns the full audit JSON — score, grade, priorities, and all 28 check results — as structured output for subsequent workflow nodes. Credentials are stored securely and reused across every workflow that includes the node.

How do you set up an automated SEO audit workflow in n8n?

Add a Cron trigger node set to your desired schedule, connect a SEO Score API node with your target URL, then branch with an IF node on score thresholds. Connect a Slack, email, or Google Sheets node to deliver results. The whole workflow takes under five minutes to configure and runs automatically on every scheduled trigger without manual intervention.

What does the SEO Score API n8n node output?

The node outputs the full audit JSON including score, grade, priorities (issues with severity labels), and all individual check results. You can reference any field downstream using n8n expressions like {{ $json.score }} to power conditional logic or notification messages. The priorities array includes severity labels — critical, warning, and info — so you can filter alerts to only the most important issues.

Where do you install n8n-nodes-seoscoreapi?

Install via the n8n UI at Settings > Community Nodes > Install, entering n8n-nodes-seoscoreapi. Alternatively, install via npm with npm install n8n-nodes-seoscoreapi on a self-hosted instance. The node then appears in your node palette under the SEO Score API category. No restart is required on cloud-hosted n8n instances after installation.

Claude Code SEO Skill: Audits in Your Terminal

Aaron VanSledright — Mon, 17 Aug 2026 14:00:03 +0000

The Claude Code SEO Skill is a custom slash-command integration that runs SEO Score API audits directly in your terminal — no browser tabs, no copy-pasting URLs, no context switching. It supports single-URL audits, batch checks, site comparisons, and specific signal inspections.

Built as a wrapper around SEO Score API, the skill translates natural-language requests into API calls and formats results as readable terminal output. Type /seo-score, describe what you want, and get structured scores and priorities in seconds.

What Is the Claude Code SEO Skill?

The Claude Code SEO skill is a custom slash-command integration that lets you run SEO audits directly inside Claude Code sessions. The skill is a wrapper around the SEO Score API — it translates natural language requests into API calls and formats the results as readable terminal output, without requiring you to leave your coding environment.

The skill supports auditing individual URLs, batch-checking multiple pages, comparing two sites side by side, and inspecting specific SEO signals like meta tags, heading structure, and canonical configuration. It's designed for developers who want SEO data inline with their workflow, not as a separate tool to manage.

How Do You Install the SEO Score Skill in Claude Code?

Installing the skill takes under two minutes. Clone or download the skill files into your Claude Code skills directory:

mkdir -p ~/.claude/skills/seo-score/scripts
curl -sL https://seoscoreapi.com/skills/seo-score/SKILL.md \
  -o ~/.claude/skills/seo-score/SKILL.md
curl -sL https://seoscoreapi.com/skills/seo-score/seo_audit.py \
  -o ~/.claude/skills/seo-score/scripts/seo_audit.py
chmod +x ~/.claude/skills/seo-score/scripts/seo_audit.py

Then set your API key as an environment variable:

export SEO_SCORE_API_KEY="your_key_here"

The API key is optional for single URL audits — the skill uses the demo endpoint if no key is present, which allows a few free audits without signup. For batch audits, comparisons, and higher volume use, you'll need a key. Get one free at seoscoreapi.com.

Once installed, restart Claude Code and the /seo-score command becomes available in any session.

What Commands Does the SEO Score Skill Support?

The skill responds to natural language, so you don't need to memorize a command syntax. These phrasings all work:

Audit a URL:

"Audit https://example.com"
"Check the SEO score for my homepage"
"What's the SEO score for this URL?"

Batch check multiple pages:

"Audit these five URLs: [list]"
"Check SEO for all pages in my sitemap"
"Run a batch audit on these pages"

Compare two sites:

"Compare https://mysite.com vs https://competitor.com"
"Which site scores better for SEO?"
"Show me the SEO difference between these two domains"

Inspect specific signals:

"What meta tags does example.com use?"
"Check if this page has a canonical tag"
"Show me the heading structure for this URL"

The skill formats output as structured terminal text — score, grade, top issues, and a list of passing and failing checks. For batch runs, it displays a summary table so you can spot weak pages at a glance.

How Does the Skill Connect to the SEO Score API?

The skill calls the SEO Score API over HTTPS. When you make a request, Claude Code invokes the seo_audit.py script in the background, which sends a GET request to the /audit endpoint (or /audit/batch for multi-URL requests) with your API key in the X-API-Key header.

The API response — a JSON object containing score, grade, up to 83 individual check results, and fix recommendations — is passed back to Claude, which formats and summarizes it for you. On Starter plan and above, the response also includes SXO (Search Experience), AEO (Answer Engine), and AIO (AI Optimization) scores, each with their own grade and check breakdown. No data is stored locally; the skill is a thin client that calls the API and displays the results.

Request flow:
Claude Code → seo_audit.py → SEO Score API → JSON response → Claude formats output

The skill respects the rate limits of your plan. If you hit a limit mid-session, it will tell you and suggest when to retry. For high-volume use cases like auditing a full site during a build, the Pro or Ultra plan is recommended.

Which SEO Score API Plan Works with the Claude Code Skill?

All plans work with the skill, including the free tier:

Plan	Audits	Best For
Free	2/day	Quick checks during development
Starter	200/month	Regular audits on personal or small client projects
Basic	1,000/month	Teams running audits across multiple projects
Pro	5,000/month	Agencies or CI/CD pipelines with high audit volume
Ultra	25,000/month	Enterprise use or large-scale automated workflows

For individual developers, the Starter plan at $5/month covers most use cases — 200 audits is enough for daily checks across several projects with headroom to spare. If you're using the skill in a CI/CD pipeline or running audits automatically on each deploy, Pro gives you the rate limits to handle that without throttling.

Why Use the Skill Instead of the API Directly?

The skill adds value in specific developer scenarios:

During active development — check SEO signals on a staging URL without switching context to a browser or API client
When reviewing PRs — ask Claude to audit a preview deployment URL as part of your code review
While writing content — confirm a page's meta tags and heading structure are correct before publishing
For quick comparisons — benchmark your score against a competitor while you're already in a session working on something else

If you prefer scripting directly against the API — for example, in a CI pipeline, a Python script, or an n8n workflow — the skill is not the right tool for that. Use the API or one of the official SDKs (Python, Node.js) instead. The skill is optimized for interactive, in-session use inside Claude Code.

What Does the Skill Output Look Like?

After running an audit, you'll see output structured like this:

SEO Audit: https://example.com
Score: 78/100 (B)

Top Issues:
  - [CRITICAL] Missing Open Graph image tag
  - [HIGH] H1 tag not found
  - [MEDIUM] Page load time exceeds 3s threshold

SXO: 81/100 (A-)  AEO: 52/100 (C+)  AIO: 68/100 (B)

Report: https://seoscoreapi.com/report/example.com

The SXO, AEO, and AIO scores appear automatically on Starter plan and above — no extra flags needed. The full report link is shareable and can be pasted into a PR comment, Slack message, or client email without any additional setup.

Build an AI SEO Agent: Automated Website Auditing with Python

Aaron VanSledright — Mon, 10 Aug 2026 14:00:03 +0000

AI agents are transforming SEO workflows. Instead of manually running audits, an AI agent can crawl your site, identify issues, prioritize fixes, and generate recommendations — all autonomously.

What is an AI SEO Agent?

An AI SEO agent is an automated program that combines structured audit data with language model reasoning to identify, prioritize, and explain SEO issues without human intervention. Rather than generating a static report, the agent interprets results and produces actionable recommendations on demand. The key distinction from a traditional script is the LLM layer: instead of hard-coded logic, the agent reasons about what the data means and what to do next.

What does the seoscoreapi Python SDK do?

The seoscoreapi Python SDK wraps the SEO Score API REST endpoints into simple function calls. It handles authentication, request formatting, and response parsing — so you call audit("https://example.com", api_key=key) and get back a structured dict with score, grade, and prioritized issue list. The SDK also exposes batch_audit() for auditing multiple URLs in a single call, and signup() for programmatically creating a free API key without visiting the dashboard.

The Architecture

An AI SEO agent uses three components: the SEO Score API to provide raw audit data (83 checks per URL on paid plans), a Python orchestration layer that loops through pages and collects results, and an LLM to interpret those results and generate human-readable recommendations. These three layers are loosely coupled — you can swap the LLM (GPT-4, Claude, Gemini) or extend the orchestration without touching the audit layer.

Manual Auditing vs. AI Agent: What Changes?

Capability	Manual workflow	AI SEO agent
Audit frequency	Weekly or monthly	Continuous or scheduled
URLs covered	5-20 by hand	500+ via batch API
Issue interpretation	Human reads raw data	LLM generates plain-English recommendations
Reporting	Manual copy-paste	Automated structured output
Alert on regressions	Check manually	Automated diff + notification
Cost per audit	Engineer time	$0-0.02 per URL via API

How do you build an AI SEO agent with Python?

Building the agent takes three steps. First, install the dependencies with pip install seoscoreapi openai. Then create the audit function: call signup("agent@yourdomain.com") to get a free API key, then pass that key and your target URL to audit(). The response includes a numeric score, letter grade, and a priorities list where each item has a severity label (critical, warning, or info) and a description of the issue. The third step is LLM analysis: pass the structured result into a prompt asking for recommendations, then call your LLM of choice to interpret the data and generate plain-English fixes.

from seoscoreapi import audit, signup
import openai

api_key = signup("agent@yourdomain.com")
result = audit("https://example.com", api_key=api_key)

prompt = f"""Analyze this SEO audit and provide 3 actionable recommendations:
Score: {result['score']}/100 ({result['grade']})
Issues: {result['priorities']}"""

response = openai.chat.completions.create(
    model="gpt-4",
    messages=[{"role": "user", "content": prompt}]
)
print(response.choices[0].message.content)

How do you automate weekly SEO audits?

To run audits on a schedule, use batch_audit() to audit an entire site in a single call, then wrap the script in a cron job or workflow tool like n8n. Pass a list of URLs — homepage, about, pricing, blog — and get back a list of structured results you can loop through. Combine with an email or Slack notification step to receive weekly score summaries and issue alerts automatically. For CI/CD pipelines, add the audit to your deploy script and fail the build if any URL drops below your target score threshold.

from seoscoreapi import batch_audit

urls = [
    "https://example.com",
    "https://example.com/about",
    "https://example.com/pricing",
    "https://example.com/blog",
]
results = batch_audit(urls, api_key=api_key)

What does the agent output after an audit?

After running an audit, the agent returns a structured response containing a numeric score (0–100), a letter grade (A+ to F), and a prioritized list of issues with severity labels (critical, warning, info). Each issue includes the check name, description, and recommended fix, making it ready to pipe directly into an LLM prompt or a downstream reporting tool.

Use Cases

Agency automation: Build an agent that audits all client sites weekly and sends reports
Content QA: Audit every new blog post before publishing to catch missing meta tags or heading issues
Competitive intelligence: Monitor competitor SEO scores daily and alert on changes
CrewAI / LangChain: Add SEO auditing as a callable tool in your AI agent framework
CI/CD quality gate: Run the agent on every deploy and fail the build if score drops below threshold
Bulk site migrations: Audit all pages before and after a migration to detect regressions
Client onboarding: Auto-generate a first-audit report for new agency clients on signup
Content freshness monitoring: Alert when a high-ranking page's SEO score drops significantly

Get Started

The free tier gives you 2 audits per day to build and test your agent. For production workloads, paid plans start at $5 per month and include batch auditing, monitoring, and up to 25,000 audits per month on the Ultra plan. No credit card is required to start — sign up with your email address and get your API key immediately.

Frequently Asked Questions

What is an AI SEO agent?

An AI SEO agent is an automated program that runs structured website audits and uses a language model to interpret results, prioritize issues, and generate actionable recommendations — removing the need for manual review at every step. The LLM layer transforms raw check data into plain-English fixes that developers and content teams can act on immediately.

What does the seoscoreapi Python SDK do?

The seoscoreapi SDK wraps the SEO Score API into simple Python function calls like audit() and batch_audit(). It handles authentication and response parsing, returning structured data with scores, grades, and issue priorities ready for downstream processing or LLM input. A signup() helper lets you programmatically create a free API key without a browser.

How do you build an AI SEO agent with Python?

Install seoscoreapi and openai via pip, call audit() with your target URL and API key, then pass the structured result — score, grade, and priorities — into an LLM prompt. The LLM interprets the data and generates specific, actionable recommendations based on detected issues. The entire setup takes under 20 lines of Python and runs from any script or scheduler.

How do you automate weekly SEO audits?

Use batch_audit() to audit multiple URLs in one call, then wrap the script in a cron job or n8n workflow to run on a schedule. Pair with a Slack or email notification step to receive weekly score summaries and issue alerts without any manual trigger. For CI/CD use, add a score threshold check to fail the pipeline when quality drops below your target.

What does the agent output after an audit?

The audit response includes a numeric score (0–100), a letter grade, and a prioritized issues list with severity labels (critical, warning, info). Each entry contains the check name, a description of the problem, and the recommended fix — structured for direct use in reports or LLM prompts. The consistent response format means the same prompt template works across every URL you audit.

Add SEO Checks to Your CI/CD Pipeline

Aaron VanSledright — Mon, 03 Aug 2026 14:00:03 +0000

Add SEO Checks to Your CI/CD Pipeline

Every deployment is a chance to accidentally break SEO. A developer removes a canonical tag, a build step strips meta descriptions, a config change adds noindex to production — and you don't find out until rankings drop weeks later. The fix is treating SEO like any other quality gate: run checks on every deployment and fail the build if something critical breaks.

Why Do SEO Checks Belong in CI/CD?

SEO regressions are invisible at deploy time. Unlike a broken API endpoint or a failing unit test, a missing <title> tag or an accidental noindex directive has no immediate error signal — it silently degrades over days or weeks as search engines recrawl and update their indexes. By the time rankings drop, the causal commit is buried under dozens of subsequent changes.

CI/CD SEO checks create the same feedback loop you have for code quality: if a deployment introduces an SEO regression, the pipeline fails, the developer sees the issue immediately, and it never reaches production.

Which Checks Matter Most in a Pipeline?

Not all 55 audit checks are equally critical at deploy time. These are the high-priority checks that justify a build failure:

Check	Why it matters	Failure threshold
Meta title	Missing or empty title tanks click-through rate	Must be present
Meta description	Direct impact on SERP snippet quality	Must be present
Canonical tag	Duplicate content and indexation issues	Must be present
Noindex directive	Accidentally blocking pages from Google	Must not be set on key pages
HTTPS	Required for ranking; marks page as insecure	Must pass
Overall score	Composite health indicator	Define your own threshold (e.g., ≥ 70)

GitHub Actions Workflow

Add this workflow to .github/workflows/seo-check.yml:

name: SEO Quality Gate

on:
  deployment_status:
  push:
    branches: [main]

jobs:
  seo-audit:
    runs-on: ubuntu-latest
    if: github.event.deployment_status.state == 'success' || github.event_name == 'push'

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: "3.11"

      - name: Install SEO Score API SDK
        run: pip install seoscoreapi

      - name: Run SEO audit
        env:
          SEO_API_KEY: ${{ secrets.SEO_API_KEY }}
          AUDIT_URL: "https://your-production-site.com"
          SCORE_THRESHOLD: "70"
        run: |
          python - <<'EOF'
          import os, sys
          from seoscoreapi import audit

          result = audit(os.environ["AUDIT_URL"], api_key=os.environ["SEO_API_KEY"])
          score = result["score"]
          grade = result["grade"]
          threshold = int(os.environ["SCORE_THRESHOLD"])

          print(f"SEO Score: {score}/100 ({grade})")

          failures = []
          checks = result.get("audit", {})

          if checks.get("meta", {}).get("title") == "fail":
              failures.append("CRITICAL: Missing meta title")
          if checks.get("meta", {}).get("description") == "fail":
              failures.append("CRITICAL: Missing meta description")
          if checks.get("meta", {}).get("canonical") == "fail":
              failures.append("CRITICAL: Missing canonical tag")
          if score < threshold:
              failures.append(f"Score {score} is below threshold {threshold}")

          if failures:
              print("\nSEO Quality Gate FAILED:")
              for f in failures:
                  print(f"  - {f}")
              sys.exit(1)
          else:
              print("SEO Quality Gate PASSED")
          EOF

Store your API key as a GitHub Actions secret: Settings > Secrets and variables > Actions > New repository secret named SEO_API_KEY.

How to Fail a Build If Score Drops Below a Threshold

The pattern above uses sys.exit(1) to signal failure to the CI runner. Choose your threshold based on your baseline:

70 — reasonable starting point for most sites
80 — appropriate for established sites where any regression is significant
Custom — run an initial audit, note your current score, then set the threshold 5–10 points below it

To track score over time, write the result to a GitHub Actions output or post it as a PR comment using the GitHub API:

import os, json, urllib.request

score = result["score"]
comment = f"SEO Score: **{score}/100** ({result['grade']})"

pr_number = os.environ.get("PR_NUMBER")
if pr_number:
    data = json.dumps({"body": comment}).encode()
    req = urllib.request.Request(
        f"https://api.github.com/repos/{os.environ['GITHUB_REPOSITORY']}/issues/{pr_number}/comments",
        data=data,
        headers={"Authorization": f"token {os.environ['GITHUB_TOKEN']}", "Content-Type": "application/json"}
    )
    urllib.request.urlopen(req)

GitLab CI Example

Add to .gitlab-ci.yml:

seo-audit:
  stage: test
  image: python:3.11-slim
  script:
    - pip install seoscoreapi
    - |
      python - <<'EOF'
      import os, sys
      from seoscoreapi import audit

      result = audit("https://your-site.com", api_key=os.environ["SEO_API_KEY"])
      print(f"Score: {result['score']}/100 ({result['grade']})")

      if result["score"] < 70:
          print(f"FAIL: Score {result['score']} is below threshold 70")
          sys.exit(1)
      print("PASS: SEO quality gate cleared")
      EOF
  variables:
    SEO_API_KEY: $SEO_API_KEY
  only:
    - main
    - merge_requests

Set SEO_API_KEY in Settings > CI/CD > Variables in your GitLab project.

Python Script for Custom Pipelines

For non-GitHub/GitLab pipelines (Jenkins, CircleCI, Bitbucket Pipelines, or a local pre-deploy hook):

#!/usr/bin/env python3
"""seo_gate.py — run before any deployment to catch SEO regressions."""

import sys
import os
from seoscoreapi import audit

AUDIT_URL = os.environ.get("AUDIT_URL", "https://your-site.com")
API_KEY = os.environ["SEO_API_KEY"]
THRESHOLD = int(os.environ.get("SCORE_THRESHOLD", "70"))

result = audit(AUDIT_URL, api_key=API_KEY)
score = result["score"]
grade = result["grade"]
priorities = result.get("priorities", [])

print(f"\nSEO Audit: {AUDIT_URL}")
print(f"Score: {score}/100 ({grade})")

critical_issues = [p for p in priorities if p["severity"] == "critical"]

if critical_issues:
    print(f"\n{len(critical_issues)} critical issue(s) found:")
    for issue in critical_issues:
        print(f"  - {issue['issue']}")

if score < THRESHOLD or critical_issues:
    print(f"\nSEO Quality Gate: FAILED")
    sys.exit(1)

print(f"\nSEO Quality Gate: PASSED")
sys.exit(0)

Run it as a pipeline step: SEO_API_KEY=your_key python seo_gate.py

Get Started

Get a free API key — 2 audits/day, no credit card required
Add the workflow YAML to your repo
Set SEO_API_KEY as a pipeline secret
Push to main and watch the quality gate run

For teams running audits on every PR across multiple environments, the Basic plan ($15/mo) gives you 1,000 audits/month at 30 RPM.

Frequently Asked Questions

Why should SEO checks run in CI/CD rather than on a schedule?

Scheduled audits tell you that something broke — CI/CD checks tell you which deployment broke it. Running checks at deploy time means you catch regressions in the same pull request that introduced them, before they ever reach production and before any search engine recrawls the affected pages.

Which SEO checks are most important to fail a build on?

Fail the build on missing meta title, missing meta description, missing canonical tag, and any noindex directive on pages that should be indexed. These are high-impact, unambiguous regressions. Use a score threshold (e.g., ≥ 70) as a secondary gate to catch broader degradation across multiple minor issues.

How do you set up the SEO audit GitHub Action?

Add a workflow file to .github/workflows/seo-check.yml with a Python step that installs seoscoreapi, runs audit() against your production URL, checks for critical failures, and calls sys.exit(1) if any are found. Store your API key as a GitHub Actions secret named SEO_API_KEY.

Does the SEO audit check a staging URL or the live site?

You can audit either. For catching regressions before they go live, point the audit at your staging or preview URL after deployment but before promoting to production. For production monitoring, audit the live URL as a post-deploy verification step.

How many API calls does a CI/CD pipeline use?

Each audit call counts as one request against your monthly quota. A team pushing to main once a day uses about 30 audits/month — well within the free tier. If you audit on every PR (e.g., 10 PRs/day), the Starter plan at $5/mo (200 audits/month) covers most teams comfortably.

SEO Quality Gates with GitHub Actions

Aaron VanSledright — Mon, 27 Jul 2026 14:00:03 +0000

A broken meta tag in one pull request can silently tank your search rankings for weeks. By the time you spot the traffic drop in Google Search Console, the damage is done. The fix is simple: treat SEO like a test suite and run it automatically on every PR.

This guide walks through a real, production-ready GitHub Actions workflow using the SEO Audit Action. By the end, you'll have a workflow that audits your deployed site, posts a score report as a PR comment, and fails the build if the score drops below your threshold.

What Does the GitHub Actions SEO Audit Do?

Here's what the workflow does on every pull request:

Waits for your preview deployment (Vercel, Netlify, Cloudflare Pages, etc.)
Runs a 28-check SEO audit against the preview URL
Posts the score, grade, and top issues as a PR comment
Blocks the merge if the score is below 80

The full audit covers meta tags, technical SEO, Open Graph, performance, and accessibility — the same checks you'd get from running curl https://seoscoreapi.com/audit?url=yoursite.com.

What Are the Prerequisites?

You need two things:

A free SEO Score API key — sign up here (takes 10 seconds, no credit card)
A preview deployment in your pipeline — any system that gives you a URL for the PR branch (Vercel, Netlify, Render, etc.)

Add your API key as a repository secret:

Settings > Secrets and variables > Actions > New repository secret

Name: SEO_SCORE_API_KEY
Value: your API key

How Do You Add It to a Workflow?

Start with the simplest version. Create .github/workflows/seo-audit.yml:

name: SEO Audit

on:
  pull_request:
    branches: [main]

jobs:
  seo:
    runs-on: ubuntu-latest
    steps:
      - name: SEO Audit
        id: seo
        uses: SeoScoreAPI/seo-audit-action@v1
        with:
          url: "https://your-site.com"
          api-key: ${{ secrets.SEO_SCORE_API_KEY }}
          threshold: 80

That's a working quality gate in 15 lines. If the SEO score is below 80, the workflow fails and the PR can't merge (assuming you have branch protection rules enabled).

The action produces a markdown summary in the GitHub Actions UI automatically — you'll see the score, grade, issue count, and top 5 issues right in the workflow run.

How Do You Get PR Comments on Audit Results?

The summary in the Actions tab is useful, but most reviewers look at the PR conversation, not the workflow logs. Let's post the results as a PR comment:

name: SEO Audit

on:
  pull_request:
    branches: [main]

jobs:
  seo:
    runs-on: ubuntu-latest
    steps:
      - name: SEO Audit
        id: seo
        uses: SeoScoreAPI/seo-audit-action@v1
        with:
          url: "https://your-site.com"
          api-key: ${{ secrets.SEO_SCORE_API_KEY }}
          threshold: 80

      - name: Comment on PR
        if: always()
        uses: actions/github-script@v7
        with:
          script: |
            const score = '${{ steps.seo.outputs.score }}';
            const grade = '${{ steps.seo.outputs.grade }}';
            const issues = '${{ steps.seo.outputs.issues }}';
            const reportUrl = '${{ steps.seo.outputs.report-url }}';
            const passed = parseInt(score) >= 80;

            const body = [
              `## SEO Audit Results`,
              ``,
              `| Metric | Value |`,
              `|--------|-------|`,
              `| Score | **${score}/100** |`,
              `| Grade | **${grade}** |`,
              `| Issues | ${issues} |`,
              `| Threshold | 80 |`,
              `| Status | ${passed ? 'Passed' : 'Failed'} |`,
              ``,
              `[View Full Report](${reportUrl})`,
            ].join('\n');

            github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: context.issue.number,
              body
            });

The if: always() is important — it ensures the comment is posted even when the audit step fails due to a low score. Without it, a failing score would skip the comment step and you'd have to dig into the logs to find out what went wrong.

Real-World Example: Vercel Preview Deployments

Most teams don't audit a static production URL — they audit the preview deployment that Vercel (or Netlify, etc.) creates for each PR. Here's how to wire that up:

name: SEO Audit on Preview

on:
  pull_request:
    branches: [main]
    paths:
      - '**.html'
      - '**.jsx'
      - '**.tsx'
      - '**.vue'
      - '**.svelte'
      - 'content/**'
      - 'public/**'

jobs:
  seo:
    runs-on: ubuntu-latest
    steps:
      - name: Wait for Vercel Preview
        uses: patrickedqvist/wait-for-vercel-preview@v1.3.2
        id: preview
        with:
          token: ${{ secrets.GITHUB_TOKEN }}
          max_timeout: 300

      - name: SEO Audit
        id: seo
        uses: SeoScoreAPI/seo-audit-action@v1
        with:
          url: ${{ steps.preview.outputs.url }}
          api-key: ${{ secrets.SEO_SCORE_API_KEY }}
          threshold: 80

      - name: Comment on PR
        if: always()
        uses: actions/github-script@v7
        with:
          script: |
            const score = '${{ steps.seo.outputs.score }}';
            const grade = '${{ steps.seo.outputs.grade }}';
            const issues = '${{ steps.seo.outputs.issues }}';
            const reportUrl = '${{ steps.seo.outputs.report-url }}';
            const previewUrl = '${{ steps.preview.outputs.url }}';
            const passed = parseInt(score) >= 80;

            const emoji = passed ? '✅' : '❌';

            const body = [
              `## ${emoji} SEO Audit`,
              ``,
              `Audited: ${previewUrl}`,
              ``,
              `| Metric | Value |`,
              `|--------|-------|`,
              `| Score | **${score}/100** |`,
              `| Grade | **${grade}** |`,
              `| Issues | ${issues} |`,
              `| Threshold | 80 |`,
              ``,
              `[Full Report](${reportUrl})`,
            ].join('\n');

            github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: context.issue.number,
              body
            });

Three things worth noting about this version:

Path filters — the paths block ensures the audit only runs when files that affect SEO are changed. Backend-only PRs (API routes, database migrations, config changes) skip the audit entirely. This is important because audits cost API calls, and you don't want to burn them on changes that can't affect your SEO score.

Preview URL — instead of hardcoding a URL, we pull it from the Vercel preview deployment. Every PR gets its own preview URL, so you're auditing the actual changes in that PR, not the current production site.

Timeout — max_timeout: 300 gives Vercel 5 minutes to deploy. Adjust this based on your build times.

Netlify Variant

If you're on Netlify instead of Vercel, swap the preview step:

      - name: Wait for Netlify Preview
        uses: jakepartusch/wait-for-netlify-action@v1.4
        id: preview
        with:
          site_name: "your-netlify-site"
          max_timeout: 300

The rest of the workflow stays identical — just reference ${{ steps.preview.outputs.url }}.

Multi-Page Audits

For sites where SEO matters on more than one page, use a matrix strategy to audit multiple routes:

jobs:
  seo:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        path: ['/', '/pricing', '/blog', '/docs']
    steps:
      - name: SEO Audit - ${{ matrix.path }}
        id: seo
        uses: SeoScoreAPI/seo-audit-action@v1
        with:
          url: "https://your-site.com${{ matrix.path }}"
          api-key: ${{ secrets.SEO_SCORE_API_KEY }}
          threshold: 80

This runs 4 parallel audits — one per page. If any page drops below 80, that specific job fails. You can see exactly which page regressed in the Actions UI.

For larger sites (10+ pages), use the batch audit endpoint with a script step instead of the matrix approach to use fewer API calls.

How Do You Set Up Branch Protection?

The workflow only blocks merges if you configure branch protection:

Go to Settings > Branches > Branch protection rules
Add a rule for main
Check Require status checks to pass before merging
Search for and add the SEO Audit check

Now any PR where the SEO score drops below your threshold literally cannot be merged until the issues are fixed.

Choosing Your Threshold

Threshold	Best For
90	Marketing sites, landing pages where SEO directly drives revenue
80	Most production sites — catches real issues without false positives
70	Apps with some public-facing pages where SEO is secondary
60	Internal tools with minimal SEO requirements

Start at 70 if your site has existing issues, then ratchet up to 80 once the team has fixed the backlog. Don't start at 90 — you'll frustrate developers with failures on day one and they'll disable the check.

Which Plans Support CI/CD Use?

The free tier gives you 2 audits/day, which works for solo projects with a couple PRs per week. For teams:

Plan	Audits/mo	Price	Good For
Starter	200	$5/mo	Small team, 1-2 PRs/day
Basic	1,000	$15/mo	Active team, multi-page audits
Pro	5,000	$39/mo	Multiple repos, matrix audits

All paid plans support CI/CD use. The free tier is sufficient for personal projects; Starter or above is recommended for active teams. Sign up free and upgrade when your PR volume outgrows the free tier.

The Complete Workflow

Here's the full production-ready workflow with all the pieces — preview deployment, PR comments, path filtering, and the quality gate:

name: SEO Quality Gate

on:
  pull_request:
    branches: [main]
    paths:
      - '**.html'
      - '**.jsx'
      - '**.tsx'
      - '**.vue'
      - '**.svelte'
      - 'content/**'
      - 'public/**'

jobs:
  seo-audit:
    runs-on: ubuntu-latest
    steps:
      - name: Wait for Preview Deploy
        uses: patrickedqvist/wait-for-vercel-preview@v1.3.2
        id: preview
        with:
          token: ${{ secrets.GITHUB_TOKEN }}
          max_timeout: 300

      - name: Run SEO Audit
        id: seo
        uses: SeoScoreAPI/seo-audit-action@v1
        with:
          url: ${{ steps.preview.outputs.url }}
          api-key: ${{ secrets.SEO_SCORE_API_KEY }}
          threshold: 80

      - name: Post Results to PR
        if: always()
        uses: actions/github-script@v7
        with:
          script: |
            const score = '${{ steps.seo.outputs.score }}';
            const grade = '${{ steps.seo.outputs.grade }}';
            const issues = '${{ steps.seo.outputs.issues }}';
            const reportUrl = '${{ steps.seo.outputs.report-url }}';
            const previewUrl = '${{ steps.preview.outputs.url }}';
            const passed = parseInt(score) >= 80;

            const emoji = passed ? '✅' : '❌';
            const status = passed ? 'Passed' : 'Failed — fix issues before merging';

            const body = [
              `## ${emoji} SEO Audit`,
              ``,
              `**${status}**`,
              ``,
              `| Metric | Value |`,
              `|--------|-------|`,
              `| Preview | ${previewUrl} |`,
              `| Score | **${score}/100** |`,
              `| Grade | **${grade}** |`,
              `| Issues | ${issues} |`,
              `| Threshold | 80 |`,
              ``,
              `[View Full Report →](${reportUrl})`,
            ].join('\n');

            github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: context.issue.number,
              body
            });

Copy that into .github/workflows/seo-audit.yml, add your SEO_SCORE_API_KEY secret, enable branch protection, and you have an automated SEO quality gate protecting your site from regressions on every pull request.

Frequently Asked Questions

What does the GitHub Actions SEO Audit action do?

The SEO Audit Action runs a 28-check SEO audit against your site on every pull request. It checks meta tags, technical SEO, Open Graph, performance, and accessibility, then posts a score and grade as a PR comment and fails the build if the score drops below your configured threshold.

How do you add the SEO audit to a GitHub Actions workflow?

Create .github/workflows/seo-audit.yml, add the SeoScoreAPI/seo-audit-action@v1 step with your url, api-key (stored as a repository secret), and a threshold value. The action installs automatically — no additional dependencies or setup scripts required.

What score threshold triggers a build failure?

The threshold is configurable via the threshold input parameter. The default recommendation is 80 for most production sites. Scores below your threshold fail the workflow step, which blocks the PR from merging when branch protection is enabled. Start at 70 for sites with existing issues, then raise it over time.

How do PR comments with audit results work?

Add a second step using actions/github-script@v7 with if: always(). It reads the score, grade, issues, and report-url outputs from the audit step and posts them as a formatted comment on the pull request. The if: always() ensures the comment appears even when the audit fails.

Which plans support CI/CD use with GitHub Actions?

All plans, including the free tier (2 audits/day), support CI/CD use. The free tier works for solo projects with a few PRs per week. For active teams, the Starter plan ($5/mo, 200 audits/month) or Basic plan ($15/mo, 1,000 audits/month) is recommended depending on PR volume and multi-page audit needs.

DEV Community: Aaron VanSledright

One Deep Audit for $12: Full Report, No Subscription

What you see for free

What $12 unlocks

Who this is for

When a pack or a plan costs less

How to buy one

Frequently asked questions

Is the $12 a subscription?

Does the unlock cover more than one site?

Do I need an account?

Replacing Screaming Frog with an API: A 10,000-URL Agency Workflow

What Screaming Frog is good at

What it isn't good at

The API-equivalent workflow

The crawl-discovery gap (and how to close it)

What the API does that the desktop can't

Cost comparison, honestly

What we keep Screaming Frog around for

The migration path

Getting started

One SEO Tools API, Five Workflows Your Team Probably Already Needs

Workflow 1: CI gates

Workflow 2: Scheduled monitoring

Workflow 3: AI agents

Workflow 4: Client and stakeholder reports

Workflow 5: Status badges

Why one endpoint instead of five

What ties the workflows together

The SEO Checker API: Pass/Fail SEO Checks for Code, Not Dashboards

What "pass/fail per check" actually means

Three workflows the pass/fail shape unlocks

Why structured pass/fail beats a score-only API

How it relates to dashboard tools

Getting started in five minutes

Pre-Deploy SEO Gates: Catch Score Regressions Before You Ship

What a pre-deploy SEO gate actually checks

The minimum viable gate

Pick a useful threshold

GitHub Actions wiring

What about multi-page gates?

Posting results back to the PR

Using /history instead of /compare

What this catches that humans miss

Cost of the gate vs cost of the regression

Getting started

Catching SEO Regressions in Vercel Preview Deploys

The shape of the workflow

The workflow

What we learned the hard way

Multi-page auditing

Posting the report back to the PR

When to skip the gate

What this gives you

Wiring an SEO Analyzer API into a Next.js Build

Why preview URLs and not production

The Vercel side

The GitHub Actions workflow

Setting the threshold

Auditing more than the homepage

What this catches that Lighthouse doesn't

What to do when a developer's PR fails the gate

How to Automate SEO Audits with n8n and SEO Score API

What is n8n and how does it relate to SEO automation?

How does the SEO Score API n8n node work?

Where do you install n8n-nodes-seoscoreapi?

How do you set up an automated SEO audit workflow in n8n?

What does the SEO Score API n8n node output?

Using the HTTP Request Node as an alternative

Get Started

Frequently Asked Questions

What is n8n and how does it relate to SEO automation?

How does the SEO Score API n8n node work?

How do you set up an automated SEO audit workflow in n8n?

What does the SEO Score API n8n node output?

Where do you install n8n-nodes-seoscoreapi?

Claude Code SEO Skill: Audits in Your Terminal

What Is the Claude Code SEO Skill?

How Do You Install the SEO Score Skill in Claude Code?

What Commands Does the SEO Score Skill Support?

Using `/history` instead of `/compare`