Website navigation testing checklist for developers

A website navigation testing checklist should prove that visitors can identify the right route, reach it with different input methods, and understand where they landed. A menu that looks correct in one desktop screenshot can still hide links on mobile, expose vague labels to a screen reader, or send users to the wrong production route.

Use this workflow on the deployed website before launch. It combines semantic HTML, manual checks, and a small Playwright test so navigation failures become specific release tasks instead of subjective review notes.

Website navigation testing checklist

Test the main navigation in this order:

1. List the critical routes a visitor must be able to find.
2. Give each route a descriptive, stable link label.
3. Put major navigation groups inside labelled nav landmarks.
4. Mark the current page and keep repeated navigation in a consistent order.
5. Open and close responsive menus with pointer, keyboard, and touch-sized controls.
6. Confirm that every visible link has a real destination.
7. Verify the final URL, page heading, and recovery behavior after navigation.
8. Automate the smallest critical path in CI.
9. Repeat the checks against the deployed public URL.

This checklist focuses on whether navigation works. Broader information-architecture research still needs user evidence, content ownership, and task analysis.

Define the critical routes before testing the menu

Start with the destinations that support the page's main job. A SaaS marketing site might require product documentation, pricing, support, contact, sign-in, and the primary conversion route. A student portfolio might require projects, an about page, and a working contact path.

Write a small route contract before inspecting the header:

Documentation → /docs → setup guidance is visible
Pricing       → /pricing → plan names are visible
Support       → /support → support options are visible
Run audit     → / → public URL form is visible

The contract separates three failures that often look alike: a missing link, a wrong destination, and a correct destination with the wrong page content. It also stops a test from passing only because some link changed the URL.

Keep the list short enough to represent the release's real user paths. Use the website launch checklist for forms, metadata, security headers, and performance checks that sit outside navigation.

Use navigation landmarks and native links

Use semantic HTML for the page regions and real anchors for routes:

<a class="skip-link" href="#main-content">Skip to main content</a>

<header>
  <a href="/">Acme</a>
  <nav aria-label="Primary">
    <a href="/docs">Documentation</a>
    <a href="/pricing" aria-current="page">Pricing</a>
    <a href="/support">Support</a>
  </nav>
</header>

<main id="main-content">
  <h1>Pricing</h1>
</main>

<footer>
  <nav aria-label="Legal">
    <a href="/privacy">Privacy</a>
    <a href="/terms">Terms</a>
  </nav>
</footer>

The W3C landmarks pattern explains that main and nav create landmark regions that assistive technology can use to move around a page. When a page has multiple navigation landmarks, label them by purpose, such as Primary, Account, or Legal. Do not label every nav as Navigation; identical names make the regions harder to distinguish.

Use <a href> for navigation and a button for an action that changes the current interface. Google's crawlable links guidance recommends anchor elements with resolvable href values so crawlers can discover destinations. The same markup also gives browsers the expected open-in-new-tab, copy-link, and history behavior.

Write link labels that identify the destination

Test each navigation label without relying on its icon or surrounding card. Documentation, View pricing, and Contact support describe a destination. Learn more, Explore, and an unlabeled icon require context that may disappear in a link list, voice command, or automated report.

The WCAG link-purpose explanation describes why users need to determine a link's purpose from its text or programmatic context. For primary navigation, the label should usually stand on its own.

Check that:

• an icon-only menu control has an accessible name such as Open primary navigation;
• opening the menu changes aria-expanded from false to true;
• the label remains accurate when the control closes the menu;
• links with the same destination use compatible wording across layouts;
• external destinations are named clearly enough that the change of site is not surprising.

If a link or menu button has no usable name, follow the accessible name testing guide before debugging its click handler.

Show the current page and keep navigation predictable

Mark one link in a navigation set with aria-current="page" when it represents the current page. The MDN aria-current reference documents how the attribute exposes the current item to assistive technology. Keep a visible current-page style as well; the ARIA state does not replace the visual cue.

Repeated navigation should keep the same relative order across comparable pages. The WCAG consistent navigation guidance notes that predictable order helps people find repeated controls without relearning each page.

