πŸ“‰ SEO Regression Auditor - Technical Audit + Diff vs Last Run avatar

πŸ“‰ SEO Regression Auditor - Technical Audit + Diff vs Last Run

Pricing

Pay per event

Go to Apify Store
πŸ“‰ SEO Regression Auditor - Technical Audit + Diff vs Last Run

πŸ“‰ SEO Regression Auditor - Technical Audit + Diff vs Last Run

πŸ” Six technical SEO audits merged into one crawl β€” redirect chains, broken links, canonical issues, duplicate titles/meta, heading structure, indexability β€” then diffed against the last run so it reports what REGRESSED. βœ… Scores the site 0-100. First run is a baseline.

Pricing

Pay per event

Rating

0.0

(0)

Developer

mohamed alaya

mohamed alaya

Maintained by Community

Actor stats

0

Bookmarked

2

Total users

1

Monthly active users

2 days ago

Last modified

Categories

Share

SEO Regression Auditor

Six technical SEO audits, merged into one crawl, that DIFF against the last run and tell you what regressed. Most SEO tools give you a fresh list of problems every time you run them β€” this one remembers, so you find out the moment something breaks instead of noticing it three months later in a traffic graph.

The six audits

  1. Redirect chains β€” follows every redirect hop-by-hop, reports the full chain, flags anything over one hop and any loop.
  2. Broken links β€” every internal link discovered during the crawl gets a status check, reported with the page(s) that link to it.
  3. Canonical issues β€” missing canonical, conflicting canonicals (multiple different tags on one page), a canonical pointing at a different page, and whether it self-references.
  4. Title / meta description β€” missing, too long, too short, and duplicated across pages β€” the cross-page pass most single-page checkers skip entirely.
  5. Headings β€” missing H1, multiple H1s, and skipped heading levels (H1 straight to H3).
  6. Indexability β€” noindex via meta tag, robots.txt disallow rules, and orphan pages (listed in the sitemap but never linked, or linked but missing from the sitemap).

The regression engine

Every audit is stored in a named key-value store, keyed per site. On the next run, each finding is compared against the stored baseline:

  • NEW β€” an issue that wasn't there last time
  • FIXED β€” an issue that was there last time and is now gone
  • EXISTING β€” unchanged since last time (included unless onlyRegressions is on)

Plus a per-category delta and the score change between runs. The first run for any site is always a baseline β€” nothing is reported as a regression yet, because there is nothing to compare against.

Score

Every site gets a 0-100 score. It starts at 100 and loses points per finding (broken links and missing H1s/titles cost the most; a rotated redirect with one hop costs little). The score itself is stored and diffed too, so you get a scoreDelta between runs.

What this does NOT do

  • No JavaScript rendering. Pages are fetched as raw HTML; content injected client-side (React/Vue apps without SSR, lazy-loaded text) will not be seen. Point it at server-rendered pages, or pre-rendered/SSR output.
  • No Core Web Vitals or any real-user field data. This is a structural/content audit, not a performance audit β€” it does not measure LCP, INP, CLS, or anything from CrUX.
  • Broken-link checking is capped (maxLinksChecked) and uses a plain GET request, not a full browser β€” pages that require JS to render their links may under-report link coverage.
  • Orphan-page detection is only as good as the crawl: a page outside maxPages won't be seen as "linked" even if it truly is.

Typical use

Run it weekly or after every deploy. Point resetBaseline at true the first time you add a new site, then leave it off β€” every run after that tells you exactly what changed.