toolkit

Scenario · Content and search

Add, change or remove a link

“Link this text to our booking page.” Or: “That link should go somewhere else now.”

Adding or changing a link looks like the smallest possible edit, and the way it goes wrong is that nobody follows the destination before publishing it — a link to an old URL that happens to redirect still works, it just quietly adds an extra hop for every visitor who clicks it. This checks that a link actually resolves, follows its full redirect chain rather than just its final status, and confirms the wording describing it makes sense to someone using a screen reader, not just to someone glancing at the page.

What to ask for

Link & image checkerOn-page link & image checker — extracts every link and image a page declares, fetches each to its status code, and reports the dead ones (4xx/5xx broken links and broken images) plus the link-quality issues search engines and screen readers care about: non-descriptive anchor text, image-only links with no accessible text, malformed links, insecure external links, new-tab links missing rel=noopener, and excessive link counts.Redirect checkRedirect-chain validator — follows where each URL actually sends a browser, hop by hop, and reports the loops, over-long chains, temporary (302/307) redirects where a permanent one belongs, meta-refresh and JS redirects, https-to-http downgrades, and dead ends.Internal link graphInternal link-graph audit — given a site's URL universe, fetches each page, extracts the internal links, and builds a directed graph of how the site links to itself, then grades the signals rankings depend on: ORPHAN pages linked from nowhere, pages unreachable from the home page, pages buried too many clicks deep, thin single-inlink pages, generic anchor text, and exact-match over-optimization.Before/after checkBefore/after verification for a change to a live page — the safety net for the small edit that doesn't justify a staging round-trip.

See it work

A real run of Redirect check:

Redirect check · redirect-check — following 1 chain(s) …

FAIL — 0 pass · 0 review · 1 fail
  ✗ https://toolkit-tests.pages.dev/r/loopA 302→302→LOOP
      redirect loop — the chain returns to a URL it already visited

  playbook: local fallback
  tsv:    ./out/redirects.tsv
  text:   ./out/redirect-check-redirect-check.txt
  report: ./out/redirect-check-redirect-check.html

The captured report, exactly as a run hands it to a client —open the full report ↗

The smallest possible change, and worth a written procedure only because of what people do with it: paste a URL, ship it, and never follow it. A link is the one edit whose correctness lives entirely on another page.

  1. Follow the destination yourself, before linking to it. Not the URL you were given — the URL after redirects. A link to an old URL that happens to 301 works, and quietly adds a hop to every visitor who clicks it.
  2. Snapshot the page.
  3. [manual] Make the edit in the CMS. Use anchor text that describes the destination — “book a consultation”, never “click here” or a bare URL. External links open in a new tab only if there is a reason, and when they do they need rel="noopener". Publish and purge.
  4. Check the link resolves, from the page. The link and image check fetches every link on the page to its real status and flags the quality problems alongside: non-descriptive anchor text, image-only links with no accessible name, insecure external links, new-tab links missing rel=noopener.
  5. Check the chain, not just the status. The redirect check follows the destination hop by hop. A 200 at the end of three redirects is a working link and a slow one, and it is invisible to a status-code check.
  6. For a removed link, check what it was holding up. The internal link graph shows whether that link was the only route to its destination. Removing the last internal link to a page orphans it — the page stays live and stops being reachable.
  7. Before/after check to confirm the edit changed the link and nothing else.

Anchor text is the accessible part

“Click here” is a link with no meaning to anyone navigating by links alone, which is how screen-reader users move through a page. Step 3 puts it in the procedure because it is a free fix at write time and an audit finding forever afterwards.

What this does not cover

Whether the destination is the right one. It confirms a link resolves, resolves cleanly, and uses anchor text a person or a screen reader can understand — it has no view on whether the page at the other end is the page the visitor wanted. Links written into the page by JavaScript are outside it too, since it reads the delivered HTML.

← All scenarios