toolkit

Scenario · Content and search

The navigation menu needs changing

“Add this to the menu.” Or: “The menu is doing something odd on phones.”

Adding a menu item and fixing a broken one are the same underlying job, because the navigation is the highest-traffic component on the whole site and the one most often only ever checked on a desktop screen. This confirms every menu link actually points at a live page, checks how the menu behaves on a real phone screen rather than just a wide monitor, and flags whether a removed item just orphaned a page that's still live but no longer reachable by anyone.

What to ask for

Layout / front-end QAFront-end / layout QA for a live page — measures the rendered DOM across device presets and flags objective layout defects: horizontal overflow, tap targets too small, text below the legible floor, skipped heading levels, DOM bloat, interactive elements whose contrast passes at rest but fails on hover or focus, a mobile nav toggle that reveals nothing, and viewport meta defects (missing or blocking zoom).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.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.ScreenshotsCapture multi-device screenshots of any URL from the command line — one PNG per device preset (iPhone → Desktop 4K), headless, on a Playwright core.

See it work

A real run of Layout / front-end QA:

Layout / front-end QA · layout-front-end-qa — https://toolkit-tests.pages.dev/layout/overflow.html
  measuring layout across desktop,iphone-17 …

FAIL — https://toolkit-tests.pages.dev/layout/overflow.html
  1 error  0 to review  1408px overflow  16 nodes
  ✗ error  overflow content overflows the viewport by 1408px on iphone-17 — horizontal scroll (offenders: div)

  report: ./out/layout-front-end-qa-layout-front-end-qa.html
  json:   ./out/layout-front-end-qa.json
  text:   ./out/layout-front-end-qa-layout-front-end-qa.txt

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

Adding a menu item and fixing a broken menu are the same procedure with a different starting point, so they share this one. The menu is the highest-traffic component on the site and the one most consistently verified on desktop only.

  1. Establish which menu and which device. Most sites have more than one — primary, footer, mobile, sometimes a separate booking bar — and the mobile menu is frequently a different component with its own markup. A report of odd behaviour is a report about one of them.
  2. Snapshot the pages the menu appears on. Which is every page, so pick the representative ones: home, a service page, a page deep in the tree.
  3. [manual] Make the change in the CMS. Add, reorder, relabel or remove the item. Keep the label short — a long label is the usual cause of a menu that wraps and collapses at tablet width. Publish and purge; menus are aggressively cached.
  4. Check every destination. The link check confirms each menu item points at a page that returns 200. A menu entry pointing at a page that was removed or renamed is the most common menu defect and it looks like a working menu right up until it is clicked.
  5. Check the layout, on real devices. The layout check finds the overflow, the collapse and the overlap; the screenshot set across desktop, tablet and phone is what makes a broken mobile menu obvious. A menu is the component least forgiving of a narrow viewport.
  6. Look at what the change did to the link graph. The internal link graph shows which pages the menu was carrying reachability for. Removing a menu item can orphan a page — it stays live, and nothing on the site links to it any more.
  7. Before/after check on the representative pages, so a menu edit that shifted the header on every page of the site is caught here rather than reported.

The orphan is the one nobody catches

A removed menu item is usually the only internal link to that page. The page keeps working, keeps being in the sitemap, and stops being reachable by a human. Step 6 exists because that failure has no symptom — nothing breaks, traffic just stops.

What this does not cover

What the menu should say. It verifies that a menu renders, works on every device and points at live pages; the information architecture — what belongs at the top level, what a label should read, how many items is too many — is a design decision no check makes for you. A mega-menu built by a page builder may also be partly assembled by JavaScript, and what is not in the delivered HTML is outside the link check.

← All scenarios