I open-sourced my page-readiness scorer

I built a small tool called PageReady. It scores a web page for two kinds of readiness, and today I’m putting it on GitHub for anyone to use however they want. MIT license. As-is. No support desk.

Repo: https://github.com/TygartMedia/page-ready

What it actually checks

Most page audits give you a score out of 100 and a list of suggestions you’ll never get to. PageReady is binary: PASS or FAIL, on two axes.

1. Citation readiness (AEO). Can an AI answer engine cite this page? It checks for one H1, a sane heading hierarchy, JSON-LD structured data, a table signal, and FAQ-style questions — the things that make a page quotable.

2. Agent interaction readiness (DOM). Can an AI agent actually use this page? It checks for a main landmark, named controls, semantic interactive elements, heading order, and form labels — the things that make a page operable.

Overall PASS requires both. And here’s the insight that made the tool worth building: fixing your headings can lift the shared heading gate, but it does nothing for clickable div cards. A page can be perfectly citable and completely unusable by an agent. Most audits conflate the two. They’re different problems.

How you use it

It’s a local command-line tool, a stdio MCP server, and an optional HTTP API you can host yourself (there are Cloud Run deploy scripts). No API keys required — it scores pages directly, nothing phones home.

As an MCP server it exposes three tools:

• score_page — score one public URL, returns a JSON scorecard
• score_site — score a batch of URLs, with pass/fail counts
• explain_gates — describe every check and the overall PASS rule

Point your agent at it and ask whether a page is ready. Exit code 0 means PASS. Exit code 1 means FAIL. That’s the whole interface.

Why open source, why as-is

The scoring logic was never going to be the moat. It’s a commodity check — the value is in knowing which pages to run it on and what to do with the answer. That’s the work I do with clients every week, and no repo replaces it.

So the repo is bait, not the business. If it saves another developer an afternoon, good. If someone forks it and makes it better, better. If a competitor forks it closed and sells it — the MIT license allows that, and I’m fine with it. The relationships are the hook; the tool is just proof I do the work.

As-is means as-is. No SLA, no roadmap, no support promise. Issues are read on a best-effort basis. I’d rather ship something useful with no promises than maintain something mediocre with a changelog.

The receipts

Before publishing, the repo went through a pre-publish scrub (secrets sweep, license, README rewrite), then three independent model reviews: a security audit (SAFE), a correctness pass (no bugs), and a docs review (pass). The scrub caught one hardcoded cloud project ID, which is now an environment variable (GCP_PROJECT). That’s the whole incident report.

Use it however you want. That’s the point.