Technical foundations
Turn clickable navigation into discoverable links
Audit important navigation destinations, replace script-only links with real anchors, and verify direct access and keyboard behavior.
TL;DR
- Use real links with useful destinations for navigation to important pages.
- A clickable div or script-only control does not provide the same discovery path as an anchor with an href.
- Keep buttons for actions, and let navigation links retain normal browser behavior.
- Test the destination, rendered markup and keyboard use after the change.
A navigation item should expose where it goes. A product card may open a page through a JavaScript click handler. A person can click it, but a crawler may not be able to extract the URL.
Google's crawlable-link guidance recommends an HTML anchor with an href that resolves to a real URL. JavaScript can insert such links, but script events on other elements are not a dependable replacement.
Audit destinations before auditing every component
Start with the pages that matter to a buyer's next decision: product categories, service pages, locations, comparison guides and contact information. Find how a visitor reaches each one. Inspect the actual HTML rendered in the browser, rather than relying on a component's name in the codebase.
A framework component called Link may output a proper anchor. A styled element called NavLink may not. Likewise, a button-looking element can be a real link. The appearance does not settle the question.
Use this worksheet to turn the review into small, testable fixes:
| Check | Acceptable evidence | Repair if missing |
|---|---|---|
| Destination | A meaningful href points to the intended page. | Add the real page URL to an anchor. |
| Label | Link text explains the destination in context. | Replace vague or misleading text. |
| Direct access | The URL opens the expected page in a fresh session. | Repair routing, redirects or access dependencies. |
| Keyboard use | The link receives focus and opens with Enter. | Restore native link behavior and visible focus. |
| Discovery | A relevant public page contains the link. | Add it where a buyer would look for that destination. |
Worked example: fix a product-card destination
Illustrative example: a fictional equipment catalog.
The category page displays a product card labeled “SL-40 solar street light.” Clicking works, but inspecting the element shows this:
<div class="product-card" onclick="window.location.href='/products/sl-40'">
SL-40 solar street light
</div>
The developer confirms that the product has a working public URL. The issue is the card's markup, so no new landing page is needed. The revised version exposes the same destination directly:
<a class="product-card" href="/products/sl-40">
SL-40 solar street light — specifications
</a>
The visual style can stay in the CSS class. If the card also has an “Add to quote” action, place that action beside the link as a separate button; do not nest an interactive button inside a large clickable link.
The tester opens the product URL directly, then uses the card with a mouse and keyboard. The browser's link destination is visible, opening in a new tab preserves the product choice, and focus remains clear. The developer checks the desktop and mobile menus. They may use different components.
The finished ticket includes the source page, destination URL, old markup, new markup and test results. This shows that the navigation defect was fixed. It does not claim that a search engine has already crawled or indexed the destination.
A 2021 SearchPilot test found no detectable organic traffic effect on pages where hidden JavaScript links were exposed. It did not measure the effect on the newly linked destinations. That limit matters: fix a clear discovery or usability defect, then measure the result on the pages you care about. SearchPilot test and scope.
Make navigation useful to readers as well
Group related links and label the navigation region when its purpose might be unclear. The W3C menu structure tutorial explains using lists, navigation regions and descriptive labels to support orientation.
Check link text outside the visual layout. “View details” may be understandable on one card, yet confusing when a screen reader presents several similar links. A product or service name gives more context. Keep the label true to the page it opens.
Also test where the URL ends up. Even a proper link can go to the wrong place. Check for expired pages, unexpected logins and redirects to the homepage. Fix the destination or update the link based on the content's real status.
Crawlable navigation: common questions
Can we keep client-side routing?
Yes. Keep a real destination in the rendered anchor and verify direct page access. Client-side transitions and native link markup can coexist.
Is a button always wrong?
No. Buttons fit actions such as opening a dialog, submitting a form or changing a filter. Use a link when the intended action is navigation to a document or page.
Will a sitemap compensate for broken navigation?
Do not use it as a substitute for a useful route through the website. A sitemap and a visitor-facing link solve different problems. Important pages should be reachable where buyers expect to find them.
Semanta checks this under findability and actionability in its service-page audit framework. If a shared component affects many high-value pages, bring the affected templates and destination list to discuss a navigation review.