Test at least three representative routes rather than only the home page. Confirm that the same label still points to the same destination, the active state moves to the new page, and conditional account or locale links do not reorder unrelated items.

Test the responsive menu as a user flow

Resize the deployed page to the smallest supported width and test the menu from a fresh load. Do not stop after confirming that the menu icon is visible.

Check this sequence:

1. Focus or tap the menu control.
2. Open the menu and confirm its state is announced.
3. Move through every visible item in a logical order.
4. Confirm focus is not hidden behind the menu or sent into the page underneath it.
5. Select a critical route and verify the final page.
6. Return, reopen the menu, and close it without selecting a route.
7. Confirm that focus returns to the menu control when appropriate.
8. Rotate or resize the viewport and check that the menu does not remain stuck open.

The W3C menus tutorial covers menu structure, visible states, and keyboard behavior. A site navigation list normally needs native links and a disclosure button, not desktop-application menu roles and custom arrow-key behavior.

Use the mobile website testing guide for overflow and narrow-layout checks, then follow the keyboard accessibility testing checklist for visible focus and trap testing. Those checks complement navigation testing without turning one CI test into a claim of accessibility conformance.

Verify destinations and failure recovery

For every critical route, record the requested path, redirect chain, final URL, response status, page title, and main heading. A navigation link can appear to work while a redirect sends it to a generic home page or an application shell renders an error beneath a 200 response.

Check query strings and fragments when they carry meaningful state. A documentation link to /docs#authentication should land on an existing target. A pricing link with campaign parameters should preserve only the parameters your measurement plan expects.

Then test one bad route. The response should be a real 404, keep useful site navigation, and offer a recovery path. The broken link testing guide covers response probes, fragments, client-side routes, and 404 verification in more depth.

Add Playwright navigation testing to CI

Automate a few high-value routes instead of clicking every header and footer link in one brittle test:

import { expect, test } from "@playwright/test";

const routes = [
  { name: "Documentation", path: "/docs", heading: "Documentation" },
  { name: "Pricing", path: "/pricing", heading: "Pricing" },
  { name: "Support", path: "/support", heading: "Support" },
] as const;

for (const route of routes) {
  test(`primary navigation reaches ${route.name}`, async ({ page }) => {
    await page.goto("https://example.com/");
    await page.getByRole("link", { name: route.name, exact: true }).click();

    await expect(page).toHaveURL(new RegExp(`${route.path}/?

  
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
  




  
    ));
    await expect(page.getByRole("heading", {
      level: 1,
      name: route.heading,
    })).toBeVisible();
  });
}

Playwright's page assertion documentation shows that toHaveURL retries until the page reaches the expected URL. Pair it with a page-specific heading or control so a redirect to an error shell cannot pass unnoticed.

Add one mobile-project test for the disclosure menu. Assert the control's accessible name, expanded state, and selected destination. Keep exhaustive link response checks separate from browser-flow checks so a single third-party outage does not obscure a broken primary route.

Run website navigation testing with Slop Audit

Run a Slop Audit on the deployed page to add public-URL evidence to this website navigation testing checklist. During its bounded Browser Run, Slop Audit renders mobile and desktop viewports, counts header, navigation, main, and footer landmarks in the rendered DOM, and reports clearly named pricing, documentation, support, contact, or help routes that appear as visible links. It also checks visible placeholder destinations, mobile overflow, clipped or off-screen controls, keyboard focus evidence, and the selected primary action's destination.

The scan does not open every menu, click every link, crawl the entire site, judge the quality of the information architecture, or certify WCAG conformance. Use its evidence to choose the first route or control to investigate, run the manual flow, fix the implementation, and rescan the same public URL.

Navigation release sign-off

critical routes → descriptive labels → nav and main landmarks
→ current-page state → responsive menu → keyboard and touch
→ final URL and heading → 404 recovery → CI → deployed scan

A good navigation release check follows the route from label to rendered destination. Test the production markup and behavior together, because a clean component snapshot cannot prove that a visitor can find and reach the right page.