Fix service cards that navigate only through JavaScript clicks

Identify navigation rather than page actions

Separate a card that opens a service page from a button that submits a form or toggles a panel. These are different tasks. The repair here concerns a destination URL. Record the card label and expected public path, and do not convert every interactive control on the site into a link.

Source checks: Google Search Central: Crawlable link practices · Google Search Central: JavaScript SEO basics

Inspect the actual card element

Use the browser inspector or ask the editor for the relevant HTML. Look for an anchor and its href value. A div with an onclick handler may feel like a link but does not expose the destination in the same reliable way. Google recommends crawlable anchor markup; styling does not determine whether that markup exists.

Use a destination that works independently

Copy the proposed URL into a new signed-out tab. Confirm it returns the intended service, not an editor preview, fragment-only route, or JavaScript expression. Check whether the URL works when requested directly without first visiting the homepage. A card repair cannot compensate for a destination that depends on previous application state.

Preserve the visitor behavior during the repair

Ask for a link that still fits the site's layout.

• Make service-page navigation use an anchor with a usable href.
• Use a concise service label that predicts the next page.
• Keep any enhancement compatible with ordinary opening in a new tab.
• Test keyboard focus and activation on the changed card.
• Verify mobile tapping and the absence of overlapping click targets.
• Check that the rendered page exposes the same destination.

Avoid hidden links and duplicated controls

Adding an invisible text link solely for crawlers leaves the customer-facing navigation problem unresolved. A second overlay link can also interfere with buttons inside a card. Choose a clear interaction model instead of stacking controls. Do not stuff a long list of service and city phrases into the label; readers need to understand the destination.

Verify discovery and usability separately

After publishing, inspect the public card again and test the actual service URL. Record the successful navigation in your release notes. Later indexing evidence may show a discovered route or crawl, but it does not isolate this one change as a ranking cause. The direct outcome is a clearer, more reliable link for visitors and crawlers.

If the site uses a component library, repair the shared service-card component and check two different pages that use it. Write the expected anchor behavior into the editing brief so future card additions inherit it. This prevents a technically correct one-off card from sitting beside several remaining script-only destinations.

Illustrative card linking to a repair page

An illustrative homepage card says Dishwasher repair and runs a click handler that changes application state. Directly opening /dishwasher-repair already works. The editor makes the card label a real anchor to that path, preserves its styling, and tests new-tab and keyboard opening. The change exposes the actual destination without rewriting the service page.

The editor checks the shared card on both the homepage and services overview. Opening its real destination in a new tab confirms that the repair did not merely reproduce the old click behavior in a different wrapper.

Questions about this task