> If there is enough demand, as it is quite involved infrastructure-wise, I might consider adding support for client-side only websites, through headless Chrome (on a separate, more expensive tier).

I respect your experience on this project, but a suite (not just Chrome) of headless browser tests checking for broken links, amongst many other things, seems like not only the most sane way to approach this, but something that has been done to death on most serious web dev projects at $corporate_workplace. Obviously these are not open source projects so everyone else has to reinvent the wheel.

Parsing HTTP responses in your favorite language for tasks like this has never been reliable at any time in the entire history of web development. The myth that HTTP alone is all you need to understand the behavior of a website has always been wrong because it's far outside the scope of the spec. All of the link checkers in these comments seem like they'd be unreliable piles of edge case handling because the authors insist they should be able do it all from a Go or Python script or whatever.

I'm having a difficult time understanding why someone would pay for this or even want to run this anywhere but locally. Other than some individual's blog or affiliate marketing website I think most projects with a ton of links to check are already well supported by teams of devs who write tests like this all the time, and small time individuals with blogs wouldn't want to pay for yet another relatively expensive 3rd-party service.