Finding Broken Links Before a Website Goes Live

Your release looks ready. Then someone clicks a download button and gets an error. A footer link still points to staging. A helpful reference opens an unrelated homepage. These failures are easy to miss during development because you already know where everything belongs. Visitors do not. A repeatable link review catches those gaps before your website asks anyone to trust it.

Define What Counts as a Working Link

A working link takes someone to the intended content. That sounds obvious, but automated checks often measure something narrower: whether a server answered successfully. A deleted article can redirect to a homepage. A missing PDF can return an HTML error screen with a successful status. Both need attention even when a scanner reports no failure.

Write down your release rules before scanning. Internal destinations should resolve on the intended host. Links to sections should reach existing targets. Downloads should open in the promised format. External references should still support the surrounding text. Redirects should finish at a relevant destination without loops.

Decide which failures stop deployment. Broken navigation and unavailable installation files usually deserve that treatment. A temporary failure on an optional external reference may need a documented review instead. Give every exception an owner and a review date. An unexplained ignored error becomes permanent surprisingly fast.

Build an Inventory Beyond the Homepage

Start with the output you plan to deploy. For a static website, that means generated HTML and copied assets. For a web application, use a running release build. Source files help locate mistakes, but they cannot prove that a build copied a download or generated a route correctly.

Gather starting addresses from your sitemap, route configuration, content inventory, and known landing pages. A crawler can follow links between pages, but it cannot reach a page that nothing links to. Compare the crawl results with your expected routes to catch those missing entry points.

Include navigation, footers, article references, download buttons, and links added by reusable components. Check language variants and older content that remains published. A shared footer mistake can affect hundreds of pages, while a forgotten campaign page may contain the only broken destination in the release.

For reviewing links in HTML, an HTML link checker can support your initial inspection. Confirm what your chosen tool actually checks before treating its results as complete. Extracting addresses, requesting destinations, validating fragments, and rendering JavaScript are separate capabilities.

Make the Test Environment Behave Like Deployment

Serve the build over HTTP with the routing rules you expect in production. Opening files directly from disk can hide server behavior. It also changes how root-relative addresses resolve. A link beginning with /guides/ needs testing against a website origin.

Match the intended base path. If the website will live under /docs/, test it there. A build that works at the root may send visitors to missing routes after deployment under a subdirectory. Check canonical host settings, trailing slash behavior, and HTTPS redirects as part of that setup.

Pay attention to filename case. A development filesystem may accept a link to Setup.pdf when the actual file is setup.pdf. A case-sensitive server can reject it. Validate the exact generated filenames in an environment that reflects your hosting setup.

For client-rendered applications, combine route inventory checks with browser-based inspection. A scanner that reads only the initial HTML may miss links created after JavaScript runs. Visit representative screens and confirm that menus, tabs, and loaded content expose the destinations you expect.

Check Internal Routes and Section Targets

Resolve each relative link against its source address before testing it. The same value can lead somewhere different depending on the current path and any document base setting. Preserve the source page in your results so you can trace an incorrect resolution back to its markup.

Check query strings according to application behavior. Removing every query parameter can hide a broken filter or pagination link. Following every possible parameter combination can create an endless crawl. Define allowed patterns and cap the scope around actual published links.

Fragments need a separate check. An address ending in #installation can return a successful response even when no matching target exists. The fragment stays in the browser rather than becoming part of the HTTP request. Validate its target against the destination document, or against the rendered document when scripts create it.

Heading changes often break these links after Markdown conversion. Compare generated IDs with incoming references whenever titles change. Preserve established IDs where possible. When a route moves, add a relevant redirect and update links you control to use the final destination.

Interpret External Responses Before Editing Links

External checks require patience. Another server may reject automated requests, require authentication, or limit request frequency. A timeout is evidence that a check failed, but it does not prove the destination has disappeared.

