Testing Links and Navigation
Navigation testing checks that people can move through a site and arrive where they expect: links lead to the right place, menus and breadcrumbs show where the user is, Back returns to the previous view, a URL pasted into a new tab opens the same page, and a mistyped address ends on a helpful "page not found" page.
On a product page, for example, the "Delivery" link should jump to the delivery section, and Back should return to page 2 of the results with the filters kept.
Why it matters
A broken link in checkout stops users when they need the next step; a Back button that loses a filtered search makes them start again; a shared link that opens the home page instead of the product loses the visit. Developers rarely notice: they click forward from the home page and seldom paste URLs, reload or go back.
Links also break when nobody edits the page: a product is removed, a section is renamed. That makes navigation a regression risk in every release, and its defects are easy to report: one page, one link, one wrong destination.
What to check on every link
A link, the <a href> from the lesson on HTML for testers, works when its destination exists, matches its text and opens as the team intended:
- Destination: a "Return policy" link that opens the general help centre is a defect, even though no error appears.
- Link text: ten "Read more" links are indistinguishable in a screen reader's list of links. WCAG 2.2 success criterion 2.4.4 Link Purpose (In Context) requires the purpose to be clear from the text and its context.
- Target:
target="_blank"opens a new tab, where Back does nothing. Check the team's rule (often: external sites and documents only) and that such links say so. - Anchors:
#deliveryscrolls toid="delivery". The match is exact (#Deliveryfinds nothing), and a missing target fails silently, with no error and no scroll. A sticky header must not cover the heading. - Schemes:
mailto:andtel:open the mail or phone app with the right address or number. - Environments and encoding: no link points to
localhostor another environment, and a percent-encoded Arabic path (%D8%B9is ع) works both when clicked and when pasted.
Broken links, status codes and a first look at redirects
The HTTP status code a link's URL returns, seen in the DevTools Network panel or a link checker, shows whether it is broken. 200 OK: found. 404 Not Found: not found. 410 Gone: removed intentionally (RFC 9110). A 5xx code or a timeout is a server or network failure, not a wrong link: retry, then report it with the time and the URL.
Status alone is not enough: a "not found" page returning 200, called a soft 404, passes a simple link checker although search engines treat it as an error. And the #fragment never reaches the server, so only the browser shows whether an anchor works.
A redirect is a 3xx response whose Location header names another URL, which the browser then requests. RFC 9110 defines 301 Moved Permanently and 308 Permanent Redirect for permanent moves, 302 Found and 307 Temporary Redirect for temporary ones; Preserve log in the Network panel shows every hop. The lesson on HTTP redirects goes deeper; here, check that:
- Old URLs from bookmarks and search results reach the matching new page, not the home page.
- There is one hop, no chain and no loop (a loop ends in a "too many redirects" error).
- A query string such as
?page=2&sort=pricesurvives. - Your own pages link straight to the final URL; the trace below works but wastes two hops.
GET http://shop.example.com/help/returns
301 Moved Permanently Location: https://shop.example.com/help/returns
GET https://shop.example.com/help/returns
301 Moved Permanently Location: https://shop.example.com/help/returns/
GET https://shop.example.com/help/returns/
200 OK page title: "Returns and refunds"href point?Answer: A
#fragmenton the pageOutcome: Anchor: check it in the browserThe fragment never reaches the server. An element with exactly thatidexists, the page scrolls to it and no sticky header covers it.Answer: A page, on this site or another
Question 2: What status code does the URL return?Answer:
200Question 3: Is it the page the link text promises?Answer: Yes
Outcome: Working linkAlso check that it opens in the tab the team agreed.PassAnswer: No
Outcome: Wrong target or soft 404A200that shows "not found" or an unrelated page is still a defect.Fail
Answer:
301,302,307or308Outcome: Redirect: follow every hopAcceptable if it ends in200at the matching page, ideally in one hop. Point your own links at the final URL.CautionAnswer:
404or410Outcome: Broken linkReport the source page, the link text, thehrefand the status.FailAnswer:
5xxor no responseOutcome: Server or network errorThe link may be right. Retry, then report a server error with the time and the URL.Caution
Answer:
mailto:ortel:Outcome: Opens the mail or phone appWith the right address or number already filled in.
After a redirect, judge the final response the same way: its status first, then its content.
Worked example: a category renamed in a release
Release note: "The Phones category becomes Mobiles. URLs move from /phones/... to /mobiles/..., and old URLs redirect permanently." The tester's checks follow; NAV-03 failed on staging, as the bug report records.
- NAV-01: the menu item "Mobiles" opens
/mobilesand is highlighted there. - NAV-02:
/phones→301→/mobiles→200, in one hop. - NAV-03:
/phones/nova-12→301→/mobiles/nova-12, the product, not the category. - NAV-04:
/phones?page=2→ page 2 of Mobiles. - NAV-05: the Nova 12 breadcrumb reads "Home › Mobiles › Nova 12" with working links.
- NAV-06: filter a search, go to page 2, open a product, press Back → page 2, filter kept.
- NAV-07:
/mobiles/nova-12in a private window opens the product;/mobiles/no-such-phonereturns404.
Title: Old product URLs redirect to the Mobiles category instead of the product
URL: https://staging.shop.example.com/phones/nova-12
Build: web 3.8.0 on staging
Actual: 301 -> /mobiles -> 200 (category page)
Expected: 301 -> /mobiles/nova-12 -> 200 (Nova 12 product page)
Impact: bookmarks, shared links and search results of every productCommon mistakes
- Checking that a link returns no error, but not that it opens the page its text promises.
- Trusting
200: a soft 404 passes every status check. - Testing navigation only by clicking from the home page, never by pasting a URL, reloading or pressing Back.
- Assuming anchors work because the page loads; only the browser shows whether
#sectionfinds its target. - Reporting a "broken link" without its page, link text,
hrefand status. - Checking links once, although removed content and external sites break them later.
The QA perspective
Navigation checks start when a story adds or moves a page: ask where it appears in the menus, what its URL is, whether an old URL must redirect and where to, and what links to it. A URL change without a redirect plan is a requirement gap; raise it before the release.
Keep a short navigation checklist for regression (menus, breadcrumbs, Back from results, a signed-out deep link, the 404 page) and leave the hundreds of links to an automated check. Report a broken link with its source page, link text, href, status and final URL, plus the hop list for a redirect.
Practice exercise
Plan navigation tests for a moved help centre
A company moves its help centre from /support/... to /help/... and adds a breadcrumb and a menu item "Help". The release note says: "Old support URLs redirect to the new ones. Each article has a table of contents linking to its sections." Write at least eight navigation checks with their expected results.
Then read the staging trace below: which of your checks does it answer, and what would you report?
Link on page: https://example.com/support/returns#refund-time
GET https://example.com/support/returns
302 Found Location: https://example.com/help
GET https://example.com/help
200 OK page title: "Help centre"- List the menu, breadcrumb and content links the change touches.
- Add redirect checks for old URLs, query strings and fragments.
- Add checks for Back, a deep link and the 404 page.
- Compare the trace with your expected results.
Show the model answer
Example checks: "Help" opens /help and is highlighted there; an article breadcrumb reads "Home › Help › Returns" with working links; table-of-contents links scroll to their sections; old URLs redirect in one hop to the matching article and keep #section; an old search URL such as /support/search?q=refund keeps its query string; article links point straight to /help/...; an article URL opens in a private window; Back returns to the search results; /help/no-such-article returns 404.
The trace meets one expectation, a single hop, and breaks three: 302 Found is a temporary redirect for a permanent move (expect 301 or 308; confirm with the team); it ends on the help home page, not /help/returns; and because a browser keeps the fragment when the Location has none (RFC 9110), the user lands on /help#refund-time, a section that does not exist there.
Report: "Old support article URLs redirect temporarily to the help home page instead of the article", with the source link, the hops, the expected 301 → /help/returns → 200 and the impact on bookmarks and search results. The trace answers only the redirect checks; the rest need the browser.
Frequently asked questions
What is the difference between a broken link and a broken anchor?
A broken link points to a URL the server cannot serve, and the status code shows it (404, 410). A broken anchor points to a #fragment with no matching id on the page: the page loads with 200 and simply does not scroll, so you find it only in the browser.
Is a redirect a defect?
No. Redirects are the right way to keep old URLs working after a move. A redirect is a defect when it leads to the wrong page, uses a temporary code for a permanent move, or passes through a chain of hops or a loop. Links on your own pages should still point to the final URL.
Should every link open in a new tab?
No. The default, the same tab, keeps Back working and lets users open a new tab themselves. Teams usually keep new tabs for cases such as external sites or a document opened while filling in a form, and such a link should say that it opens a new tab. Check against the team's rule, not your own preference.
Can link checking be automated?
Yes, and on a large site it should be: a crawler or a test script can request every link and report the status codes. It cannot judge whether a destination matches its link text, does not reliably catch soft 404s and does not test Back or deep links in context, so keep a short manual pass for those.
References
- RFC 9110: HTTP SemanticsThe meaning of HTTP methods, header fields, status codes and content negotiation, independent of the wire version.
- HTML Living StandardThe HTML language, including named character references (entities) and the parsing rules browsers follow.
- Web Content Accessibility Guidelines (WCAG) 2.2The W3C Recommendation that defines the testable success criteria for accessible web content, organised under four principles and three conformance levels (A, AA, AAA).
- Accessible Rich Internet Applications (WAI-ARIA) 1.2The W3C Recommendation that defines ARIA roles, states and properties — how custom widgets expose their meaning to assistive technology.
Practise with Mutqan tools
Trace redirect chains (301/302/307/308) and see every hop, status and final URL.
Look up any HTTP status code with its meaning, RFC reference and when to use it.
Break a URL into protocol, host, port, path, query parameters, fragment and credentials.
Decode percent-encoded URLs and query strings back to readable text.
Parse and build query strings, including repeated keys and bracket-array notation.
Go deeper
Your progress on this topic
Not started
Mark the topic complete when you have studied it and done the exercise.
Sign in to track your progress
Mark topics complete, continue where you left off and unlock specialisation exams.