How to read your SRPS score and fix it with… | Suparanku IT

What the Site audit looks at

Most of Suparanku measures the outside — what AI assistants say about your brand. The Site audit looks at the inside: your own site, seen the way AI crawlers and answer engines see it. It runs two ways. The domain audit checks site-wide signals once — HTTPS, your robots.txt, whether citation and retrieval bots are allowed, sitemaps, hreflang consistency, organization markup. The page audit runs the same lens over individual URLs: status code, canonical and noindex, a single H1, title and description length, structured data that carries real facts, freshness, image alt coverage, and the health of the links on the page.

Together they answer one question an external visibility tracker can’t: if AI can’t find or read your page, why not?

How to read your SRPS score

Every page gets an SRPS — a 0–100 readiness score. It’s a weighted ratio, not a checklist percentage. Each check carries a weight by priority: low = 1, medium = 3, high = 9. A passing check contributes its full weight, a warning contributes about a third, and a failure contributes nothing. The score is the share of weight you earned out of the weight that applied.

Read the tiers like a traffic light:

• 80–100 — good. AI can read and cite the page.
• 60–79 — needs work. Real gaps, none fatal.
• below 60 — poor. Something important is blocking you.

Two details change how you read a low number:

• Hard cap at 30. A fatal, high-priority failure — a non-200 status, a noindex on a page you want cited, or citation bots blocked at the domain — caps the score at 30 no matter how much else passes. A page stuck near 30 almost always has one of these; fix that first.
• SRPS vs SRPS+. Plain SRPS is computed from the raw HTML (the fast audit). SRPS+ comes from the deep audit, which renders the page like a browser and adds extraction-quality checks. SRPS+ shows a dash until you run a deep audit on that page. If SRPS is healthy but SRPS+ is weak, your content depends on JavaScript that crawlers may not execute.

The domain score is not the average of your page scores. It pools every check — page checks and domain checks — into one ratio, so a broken site-wide signal genuinely drags the whole number down instead of being averaged away.

One more thing worth knowing: pages that AI already cites get their checks weighted up a step (a medium becomes a high). A small flaw on a page that’s actually winning citations is more urgent than the same flaw on a page nobody reads — and the score reflects that.

Why a page scores low

In practice, low scores cluster into a few causes:

• Access. robots.txt blocks a retrieval or citation bot, or a conflicting Allow/Disallow rule does it by accident. Nothing else matters if the crawler never arrives.
• Indexability. A stray noindex, a canonical pointing at a different page, or a non-200 status quietly removes the page from consideration.
• Thin structure. No structured data, or markup that exists but carries no real facts (a Product with no price or availability), or a missing/oversized title and description.
• Graph problems. A page no internal content links to (an orphan), or one buried many clicks deep, is hard for any crawler — and any reader — to reach.

Manual checks (for example, Indexed in Google or a Knowledge Panel) always count toward the denominator and sit at zero until you confirm them done. That’s deliberate: they pull a new site’s score down honestly, and each one comes with an action.

Fixing it with a technical brief

This is the part that makes the score actionable. Every issue the audit raises can generate a technical fix-it brief — the same one-click brief the Growth engine produces for content, adapted for technical work. It doesn’t just say “add structured data.” It gives you:

• the problem and exactly where it is;
• why it matters, with the playbook tactic and how strong the evidence behind it is;
• the step-by-step fix, including a ready-to-paste artifact — the robots.txt line, the JSON-LD block, or the corrected meta tag;
• acceptance criteria, so you know when it’s actually closed.

Because the brief is plain, structured text, you can hand it straight to a developer, drop it into a ticket, or paste it into an AI agent and let it open the pull request. When the fix ships, the next audit re-checks the signal: pass, and the recommendation auto-resolves; still failing, and it stays open. The loop closes on evidence, not on someone remembering to tick a box.

A weekly habit

You don’t need to run a full crawl every day. Let the fast audit refresh on its weekly cadence to keep SRPS current, and spend your deep-audit budget on the handful of pages that matter most — the ones AI already cites, or the ones you’re trying to get cited. Read the domain score for the site-wide blockers, sort pages by SRPS to find the worst offenders, and work the briefs from the top. Fix access first, indexability next, then structure — and watch the score climb as AI starts to find, read, and cite the pages you care about.