toolkit

Scenario · Content and search

Take this page down

“We don't offer this any more — take the page off.”

Deleting a page is the easy half of taking one down — the part that gets missed is that the rest of the site goes on pointing at it anyway, in menus, service lists, and markup that a normal search of the visible text never catches. This finds every place on the site that still references the page before it comes down, and proves the replacement redirect actually works cleanly afterward, so removing a page doesn't quietly create a dead end the site links to itself.

What to ask for

Sitemap & robotsRead-only sitemap & robots map — fetches a site's robots.txt and every sitemap it declares (or probes the common locations), follows sitemap indexes down to their children, collects every URL, and reports what is declared, what robots.txt blocks, and what is oversized, cross-host or insecure, plus a crawl-over-crawl diff.Site-wide content searchSite-wide content scout — searches every page of a site (or one page) for literal phrases or labelled regex rules and reports every occurrence with its surrounding sentence, so a copy change can be scoped before anything is edited.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.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.

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 ↗

Deleting the page is the easy half. The half that gets missed is that the site goes on pointing at it: menu entries, service lists, related-treatment blocks, sitemaps, schema. A page removed without that sweep becomes a 404 that the site itself links to.

  1. Map the site first. The sitemap-and-robots read gives you the URL list every later step runs against, and tells you whether the page is even declared in the sitemap.
  2. Find everything that references it. Search the whole site for both the page’s URL and its subject, with the raw pass on so hrefs, nav markup, schema and meta tags are searched and not just visible copy. A page’s inbound internal links are almost never in body text — they are in menus and lists, which visible-text search cannot see.
  3. Pick the redirect target, and write down why. The parent service or category page, not the home page: a visitor who wanted a discontinued treatment is best served by the list of what you do offer. Home is where a lazy redirect goes and it reads as a dead end.
  4. [manual] Remove the page and put the 301 in. Delete or unpublish, add the redirect, then remove every reference found in step 2 — the menu entry, the service-list item, the schema node. Republish and purge. Archive the copy first if there is any chance it comes back.
  5. Prove the redirect. The redirect check confirms one clean permanent hop to the target, with no chain and no loop. A 302 where a 301 belongs, or a two-hop chain, both count as not done.
  6. Re-run the reference search. Zero hits on both passes. Then check links across the site so a menu entry you missed shows up as a broken link rather than as a client email.

The 404 you created yourself

An external site linking to a page you removed is somebody else’s stale link and a 301 handles it. An internal link to a page you removed is a defect you introduced, and it is the one visitors and crawlers both hit immediately. Step 2 exists because those internal references live in markup that does not render as text.

What this does not cover

Whether the page should go, and where its traffic should land. It finds everything that points at the page and proves the redirect works afterwards; picking the redirect target is a judgement about what a visitor was actually looking for, and picking wrong is invisible to every check here. It also cannot recover a page you deleted without archiving first — if the copy might be wanted again, that is on you before step 4, not after.

← All scenarios