A practical checklist for links that land on the right page

I maintain the six small web projects used in the examples below. This note shares a repeatable way to check links to specific features and guides, with a small evidence log you can reuse in your own projects.

A useful link check follows the whole journey: open the source page, find the intended link, click it, observe the final destination, and check that the page fulfills the promise made by the link text.

Start with a specific promise

Write down what a reader should find after clicking. A product name is a broad promise. A link to a particular tool or guide gives you something concrete to inspect.

Here are six examples from my own sites. Each has a different page identity to check:

These expectations cover navigation and page identity. Complete product workflows deserve their own tests: generating text, editing a file, performing a conversion, or calculating a real room is a broader task.

Keep the source page in the test

Use the actual public page containing your link. Find the particular paragraph, card, or comment where you placed it, and click the anchor a reader would use.

This catches problems that opening the destination directly can miss:

• An editor saved the URL as plain text.
• The clickable area belongs to a neighboring card.
• A platform added an intermediate redirect or an interstitial.
• A copied link points to a draft or private preview.
• The label promises a feature, while the saved address opens the homepage.

For a comment, keep its exact comment link or ID in the log. For a card collection, keep the card's label. That small detail helps someone else reproduce the check without guessing which link you meant.

Record the redirect and inspect the content

Keep both the intended URL and the final URL observed after the click.

For example, a link can request /gif-resizer/ and finish at /gif-resizer. In that case, inspect the final page's heading and controls, then record the redirect you observed. The GIF resizing page is still the intended resource.

A redirect from /tier-list to a general homepage needs a different decision. The reader was promised a tier list, so the final page needs to provide that material.

Treat URL differences as review information. Preserve path case and meaningful query parameters, and describe any accepted difference. Removing every slash or query parameter before comparing two addresses can hide a real routing problem.

Use a small, reproducible evidence log

One record per source link is enough. This example records an actual navigation check from a public technical note:

{
  "source_url": "https://gist.github.com/zuogl/bf1f0405a9a74cf578224c8e39514482",
  "anchor_text": "GifLoom's GIF resizer",
  "expected_url": "https://gifloom.com/gif-resizer/",
  "observed_final_url": "https://gifloom.com/gif-resizer",
  "page_identity": "GIF Resizer heading, size controls and file picker",
  "checked_at": "2026-11-12T21:03:21+08:00",
  "result": "pass",
  "notes": "Clicked the source anchor. The final page matched the intended tool. GitHub was signed in; a separate signed-out session was not tested."
}

For a failed or incomplete check, keep the observation that explains it: a pending review, missing anchor, wrong destination, blocked page, or unavailable browser session. Use a separate pending or unknown result until you can finish the navigation.

Keep the scope visible

Public visibility, a successful click, indexing, and search performance are separate observations. A navigation check establishes the source-to-destination path you actually tested.

For each check, retain the source location, anchor, intended page, observed final URL, time, and a brief description of the destination. That is enough to revisit a link later and understand what passed, what changed, and what still needs checking.