How Slop Audit audits a public website

Most website audits return a checklist. Slop Audit checks what a visitor, crawler, or tool can reach, understand, and do on the URL you plan to share.

The local preview can look fine while the deployed page returns the wrong content type, hides its main action, overflows on a phone, or gives search systems conflicting information. Slop Audit checks the deployed page and turns what it finds into evidence and fixes.

Check the public page

You submit one public URL. The scan follows limited redirects to the final page and records the response. It does not ask for credentials, bypass access controls, or claim to inspect pages it could not reach.

The first pass reads response headers, HTML, metadata, crawler files, links, and visible text. When Browser Run is available, a second pass opens the page on mobile and desktop so the audit can check the rendered page, not only the source HTML.

The scan is limited. It checks the page you are about to share, not every route on the domain.

Four groups make up the readiness score

The Production Readiness score runs from 0 to 100. It combines four groups, each worth one quarter of the score. It shows whether the page is ready to share with visitors, crawlers, and your team.

1. Discovery and agent access

This group checks whether systems can find and describe the page. It checks:

• Reachable final HTML and the final content type.
• A usable robots.txt policy and whether it permits the audited route.
• A discoverable sitemap and whether it represents the audited URL.
• The page title, meta description, canonical URL, and Open Graph title, description, and image.
• Valid JSON-LD that identifies a meaningful page type.
• A factual llms.txt with useful links and no prompt-like instructions.
• Semantic landmarks for the header, navigation, main content, and footer when the rendered browser pass is available.

These checks do not guarantee indexing or ranking. They give crawlers and tools clearer information.

2. Identity, reliability, and hygiene

This group checks production details that a screenshot may not show:

• HTTPS on the final route.
• Content security policy, frame protection, MIME sniffing protection, and referrer policy.
• A usable favicon, manifest metadata when appropriate, and the document language.
• Console errors and failed first-party network requests observed during the browser pass.
• Broken same-origin links.
• Images that are oversized relative to their rendered dimensions or transfer budget.

The audit reports what it observed. A missing header is one issue, not proof that the whole application is insecure. Third-party failures are kept separate from first-party failures so a vendor outage is not reported as a problem in your product.

3. Responsive, accessible, and fast

This group checks whether the page remains usable on small screens and with different input methods. It measures or observes:

• Responsive viewport configuration.
• Horizontal overflow and clipped or off-screen content on mobile.
• Alternative text for informative images.
• Accessible names for controls and visible keyboard focus.
• Tap-target spacing for primary interactions.
• Lab Largest Contentful Paint and long main-thread tasks when performance measurements are available.

The browser evidence includes the viewport where the issue appeared. This is more useful than a generic responsive warning. If a browser check cannot run, the report marks it as unable to test instead of guessing.

4. Content clarity and completeness

This group checks whether a visitor can understand the page and complete the next step. It checks:

• Whether the product, audience, and concrete outcome are clear in the opening copy.
• Whether the primary call to action has a specific intent and a resolvable destination.
• Whether important claims have proof, examples, documentation, or a way to verify them.
• Placeholder text, fake values, template residue, and readable visible copy.
• Heading hierarchy, including one clear primary heading.
• A credible contact, support, documentation, or ownership path.

The content review uses the page evidence. It does not judge the author or identify who wrote the copy. It checks whether the page gives readers enough information to act.

Slop Risk is a separate score

Readiness and Slop Risk answer different questions. Readiness goes up when more production checks pass. Slop Risk goes down when the page has fewer generic, unfinished, or hard-to-trust patterns.

The slop-risk score is built from four measured groups:

• Generic or clichéd copy (30%): broad language, vague value, and readable-copy signals.
• Specificity, proof, and trust (20%): CTA intent, supporting evidence, and a real help or contact path.
• Starter-template visual patterns (30%): correlated surface signals such as repeated panels, heavy rounding, shadows, gradients, or repeated visual treatment. One rounded button does not fail this check by itself.
• Placeholder and unfinished signals (20%): placeholder phrases, heading problems, and primary actions that do not lead anywhere.

Each group reports its tested points and points at risk. The report combines the groups and labels the result from Low to Severe. Lower is better. A group can be marked not measured when there is not enough evidence.

Keeping the scores separate prevents two mistakes: calling a page high risk only because its main action is broken, or calling a reachable page ready when its copy is vague and unsupported.

Each finding includes a fix

Each finding includes:

• An outcome: pass, warning, fail, not applicable, or unable to test.
• A severity and confidence level.
• The rule that produced it.
• A plain-language summary of what was observed.
• The impact on visitors, crawlers, or agents.
• A remediation written as a next action.
• An effort estimate: quick, moderate, or involved.
• Evidence such as an HTML tag, response header, visible quote, selector, screenshot region, performance metric, console error, or network failure.

For example, a main-action finding should say whether the control is a link or button, where it points, and why it matters. “Fix the CTA” is too vague. “Connect the main action to a working route or in-page action” gives the developer something to check on the next scan.

Coverage is shown beside the score because a 90 based on a complete test is different from a 90 where several browser checks were unavailable. Confidence and coverage make that difference visible.

MCP and WebMCP are observations, not penalties

Slop Audit can show whether a public page exposes agent protocol signals, but these observations do not change readiness or slop-risk scores.

For MCP, the audit only probes an explicitly advertised, same-origin endpoint with a safe server-discovery request. A recognizable live JSON-RPC response is marked Detected. An endpoint or server card without confirmation is marked Hint only.

For WebMCP, the browser pass can feature-detect document.modelContext and read a registered tool catalog without executing tools. A non-empty catalog is Detected. A runtime with no registered tools is Not observed. If the required browser runtime is unavailable, the report says Unable to verify.

The audit never invokes an MCP or WebMCP tool. Protocol metadata and tool names are treated as untrusted evidence. This keeps the status useful without changing the score for an optional integration.

Why run a Slop Audit?

Use it when a page is almost ready and you can still fix a problem before sharing it:

1. It checks the URL people will actually receive. Production headers, redirects, assets, and environment configuration matter more than a local screenshot.
2. It joins human and machine concerns. The same page needs to make sense to a visitor, a search crawler, a screen reader, and an agent-facing parser.
3. It shows the evidence behind the result. You can inspect the observed tag, URL, selector, metric, or visible copy instead of accepting an unexplained number.
4. It gives the next fix. Findings include impact, remediation, and effort so the report can move directly into a release checklist or code review.
5. It makes uncertainty explicit. Browser capacity, blocked resources, and unavailable measurements stay visible as coverage gaps. The report does not fill them with sample data.
6. It creates a reusable handoff. You can download or share the report with scores, findings, evidence, and the remaining work attached to one public URL.

The result gives you a clear release decision. You do not need a perfect page. You need to know what the public page shows and what to fix first.

What ready means

A page is ready when it loads, explains what it does, works on a small screen, gives controls clear names, sends the main action to a real destination, and leaves enough evidence for someone else to check.

That is what Slop Audit checks: whether the page you are shipping is clear, usable, discoverable, and supported by evidence.

Run audit when you have a live page. For the surrounding release routine, start with the website launch checklist for developers, then review the guides on mobile website testing and robots.txt versus sitemap.xml.