Link & Button Check
If it looks clickable, it must work exactly as promised. Dead links and broken buttons are the fastest way to frustrate users and lose trust.
1 The Hook — Why This Matters
In 2022, an Auckland animal shelter ran a winter donation campaign. Their homepage featured a big red "Donate now" button. It looked perfect. It was centred, bold, and urgent. The only problem: it linked to a page that had been deleted two months earlier. Every click returned a 404 error.
The shelter raised 40% less than the previous winter. A volunteer discovered the broken link on day 18 of the campaign. One dead button cost thousands in donations and weeks of goodwill.
Links and buttons are promises. When they break, the promise breaks. Testing them is not optional.
2 The Rule — The One-Sentence Version
If it looks clickable, it must work exactly as promised.
A link is a contract. The label tells the user what will happen. The destination must match the label. A button that says "Download" must download. A link that says "Contact us" must lead to a working contact method. Anything else is a defect.
3 The Analogy — Think Of It Like...
Door handles.
If a handle looks like you can pull it, but you must push, it is broken. The design promised one thing and delivered another. Links and buttons are the same. A blue underlined word promises a destination. A rounded rectangle promises an action. If the promise is broken, the user is stuck.
4 Watch Me Do It — Step by Step
Here is a real NZ example: testing a small business website before launch. Follow these steps on every page you test.
Scenario: You are reviewing a Queenstown tour operator's site. The owner says "everything works." You verify.
- Hover over every link Check that the cursor changes and the destination URL appears in the browser corner. Look for unexpected redirects.
- Click every link Navigation, footer, body text, social icons, logos. Every single one. Note any 404s, timeouts, or wrong destinations.
- Test button lifecycle states Check default, hover, active (click), disabled, and loading states. A button that looks the same when disabled is a usability bug.
- Test keyboard activation Tab to every link and button. Press Enter or Space. If it only works with a mouse, it is an accessibility defect.
- Check for orphan buttons Orphan buttons do nothing when clicked. They look clickable but have no attached action. Click every button to confirm it responds.
- Test mobile touch targets On a phone, try tapping small links and buttons. If they are too close together or too small, users will mis-tap.
-
Check special link formats
mailto:links should open an email client.tel:links should trigger a phone call. In NZ, tel: links with spaces or dashes (liketel:0800 100 123) often fail. Usetel:+64800100123instead.
| Element | Test | Result |
|---|---|---|
| "Book now" button | Click, check destination | Pass |
| "Donate" button | Click, check 404 | Fail — 404 |
| Phone link | tel:0800 100 123 | Fail — dashes break it |
| Facebook icon | Click, check URL | Fail — old page URL |
| Disabled "Sold out" button | Visual state + no action | Pass |
Three defects in seven checks. The owner thought "everything works" because the main navigation loaded. They never tested the donate button, the phone link, or the social icons.
Scenario 2: Network-dependent link failure reveals environment issues.
A site works perfectly on your desktop. But when you test on a different network (mobile hotspot, offline mode), external links to third-party services fail silently. The app assumes the internet connection is always available.
| Link | Works Online | Works Offline / Slow Network | Issue |
|---|---|---|---|
| Internal page link | Yes | Yes | No issue |
| External partner API | Yes | Hangs 20s, times out | No timeout handling |
| Embedded map | Yes | Blank / error not shown | No error message |
| Analytics tracker | Yes | Hangs entire page | Blocking script |
The lesson: test links on different networks. An external CDN link might fail on a slow 3G connection while your local WiFi works fine. Users in rural NZ on slower networks will experience failures you never see.
5 When to Use It / When NOT to Use It
✅ Do it when...
- A new page or site is ready for review
- Navigation, footer, or contact details changed
- Social media or partner links were updated
- You are doing a pre-release sanity check
❌ Skip it when...
- You are testing back-end APIs with no UI
- The build changed only CSS colours
- You already ran an automated link checker and reviewed its results
Before you apply this technique, ask:
- Does your app have external links, social media icons, or partner integrations?
- Are you testing an internal API or a public website with clickable elements?
- Do you have access to real devices for testing tel: and mailto: links?
- Is network connectivity an issue (users on slow/offline connections)?
6 Common Mistakes — Don't Do This
🚫 Only testing happy-path links
I used to think: If the main navigation works, the links are fine.
Actually: Footer links, social icons, email signatures, and PDF downloads break far more often than main nav. Users discover broken links in the places you forgot to check. Test every clickable element, not just the obvious ones.
🚫 Not checking mailto: and tel: links
I used to think: mailto: and tel: links are simple; they always work.
Actually: mailto: links with missing subject lines, tel: links with spaces or dashes, and tel: links without the +64 country code all fail on some devices. In NZ, tel:0800 100 123 breaks on iOS. Always test special link formats on real devices.
🚫 Ignoring the back button
I used to think: The browser back button is the browser's problem.
Actually: Single-page apps and modal dialogs often break the back button. A user clicks "Open map", hits back, and lands on a different site. If your button changes browser history, test that back works as expected.
🚫 Assuming external links work offline
I used to think: Links to external sites are tested by those sites, not me.
Actually: When your site links to a third-party API, payment processor, or external resource, network failures on your connection affect the user experience. Test links on slow networks (3G) and offline. Add error handling so timeouts are visible, not silent failures.
When this technique fails
Link and button checking fails when you test only on a fast, reliable network. External links that work on desktop WiFi will fail on mobile 3G or in areas with poor connectivity. Also fails if you check only happy-path links (main navigation) and skip secondary links (footer, social icons, mailto: links). Test every clickable element and test on different networks.
7 Now You Try — Interview Warm-Up
Scenario: You are testing a Dunedin café website. Spot the link and button defects in this list:
- "Menu" link in navigation — goes to /menu
- "Book a table" button — goes to /bookings (404)
- Phone number:
tel:0800 100 099 - Instagram icon — links to instagram.com/oldcafehandle
- "Get directions" button — opens Google Maps correctly
Write down every defect before revealing the answer.
Defects found:
| # | Defect | Why it fails |
|---|---|---|
| 1 | "Book a table" 404 | Link points to deleted page |
| 2 | tel:0800 100 099 | Spaces break tel: on iOS; use +64800100099 |
| 3 | Instagram old handle | Social link points to rebranded account |
Tip: The "Menu" and "Get directions" links work. Three out of five clickable elements are broken. That is a 60% failure rate the owner never noticed.
8 Self-Check — Can You Actually Do This?
Click each question to reveal the answer. If you got all three, you're ready to practice.
Q1. Why do tel: links with spaces fail on some phones?
Not all devices parse spaces in tel: URLs. iOS in particular struggles with tel:0800 100 123. Use the international format without spaces: tel:+64800100123. Test on a real device, not just desktop hover.
Q2. What is an orphan button?
A button that looks clickable but does nothing. It may have been styled before the JavaScript was attached, or the click handler was removed. Click every button to confirm it responds. If nothing happens, it is a defect.
Q3. Should you test the back button after clicking a link?
Yes, when the link changes browser history. Single-page apps and modal dialogs often hijack the back button. A user should be able to return to where they started. If back sends them somewhere unexpected, it is a defect.