wardley-maps.sgit.ai / Resources / Link verification

The link-verification run

Every external URL this site publishes is fetched on a schedule, and the run is published — failures and skips included. This page renders /data/link-check.json, which is written by bin/verify-links.js from a GitHub Actions job every Monday and on demand.

No sibling site in this network has one. This site needs one, because it spends a page telling you that awesome-wardley-maps, Wikipedia and Simon Wardley's own resources page all list five dead things as live. A site that makes that criticism and does not check its own links has no standing to make it.

Method, and what "verified" does not mean

• HEAD first, then GET. A good number of hosts refuse HEAD and serve GET, so a HEAD failure is not recorded as a result.
• Redirects are followed and the final URL is recorded. A link that now lands somewhere else shows as a redirect rather than silently passing — which is how the Teachable course deep links were caught: they return 302 to a login wall, not 404.
• Hosts that block automated retrieval are recorded as skipped, never as ok. LinkedIn, SlideShare, YouTube and Discord are on that list. Claiming a 200 that was not received would be worse than admitting the check cannot be made. Those need a human.
• A 401, 403, 429, 451 or 999 is blocked, not failed. Medium serves 403 to anything without a browser, and every chapter of the book is on Medium. Calling twenty live chapters dead links would make this report wrong in exactly the way it exists to complain about. Blocked means we could not check. Only a 404, a 5xx or a connection failure means the link is broken.
• Our own host is skipped. Internal links are checked by the release gate against the files on disk, which is a stronger check than fetching a deployment that may not have happened yet — and it runs before every publish rather than weekly.
• A dead link does not fail the build. The point of the job is that links rot; a red pipeline would tempt somebody to delete the evidence rather than record it.

What a green row means: the URL responded. It does not mean the content is still what it was, that the project is maintained, or that the licence has not changed. Those are the resource pages' job, and they carry their own dated verification.

The screenshots, and the three that are not screenshots

The same discipline applies to the capture run. Thirty targets were attempted: 26 produced a usable image, one failed to load at all, and three succeeded technically while photographing a Cloudflare interstitial rather than the page. Those three are recorded as blocked and no page presents one as a screenshot of the resource — a picture of a bot-check is not evidence of anything except a bot-check. Every published image records the capture timestamp, the HTTP status, the original pixel dimensions and the fact that the published file is a resized WebP derivative of the PNG that was captured.