How SlaySlop checks Linked Pages

I care what an attacker—or a tired contractor—can walk into from the public HTML. Scope fantasies die when the footer still links /admin-old or a staging note. SlaySlop's Linked pages check "Discovers public pages reachable from the scanned surface." That is reachability on the public surface, not a compliment about your IA.

Outcome the check is for

You get discovery of public pages reachable from what you scanned, so later findings have routes to attach to and so you can see when the live graph exceeds the launch checklist. The outcome supports security and quality triage alike: forgotten pages are still public pages.

UX siblings include failed requests ("Finds failed public requests observed while pages render") and technology detection ("Identifies public framework and service signals used by the site"). Linked pages is the map; those checks are signals observed while traversing and rendering.

Boundaries

Read-only. Permission required. Not a pentest. Not forced browsing through paywalls. SlaySlop does not edit your nav. Acceptable Use still applies when the domain is not yours. Discovery of a link is not authorization to attempt credential stuffing on that path.

Security category checks—exposed files, headers, client-side secrets—remain separate. Discovery may reveal a path those checks should care about. It does not replace them.

Happy path: how the signal is observed

Website scanner framing is simple: run checks against any public production, staging, or client URL you are allowed to test. Linked pages participates by expanding which public documents exist in that story. Performance and accessibility product copy says quality audits run on discovered pages and findings attach to routes. Discovery is how "discovered" gets a concrete meaning.

When I reproduce locally before arguing with a report:

# Permissioned starting point
curl -sI "https://staging.example.com/" | sed -n '1,12p'
# Then open the site in a browser and walk primary nav + footer
# Note URLs that leave the marketing shell

check: Linked pages
definition: Discovers public pages reachable from the scanned surface
category: UX
feeds: route-attached findings across quality and security checks

Pitfalls when reading discovery

Assuming no link means no risk—people also type URLs and reuse old campaigns. Assuming every discovered 200 is a good page. Assuming sitemap-only URLs are unreachable when the sitemap is public. Confusing monitoring uptime on one URL with coverage across the discovered set.

Depth notes

Discovery only helps if someone reads the map. I paste surprising URLs into the security review and the QA checklist the same afternoon. A publicly linked /backup or forgotten CMS theme is not a UX trivia item; it is public surface.

# Permissioned: compare nav expectations vs live homepage anchors
curl -sL "https://staging.example.com/" | tr '"' '
' | grep -E '^https?://|^/' | head -n 60

Performance and accessibility audits that claim "key pages" without consulting discovery are guessing. Product language says audits run on discovered pages. Linked pages is how you audit that claim.

Also keep Domain insights separate when a discovered hostname points elsewhere: DNS records and redirects explain where the name goes; Linked pages explains what the HTML offered as a next hop.

Security sharpness on discovery

When discovery surfaces /server-status, /phpinfo, or a vendor admin path linked from a leftover footer, escalate with the security catalog. The UX check found reachability. The exposure check names what an attacker sees on that public surface. Do not close the ticket as "odd URL" without that second look.

Related next step

Use discovery to widen the handoff checklist, then run security and quality checks on what you actually expose. SlaySlop keeps that route context beside ranked findings.