Skip to content

Features

The monitoring layer between your deploys and your traffic

Point PixyScan at a site and it establishes a baseline, then re-crawls on your schedule and reports the difference. 112 checks over every page it finds, with the URLs behind each failure and a written fix for every check.

Auditing tells you today. Monitoring tells you what changed.

Auditing tells you the state of your site today. Monitoring tells you what changed since the last time it was fine — which is the only question you can act on.

  1. Establish a baseline

    The first crawl records every page and runs all 112 checks. That run is the reference point — nothing is a "regression" until there is something to regress from.

  2. Re-crawl on a schedule

    Daily, weekly or monthly per site, in your timezone. Scanning often is the whole point, which is why it is not metered: no credits to ration, so you never hesitate before a re-scan.

  3. See what changed, not everything

    Each scan is compared with the previous one on the same branch and split into new, resolved and regressed. A list of 200 findings you already knew about is noise; the four that appeared this week are the work.

  4. Check a branch before it ships

    Scans carry the branch they ran against. A preview deploy is scanned as its own line of history, so it never becomes production's baseline — and you can see what a release would do before it does it.

  5. Fail the build when it matters

    Trigger a scan from CI with a per-site token, poll it, and read the result — including a pass/fail against the score threshold you set. Your pipeline decides what to do with that.

Everything it does, and nothing it doesn't

PixyScan is an SEO crawler and checker. It does not measure page speed, track rankings, or watch your competitors — there are good tools for those, and pretending otherwise would only waste your time.

  • Every finding tied to the exact pages

    A scan produces a health score and a list of failing checks by severity. Open any check to see every URL that fails it and what was found on each one — not a percentage with nothing behind it.

  • A full report for any single page

    One URL, everything recorded about it: title and meta with lengths, heading outline, readability grade, internal and external links with their anchor text and status codes, images, JSON-LD, security headers, hreflang and HTML head.

  • The fix, next to the problem

    Each of the 112 checks has a written guide — what it is, why it matters, how to fix it, with examples. It is in the product beside the finding, and on this site.

  • Every run kept

    Scan history is permanent and each run has its own screen: its score, the checks it failed, how long it took and which branch it measured. You can always go back to the run before the one that broke something.

  • Priced per site, not per seat or per scan

    Invite the whole team at no cost — a monitoring tool is more useful the more people watch it. Sites are the thing you are protecting, so sites are what you pay for.

  • Export anything you can see

    The issue list, the pages failing one check, and a single page's full report all export to CSV for a spreadsheet or a client report.

112 checks, in 14 groups you control

Turn a group off for a site and PixyScan stops running it and stops reporting it — scans get faster and quieter. Every check has its own guide.

Page SEO basics
Titles, meta descriptions, canonicals, H1–H6 structure, duplicate elements, indexability.
HTML head tags
charset, viewport, html lang, robots directives, author, site verification, referrer policy.
Social & Open Graph
og: and twitter: tags, image dimensions, locale, article metadata.
Structured data
JSON-LD parsed and validated per type — Organization, Product, FAQ, Article, Breadcrumb and more.
Image analysis
Alt text, width and height attributes, modern formats, descriptive filenames.
Semantic HTML
Whether key regions use real landmarks instead of bare divs, and figures carry captions.
Content & readability
Flesch–Kincaid grade level, word count, placeholder text, author attribution.
Link rel tags
Favicons, apple-touch-icon, RSS feeds, manifest, AMP links.
Crawl behaviour
robots.txt, sitemaps, redirect chains and loops, broken internal links, orphan pages.
HTTP security headers
HSTS, CSP, Referrer-Policy, X-Frame-Options, mixed content.
International SEO
hreflang pairs, x-default, self-referencing tags, RTL direction, per-language URLs.
URL parameters
Whether parameterised and faceted URLs are canonicalised, and canonicals stay clean.
AEO content signals
Readability scored for answer engines rather than only for people.
GEO / AI engine signals
llms.txt and llms-full.txt presence, and whether GPTBot, ClaudeBot, PerplexityBot, Google-Extended or CCBot are blocked in robots.txt.

Browse every check in the help centre →

Run it from your pipeline

Every site can issue a scan token. Trigger a crawl over HTTP, poll it, and read the result as JSON — the same crawl and the same checks as the dashboard.

# Trigger a scan
curl -X POST https://api.pixyscan.com/v1/scan \
  -H "Authorization: Bearer $PIXYSCAN_SCAN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"executionType":"crawl"}'
# → { "scanId": "..." }

# Poll it, then read the result
curl https://api.pixyscan.com/v1/scan/$SCAN_ID/progress \
  -H "Authorization: Bearer $PIXYSCAN_SCAN_TOKEN"

curl https://api.pixyscan.com/v1/scan/$SCAN_ID/result \
  -H "Authorization: Bearer $PIXYSCAN_SCAN_TOKEN"

Your pipeline decides what to do with the result — PixyScan does not post a status back to your pull request, so failing the build is your call and your script.

One site free, forever

No credit card, no credits to ration. Add a site and run a scan in a couple of minutes.

See pricing

Questions people ask first

We already use Semrush or Ahrefs. Why this too?

Keep them. Those are research tools — they tell you what to go after. They will not tell you that last night's deploy dropped the canonical off your category pages. PixyScan watches the site you already have and tells you what changed since it was last fine. Different job, works alongside.

How is this different from a free one-off audit?

An audit is checking for smoke once a year. This is the smoke detector. A single audit gives you a list you will mostly already know; the value here is the second scan and every one after it, because that is when a finding means something changed.

Couldn't a developer script this in an afternoon?

The crawl, yes. What a script does not have is memory of your last ninety deploys, a maintained library of 113 checks as Google shifts, or the judgement to separate a real regression from a cosmetic change. And somebody owns it forever. That is what you are paying us for.

We don't really have SEO problems.

Most teams do not — until a release introduces one and nobody is watching. Connect one site free and leave it for two weeks. If nothing worth knowing turns up, walk away.

Does it measure page speed or Core Web Vitals?

No. PixyScan is an SEO crawler, not a performance tool. It does not run Lighthouse and does not report LCP, INP or CLS. Use PageSpeed Insights or your RUM provider for those.

Will it email me when something breaks?

Not yet, and we are not going to pretend otherwise. Today you see regressions when you open a scan: the comparison against the previous run on the same branch is waiting for you, and scan history keeps every run. Notification delivery is the next thing on this list, not a shipped feature.

Can it stop a bad release from merging?

Partly, and here is the exact line. You can trigger a scan from CI with a per-site token, poll it, and read a result that includes a pass/fail against your score threshold — enough for your pipeline to fail the build. What does not exist is a GitHub app that posts a comment on the pull request or blocks the merge itself. Your script makes that call.

How does it handle JavaScript-rendered pages?

PixyScan reads the server-rendered HTML, which is what a crawler sees first. That is deliberate: several checks exist precisely to catch metadata that only appears after JavaScript runs. If your title is injected client-side, PixyScan will tell you.

Can I scan a preview deploy without ruining my production trend?

Yes — that is what branches are for. Every scan records the branch it ran against, and a scan is only ever compared with the previous scan on the same branch. A preview run never becomes production's baseline.

How is it priced?

Per site. Not per credit, so re-scanning costs nothing extra and you never hesitate before checking. Not per seat, so invite everyone — the tool is more useful the more people watch it.