A practical broken-link check for a small website

Open your homepage on a phone and follow the link to your main service page. Then take the next step a customer would take: the booking page, the quote instructions, or the contact details. Write down any link that lands somewhere other than what its label promises.

That one route is enough to start. Once you have a dependable way to record a problem and confirm a repair, widen the check to the rest of the site.

Record the link you followed

For each problem, save four things: the address of the page holding the link, the visible link text, the destination it points to, and what actually happened. Add the date you checked. "The booking link is broken" leaves the next person hunting for it again. "On the service page, the 'Request an appointment' link opens a page-not-found message" tells them where to begin.

A 404 response means the server could not find the requested resource. It confirms the resource is missing; it does not say whether the absence is temporary or permanent, so record what you saw instead of diagnosing the cause. MDN's 404 reference

Other outcomes deserve their own entries. A page that asks for a login, a link that opens the wrong service, and a link that drops you on the homepage are each worth writing down. Only call something a 404 if you have checked the response or the page identifies it that way.

Decide what belongs at the failed address

During a clinic website launch, we found three article addresses from the old site that still returned 404. The new site's navigation worked, but someone following an old saved link could still land on a missing page. Those addresses remain on the redirect review list. The site owner needs to compare each old article with current content before choosing a relevant destination.

Old addresses survive in saved messages and bookmarks, so the maintainer may also need a redirect. Google Search shows the new target in results for a permanent redirect and keeps showing the source page for a temporary one, depending on how long the move will last and which page you want people to reach. Redirects and Google Search

An expired event page calls for a different decision. If nothing useful replaces it, remove the link and rewrite the sentence around it. Sending readers to an unrelated homepage does not give them the event details the label promised. Keep the old address in your record so the maintainer can decide how requests to it should be handled.

For a link pointing at another organization's site, find the current page on that organization's own site and read it before swapping the URL. A page with a similar title can describe a different service or location. If you cannot confirm a replacement, mark it for review.

The same clinic's website linked correctly to its hosted scheduler and patient portal. On those pages, though, the "Our Website" return link pointed only to https://. That fix sits with the system administrator who controls the external service. After the URL is corrected, someone should follow it from both the scheduler and portal to confirm it reaches the clinic site.

Check the places customers can reach

After the main route, work through the navigation and footer, then the pages that carry downloads or links to outside services. Include links inside paragraphs as well as buttons. On a phone, open the menu before checking its destinations, since the mobile menu can present a different set of links than the desktop one.

For a small site, a browser and a notes app are enough; a spreadsheet can make the record easier to sort. A link checker helps on a larger site, but treat its output as a list of candidates to inspect. A page that loads successfully might still not match its label or serve the document a customer needs.

For booking or payment links, checking where the link goes is enough for this pass. Do not complete a booking or run a charge just to test a link.

Confirm the repair from its starting page

Once an approved change is live, return to the page where you first found the problem. Follow the link again, check where it lands, and read enough of the destination to confirm it answers the label's promise. If the phone menu was the source, test it at that width too.

If the maintainer added a redirect, open the old address on its own. Updating a link and redirecting the old address are two separate changes, so note which ones actually shipped.

Close the entry with the new destination, the check date, and any work still with someone else. Leave unresolved external links in the record. The next pass can start from those entries instead of rebuilding the investigation.