ifySEO
Sign inRun a scan
How it works

A URL in.
A pull request out.

Two engines, one loop. The scan engine measures everything underneath your page; the fix engine reads the report, edits your source, and opens the pull request. You review and merge.

◢ the_loopscan → fix → ship
  1. 01urlhttps://your-site.com/
  2. 02scan47 checks · 2.1 s · 6 issues
  3. 03fix3 issues · diff drafted
  4. 04propened — you review
The scan engine

From URL to a scored report, in six steps.

Every step of the scan is designed around one constraint: produce a real measurement, not a synthetic estimate, on a budget small enough that the loop fits in a minute.

  1. 01Step

    You drop a URL

    Any public page. Type it into the panel — no extension, no integration, no API key.

    The URL is normalized (`https://` prepended if missing), parsed, and the action redirects to a live status page that polls until the report is ready.

  2. 02Step

    The SSRF guard vets the target

    Before anything heavier runs, the URL is checked against an explicit deny list.

    Loopback (`127.0.0.0/8`), private networks (`10/8`, `172.16/12`, `192.168/16`), link-local (`169.254/16`), and cloud metadata endpoints (`169.254.169.254`) are blocked. The check resolves DNS so a hostname that points to a private IP is caught the same way.

  3. 03Step

    Trigger.dev queues the work

    The scan runs on a background worker, not inside the request.

    A headless render plus five collectors is far too heavy for a 60-second Vercel function. The action only enqueues a `scan_jobs` row, hands the job to Trigger.dev, and redirects to the live status page. The worker runs the rest.

  4. 04Step

    A real headless browser renders

    Chromium opens your page the way one of your visitors would.

    Puppeteer drives Chromium (locally) or `@sparticuz/chromium` (in production). For the Core Web Vitals pass the render is throttled via CDP to the `mobile-slow4g` profile — 150 ms RTT, 1.6 Mbps down, 4× CPU slowdown, mobile viewport. That's Lighthouse's mobile preset, not a synthetic guess.

  5. 05Step

    Five collectors run in one pass

    Robots, sitemap, metadata, Core Web Vitals, axe-core accessibility.

    Each collector is a pure signal producer — it returns raw data (a `PageMetadata`, a `PagePerformance`, a `PageAccessibility`, a `RobotsResult`, a `SitemapResult`). The crawler never decides what is a problem; it only measures.

  6. 06Step

    Signals become Issues, Issues become a score

    The scanner maps every signal into an `Issue` with severity and evidence.

    `map-metadata`, `map-sitemap`, `map-performance`, `map-accessibility`, `map-artifact` are the only places that decision is made. `computeScore` rolls every Issue up — severity points × category weight, clamped to 0 — and persists a `scan_reports` row.

Engine profile
RTT
150 ms
Down
1.6 Mbps
Up
750 Kbps
CPU
4× slowdown
Viewport
Mobile (360×640)

Lighthouse mobile preset, applied via CDP.

Why a real browser

Synthetic numbers lie. A render doesn't.

Most audit tools estimate Core Web Vitals from static analysis. ifySEO opens a real Chromium with the mobile-slow4g network and CPU profile, lets your page actually load, and reads what Google's `web-vitals` library reports — the same metric, the same way the browser would record it.

Note: CDP throttling is not Lighthouse's simulated throttling, so the numbers are directionally comparable to PageSpeed Insights but will not match it exactly. We are honest about that — see the engine docs.

The fix engine

From a report to a merged pull request.

Where most tools stop at telling you what is wrong, ifySEO has a second engine that takes the report, edits your source, and opens the pull request. You stay in control of the merge.

  1. 01Step

    Link a repository

    Install the ifySEO GitHub App on the repo you want fixed.

    The app asks for the narrowest scopes that let an agent open a PR: contents (read/write), pull requests (write), metadata (read). You pick exactly which repos the app sees.

  2. 02Step

    Pick the issues to fix

    From a report, tick the issues you want the AI to take on.

    Only the auto-fixable ones can be ticked — the engine narrows your selection to the issues it actually knows how to resolve. Free is read-only; Growth and Pro can run fixes.

  3. 03Step

    The agent edits your code

    An AI tool loop clones the repo on a worker, reads the issues, edits files.

    The run is isolated — it operates on a fresh clone in an ephemeral worker, with the same narrow GitHub App scopes. It cannot push to your default branch; it can only open a PR from its own working branch.

  4. 04Step

    A pull request opens. You review.

    ifySEO never merges. The PR lands in your repo with the diff and a summary.

    You read the change, run your CI, and merge — or close it. The number of fix runs per month is capped per plan (Growth: 10, Pro: 50) so the cost is bounded; the merge decision is always yours.

What we don't do

The promises we keep tight.

  • No bypassing authifySEO crawls only what a public, unauthenticated browser can see. Logged-in pages aren't scanned.
  • No bypassing robots.txtIf your site disallows our crawler, the scan stops and reports the block honestly.
  • No merging for youThe fix engine opens pull requests. It cannot, and will not, push to your default branch or merge.
  • No selling your dataScan targets and reports stay scoped to your account. No third-party share, no training data, no resale.
Read the privacy notice →See every signal

Watch the loop run.

Drop in a URL. Six steps, about a minute, one honest score.

See your score in under a minute. · No card · No setup