3 ms·

What sets this apart from other broken link detectors?

chrismorgan 13y ago
The most important feature I see is that it's automatic. This will save a lot of time, which for businesses is rapidly worthwhile. Even when you can have a link checker running in the background on your own machine, it's still very distracting. Comparing it with the one or two automatic link checkers in existence, my goal is quite different from them. They have stagnated and are designed around HTTP status codes. Unfortunately, that's not all there is to the web. Links can (and far too often do) break completely without returning 404—they may redirect to a 200 OK "not found" or "under construction" page; there's more: links can be broken because they go to different content. Detecting changes like that is also valuable and is one of my many longer-term goals. Another idea that I have which I haven't seen anyone else using is link hash checking. Getting sent to the wrong part of a long page is often as bad as a 404 Not Found. Finally, my goal is to ensure that if a link ever existed, it shouldn't be broken: someone else might be linking to it. None of the competitors have anything like that, either, focusing on the current state of your site. Those are just a few of the things that I have been working on with it.
- waterlion 13y ago
  Just curious about how you'd validate the hash thing, especially with the rise in single-page apps with routing information in the fragment.
  - chrismorgan 13y ago
    Certain patterns would certainly not be able to be checked; most notably, any #! links would be blacklisted from checking. It'll be a learning process, improved over time. Hopefully it'll get to the stage where adding machine learning to it will be worth the effort. But for the rest of cases, it's quite straightforward: for any hash, check that an element of that ID exists in the document. Certainly there will be false errors reported with this, but there will be a very significant number of genuine problems found by it.

The most important feature I see is that it's automatic. This will save a lot of time, which for businesses is rapidly worthwhile. Even when you can have a link checker running in the background on your own machine, it's still very distracting. Comparing it with the one or two automatic link checkers in existence, my goal is quite different from them. They have stagnated and are designed around HTTP status codes. Unfortunately, that's not all there is to the web. Links can (and far too often do) break completely without returning 404—they may redirect to a 200 OK "not found" or "under construction" page; there's more: links can be broken because they go to different content. Detecting changes like that is also valuable and is one of my many longer-term goals. Another idea that I have which I haven't seen anyone else using is link hash checking. Getting sent to the wrong part of a long page is often as bad as a 404 Not Found. Finally, my goal is to ensure that if a link ever existed, it shouldn't be broken: someone else might be linking to it. None of the competitors have anything like that, either, focusing on the current state of your site. Those are just a few of the things that I have been working on with it.

waterlion 13y ago
Just curious about how you'd validate the hash thing, especially with the rise in single-page apps with routing information in the fragment.
- chrismorgan 13y ago
  Certain patterns would certainly not be able to be checked; most notably, any #! links would be blacklisted from checking. It'll be a learning process, improved over time. Hopefully it'll get to the stage where adding machine learning to it will be worth the effort. But for the rest of cases, it's quite straightforward: for any hash, check that an element of that ID exists in the document. Certainly there will be false errors reported with this, but there will be a very significant number of genuine problems found by it.