How SlaySlop checks Privacy Policy

Crawlers and humans both need a reachable policy URL. Thin sites hide it. Broken sites link it and 404. SlaySlop's Privacy policy check "Checks whether a public privacy policy can be found and reached." I keep that sentence in the handoff so nobody invents a deeper legal audit the product did not run.

Outcome the check is for

You get a Legal finding when the public site does not expose a reachable privacy policy in the scan's observation. Evidence should point at what was missing or unreachable. The outcome is a fixable discoverability problem, not a scored essay about privacy philosophy.

Siblings matter for a scannable Legal section: Terms page, Cookie signals, Consent controls. Quote their glossary lines when stakeholders ask. Avoid stuffing "compliance" into every heading. Reachability is enough claim for this row.

Boundaries

Read-only public scan with permission. Not legal advice. Not a substitute for counsel review of the policy text. SlaySlop does not edit the page. Acceptable Use applies.

The check does not certify that the policy content matches every product surface or every region. It asks whether a public privacy policy can be found and reached.

Happy path: how the signal is observed

1. Crawl the public site in the product's browser context where applicable.
2. Look for privacy policy links and common policy routes.
3. Attempt to reach the candidate URL.
4. Flag when a public policy cannot be found or reached.
5. Attach evidence and rank with other verified findings.

Spot-check pattern on a host you control:

BASE="https://www.example.com"
curl -sL "$BASE" | tr '\n' ' ' | grep -oiE 'href="[^"]*privacy[^"]*"' | head
curl -sI -L "$BASE/privacy" | awk 'BEGIN{IGNORECASE=1} /^HTTP|^content-type:|^location:/{print}'

I want a discovered link and a successful public response. A homepage that never mentions privacy, plus a 404 on /privacy, is the classic miss. A link that points at a Google Doc with "request access" is not reached in the public sense that matters here.

Pitfalls when reading the row

Policy only on the app subdomain while the marketing apex was scanned. Policy behind a cookie wall that never finishes. Policy in the footer of the blog theme but removed on the new marketing redesign. Policy URL correct in staging, wrong host in production DNS.

Do not treat a PDF download that fails on mobile Safari as "fine because legal has the file." The check is about the public site the scan sees.

What good reporting looks like

A short block: scanned host, policy URL if any, status, owner, next action. No keyword-stuffed title. No claim that the scan "ensures compliance." Soft CTA: if the client portal already shows Legal findings, keep Privacy policy next to Terms so reviewers see both documents' reachability in one place.