Explore various methods for checking for broken links and what to consider when applying the approaches to your site.
Broken links can be a major issue for websites, causing frustration for users and potentially harming SEO rankings.
There are a number of different ways to check for broken links, and each has its benefits and challenges. Let's look at two common approaches.
One approach is to regularly check for broken links against your live production site. Some SEO services will do this automatically for you, or you can write your own script. Events can also be set up to trigger the check on an as-needed basis.
For pre-rendered sites, it can be useful to check for broken links during the build process. However, this can be tricky to set up, especially for server-rendered sites like Next.js.
When it comes to reporting on broken link tests, there are several factors to consider to ensure that the report is actionable and acted upon quickly.
How often you check your site should be a byproduct of how often the content is updated. You should check for broken links more freq_u_ently than you publish new content.
If you're usually publishing new content weekly, run a daily check on your site to check what was published yesterday.
Or maybe you don't have a blog, but you might change a page monthly. Then run a weekly check.
The report should include a list of broken links, along with the URL where the link was found and the HTTP status code returned.
It's important to prioritize the broken links based on their impact on the user experience and SEO. For example, highly visibility pages should be fixed immediately.
If the report is too noisy, it will get ignored, even if it has useful information. It should stay out of the way until it's important to act. And when that time comes, provide information to make it clear what needs to be done, where it should be done, and who is going to do it.
For example, I use a simple Slack message for regular checks. But if I am checking during a build, I will fail the build with broken links, making it more obvious and immediately actionable.
(You know what I'm going to say, right?)
The right answer is the one that works best for you. I take both approaches in different ways at different times for different sites. For some sites, I test the entire site at build time. Other sites I only check routinely. And I use a combination in more complex scenarios.
There are a number of factors to consider:
There is further nuance from page to page. You may not want to test every page in the same way. Maybe critical pages are tested during the build, but you also run a weekly check on the entire site.
One last consideration I'll add is how you handle external links. There is always a risk when linking externally that the link will break. And yet, checking for external links may drastically slow the test down because you don't have control over the response time of those links.
I absolutely recommend testing external links but defer it to some routine check, and don't include it in your more frequent or mission-critical checks (unless it is mission critical).
Continuous integration was coined as an extreme programming practice, but is used more loosely today.
Commit file changes created during a GitHub automated workflow run.
Four considerations when deciding to run continuous integrations with production builds or as a separate workflow.