Use conservative concurrency and bounded retries. Record the request method and final response. If a server rejects a HEAD request, retry with GET within sensible transfer limits. The official HTTP semantics specification defines 405 as a method the resource does not support. It also distinguishes a 404 response from 410, which signals likely permanent removal.

Inspect authentication failures and access restrictions in a browser. A documentation link may work for signed-in staff while failing for public visitors. Test public references without your usual account session before deciding they are suitable for launch.

Follow redirects with a maximum hop count and record the final address. Review unexpected host changes and irrelevant landing pages. If an old tutorial now redirects to a general product page, the request may succeed while the reference has lost its value.

Keep external crawling bounded. Request linked destinations without recursively scanning unrelated websites. This reduces load and keeps the report focused on links your release actually publishes.

Open Downloads and Inspect Converted Content

Downloads deserve more than a status check. Retrieve each release-critical file and open it with a suitable viewer or parser. Confirm that its contents match the link label. A button promising a CSV export should not deliver a login page saved with a .csv extension.

Check the response content type, filename, and actual file format. For archives, verify that extraction succeeds and the expected files exist. For PDFs, inspect readability and any linked references that matter to the reader. For converted documents, check whether conversion changed filenames, removed section targets, or left references to local paths.

Keep original source files available while correcting conversion problems. Rebuild the published output from those sources and inspect it again. Editing only a generated document can leave the next build ready to recreate the same failure.

Use checksums when you need to confirm that a published download matches an approved artifact. That verifies file identity. It still leaves compatibility and usability to be checked by opening the file in the tools your audience uses.

Keep Private Addresses Out of Public Checks

A prelaunch report can contain more sensitive information than expected. Draft routes, customer identifiers, signed download addresses, and query parameters may all appear in extracted links. Review what you submit before sending HTML or address inventories to an external service.

Run checks locally or through an approved internal runner when the material is private. Give authenticated scanners only the access they need. Keep credentials outside committed configuration, and redact tokens from reports and build logs.

Restrict allowed schemes and destinations when a scanner processes user-controlled content. A link review should not make arbitrary requests to internal services. Treat email and telephone links separately from HTTP destinations, and exclude action links that could change application state.

Turn Findings Into Fixes You Can Verify

Save a report containing the source page, original link, resolved destination, response status, redirect destination, and check time. Add a short diagnosis after manual review. These details let another developer reproduce the issue without guessing where the link appeared.

Group repeated failures by cause. Hundreds of broken links may come from one shared template or an incorrect base path. Fixing that source is more reliable than editing generated pages individually. Preserve every affected source location in the report so coverage remains visible.

After each correction, rerun the relevant checks. Then scan the full build again before release. A route rename can fix one reference and break another. Record exceptions explicitly instead of hiding them through broad exclusions.

Make Link Review Part of Every Release

Add the process to continuous integration once the checks are stable. Build the website, serve the output, run internal validation, and save the results as release artifacts. Fail the pipeline on confirmed internal errors according to your agreed rules.

External checks often fit a separate job because remote availability can fluctuate. Flag failures for review, retry within limits, and require a decision for unresolved references. Keep exceptions narrow, with a reason and expiry date. Pin scanner versions and store configuration with the project so results remain reproducible.

Finish with a short browser review of important visitor journeys. Open navigation links, follow a documentation reference, jump to a section, and download a file. Use a clean session where appropriate. Automated coverage and human judgment answer different parts of the same question: can a visitor get where the website promises?

Let the Release Report Earn the Green Light

Before deployment, you should have evidence tied to the build you are releasing. Expected routes were covered. Internal links resolved. External failures received review. Downloads opened correctly. Any remaining exceptions have named owners.

After deployment, repeat a bounded check against the public website. Hosting rules, caches, and domain configuration can introduce failures that staging could not reproduce. Keep that check small enough to run immediately. Link review becomes dependable when it is a routine release step with clear results, rather than a hopeful round of clicking just before launch.