The Website Readiness Score summarizes evidence collected from the pages included in a scan. It is a directional indicator of how well those sampled pages expose selected SEO, technical, accessibility, structured-data, business-identity, and content signals. It is not a Google ranking score, an AI citation probability, a complete-site grade, or a substitute for professional review.
What the Website Readiness Score represents
The score condenses a versioned set of deterministic checks into a practical overview. Deterministic means the scanner applies defined rules to the evidence it retrieves instead of asking a language model to guess whether the website looks good. The report should identify the scoring-model version so a later rescan can be interpreted against the correct rules.
The score applies only to the eligible pages and evidence analyzed during that scan. A free sample does not become a verified whole-site score simply because it produces one number. Pages that were private, blocked, undiscovered, excluded, timed out, or outside the crawl limit are not silently treated as reviewed.
What this means for your website
Use the score as a progress marker. Read the findings, fix a confirmed cause, verify the public output, and run another scan under a comparable scope. If the evidence changes as expected, the new report can show whether the automated checks now see the repair.
Do not chase points without understanding the page. Removing an intentional noindex directive from a private or duplicate page could make the website worse. Adding generic text to increase a content measurement can make the page less useful. The correct repair depends on the page's purpose.
Categories and individual checks
Each check examines a defined condition, such as whether a sampled page returned an eligible response, exposed an indexing directive, declared a canonical URL, used a clear title or heading, linked to other useful pages, supplied valid structured data, or provided an observable business or content signal.
Related checks are grouped so the report can show where readiness is strongest and where several findings share a common cause. The final public category names and any disclosed weights must match the deployed scanner configuration:
Final categories and approved weight disclosure: {SCORE_CATEGORIES}
Pass, warning, and failure definitions
The page brief uses pass, warning, and failure as working documentation terms. Final public labels must be synchronized with the scanner interface before publication. Whatever labels are approved, the meaning should remain evidence-based and visible in text rather than communicated by color alone.
| Working term | Meaning | What it does not mean |
|---|---|---|
| Pass | The retrieved evidence satisfied the defined automated check within the scan's scope. | The page is perfect, will rank, meets every standard, or requires no human review. |
| Warning | The scanner observed a condition that may need context, improvement, or manual verification. | The page is necessarily broken or that the condition has a fixed ranking impact. |
| Failure | The evidence did not satisfy a defined check or revealed a condition the rule treats as a problem. | The website cannot rank, cannot be cited, or has failed a complete professional audit. |
| Not tested or unknown | The scanner lacked sufficient eligible evidence, the condition was outside scope, or manual confirmation is required. | A pass or failure. Unknown evidence should not be converted into certainty. |
How severity differs from a check outcome
An outcome describes what a rule observed. Severity describes how urgently that finding may deserve attention within the methodology. They are related, but they are not the same thing. A failed check on a low-value page may have less practical impact than a crawler or indexing problem repeated across every service page.
Until the final public severity labels are approved, use this priority logic:
- Address conditions that prevent access, secure delivery, indexing eligibility, or reliable page retrieval first.
- Next, investigate repeated template, navigation, canonical, structured-data, or identity problems that affect many pages.
- Then improve page-level clarity, completeness, internal context, images, and supporting evidence.
- Keep informational observations available without presenting them as urgent failures.
Weighting methodology
The current implementation contract uses per-page severity deductions, category caps, and a weighted overall calculation. This prevents an unlimited number of repeated minor findings from distorting the score without bound, and it allows higher-priority checks to influence the result differently from informational observations.
The exact category names, deductions, caps, and weights are product configuration. They should be disclosed only at the level N8 Solutions approves and only after the deployed code, report language, and this page agree. A methodology page that publishes stale or approximate weights would create false transparency.
A repair can also affect more than one check. Correcting a template-level canonical problem, for example, may change evidence across several pages. The score should reflect the new retrieved evidence on the next scan rather than award points merely because someone marked a task complete.
Page sampling and crawl limits
The free scan examines a bounded sample of up to {FREE_SCAN_LIMIT} representative pages. The expanded report examines up to {FULL_SCAN_LIMIT} URLs under the confirmed product configuration. Discovery can be influenced by navigation, sitemaps, robots rules, redirects, host policy, timeouts, page size, authentication, and the crawl limit.
The report should distinguish at least the discovered, eligible, selected, analyzed, excluded, and failed-to-fetch counts where the production interface supports them. This prevents a user from mistaking “five pages analyzed” for “the entire website verified.”
When comparing two scans, use a similar target, scope, and website state. A score from a small sample and a score from a larger crawl are not automatically equivalent.
How recommendations are prioritized
A useful recommendation connects the finding to evidence and a verification step. It should identify the affected URL or element, explain the potential impact without promising a ranking effect, and direct the reader to the smallest appropriate repair.
- Confirm the evidence. Check that the live page still exposes the condition and that it is not an intentional configuration.
- Find the source and reach. Determine whether the issue comes from one article, a menu item, a template, a plugin, server configuration, or a shared data source.
- Repair dependencies first. Fix access and sitewide causes before editing several pages individually.
- Verify the rendered result. Clear relevant caches and inspect the public output.
- Rescan comparable pages. Confirm that the evidence changed and check for unintended side effects.
Known limitations
- Sampling: a bounded scan cannot claim complete coverage of pages it did not analyze.
- Automation: some accessibility, usability, content-quality, trust, and business-context questions require human judgment.
- Changing conditions: dynamic content, personalization, geolocation, testing, caching, intermittent failures, and third-party resources can change retrieved evidence.
- External systems: the scanner does not have access to Google or AI-platform ranking systems, private indexes, Search Console accounts, analytics, or unpublished platform decisions.
- Intent: an automated rule may detect a condition without knowing whether the page's business purpose makes that condition appropriate.
- Compliance: the score is not a legal, privacy, accessibility, or security certification.
How to improve the score and rescan responsibly
Start with findings that have clear evidence and broad reach. If an important page is unavailable, unintentionally excluded from indexing, served without HTTPS, or affected by a sitewide template error, investigate that before rewriting a minor description.
Keep a simple change record containing the original finding, affected pages, source of the issue, repair, publication time, caches cleared, and verification result. Then run a new Website Readiness Scan. If the score changes, confirm which evidence changed. If it does not, check whether the live output still contains the original condition.
Methodology version history
The public report and this methodology page should identify compatible versions. Update this history whenever a category, rule definition, severity, cap, weight, sampling method, or calculation changes materially.
| Date | Status | Change |
|---|---|---|
| 25 July 2026 | Prepublication methodology draft | Established the evidence, scope, sampling, outcome, severity, weighting, limitation, and rescan explanations. Final public labels, categories, weights, and deployed model identifier remain subject to product confirmation. |
Frequently asked questions
What is a good Website Readiness Score?
The number needs the context of its model version, scope, and findings. A higher score generally means more sampled checks met the configured rules, but it does not prove that the entire site is healthy or that search performance will improve.
Why can my score change after a small website edit?
A shared template or navigation change can affect several pages or checks. Dynamic resources, crawl scope, availability, and the scoring-model version can also change the evidence. Compare the finding details, not only the total.
Does a passing check prove that the page meets every standard?
No. It means the retrieved evidence satisfied that defined automated check. Broader quality, usability, accessibility, security, compliance, and business questions may require manual review.
Can I compare scores from different scan sizes?
Use caution. A different sample can expose different templates and problems. The most useful comparison uses the same website, a similar scope, and the same scoring-model version before and after a verified repair.
Should I fix every failure?
Confirm intent and evidence first. Some directives or exclusions are deliberate. Repair genuine problems in a sequence that accounts for impact, reach, dependencies, risk, and the importance of the affected pages.