Product Card Links: Anchor Text and Crawlability

A product card is crawlable when it contains a real link: an a element whose href attribute holds the product URL, with anchor text that names the product. Google's crawlable links page (Opens in a new tab) puts it plainly. Google can crawl a link only when it is an a element with an href, and anchor text should sit between those a elements. If you build list and card interfaces as a front-end developer, or audit them for SEO, three design choices ride on that one rule: how you make the whole card clickable, what the visible link text says, and how many related-product links you place on a product page. Examples here use a single category: wooden toys.

What a crawler sees when the whole card is clickable

A toy card holds a photo, a name, a price, a seller line, a badge such as "handmade", and a button. Practical suggestion: let the whole card respond to a tap. A crawler does not read taps. It reads markup. Google's documentation defines a crawlable link as an a element with an href attribute, and it says Google cannot reliably extract a URL from an a element that has no href. Google's ecommerce site structure page (Opens in a new tab) says the same in practical terms: use a href tags to link to other content, and do not use JavaScript events on other HTML elements for navigation.

So "clickable card" is a user-facing description and "crawlable link" is a markup requirement. They can coincide, but only if you make them coincide on purpose.

Five ways to build the card

The documentation does not prescribe the internal structure of a card. It prescribes what a link must look like. Table: Card structures. This comparison is practical suggestion built on those requirements.

Table: Card patterns for a wooden toy listing

Decision rule: the card needs one real link whose text is the product name. If you want the full card to react to a tap, extend that link's hit area. Do not remove the link and replace it with a script.

Which link forms Google accepts

Google's page pairs each recommended form with a discouraged one. The recommended forms are standard a elements with a resolvable href. The discouraged forms include an element that carries the address in a different attribute (the page names a span with href and a framework routing attribute as examples) and an a element with no href that navigates through onclick. The page also lists a href containing a javascript: call among the discouraged forms.

Two details matter for card components. First, the href must resolve to an actual web address. Second, links inserted into the page with JavaScript are crawlable too, provided they use the standard a href markup. Rendering cards on the client is therefore not the issue; the form of the link inside the card is.

Table: Link forms and what the page says

Example scenario: a puzzle card that goes nowhere

Example scenario: a marketplace lists wooden puzzles, stacking blocks and pull-along animals. Its cards are produced by a single-page app, and each card is a div whose click handler calls a router function with the listing id. Shoppers notice nothing wrong. Yet the list page contains no link to any listing. The fix is to render the product name as an a element whose href is the listing address. The click handler may stay for analytics, as long as the link carries its own destination and does the navigating.

Whether the fix worked cannot be judged from the screen. It has to be confirmed in the page source and in the rendered HTML.

Writing the link text

Google describes good anchor text as descriptive, reasonably concise and relevant to the page it links to. It suggests a test: read the anchor text on its own and see whether it makes sense. "Click here" fails; a phrase naming the subject passes. For the general principle, see the article on descriptive link text. Card-specific choices follow here.

Table: Candidate link texts on a toy card

Decision rule: put the product name in a link, keep price, badges and ratings in separate elements, and let a "View" button stay as a visual cue that does not replace the name link.

Image links and alt text

Google states that it uses the alt attribute of an image as anchor text when the link contains only an image. When the photo is its own link, give it alt text that names the product. When the photo sits inside the name link and adds nothing the name does not already say, an empty alt is reasonable. That second part is practical suggestion.

Empty links and the title fallback

The page says Google may use the title attribute as anchor text if the a element is empty for some reason. Treat that as a safety net rather than a technique. A visible product name inside the link is the dependable choice.

Several links to one target

When photo, name and button all point to the same URL, note that the links page warns that chaining links together makes it harder for readers to tell them apart. Practical suggestion: reduce the number of links per card, and merge them into one name link where the design allows.

Related-product modules: how many links and which ones

A related-product module is a block of links from one product page to others. Google's ecommerce page says that the more links a page has pointing to it within a site, the higher its relative importance. The links page adds two statements: every page you care about should have a link from at least one other page on the site, and there is no magical ideal number of links a page should contain. The broader framework for this is covered in the article on internal linking strategy.

Taken together, the statements set one requirement and leave one question open. The requirement is that important products get linked from somewhere. The open question is how many links a module should hold. The decision belongs to usefulness: show enough alternatives and companions to help a shopper decide, and no more.

Table: Design criteria for a related-products block

Linking to a sold-out listing

A link to a listing that has been removed sends the shopper and the crawler to a dead end. Practical suggestion: check item status when the module is generated, and exclude listings that are not for sale. What a removed listing's own page should return is a separate decision.

Example scenario: the train set page

Example scenario: the page for a wooden train set first showed eight random items from the same category. The team rebuilds the module: three alternative train sets, three companions (extra track, a bridge, a station) and two items from the same maker. Each card carries a name link. Items that have sold stay out. Shoppers get more useful choices, and Google's statement about linking important pages is met for the companion products.

Personalized suggestions

Some marketplaces vary suggestions per visitor. It says only that standard a href markup is crawlable. Practical suggestion: treat personalization as an extra layer for the visitor, and keep a fixed set of related links that every visitor and every crawler sees. That way important listings do not depend on a session.

Decision rule: do not rely on a personalized module as the only inbound link to a listing. Every product should receive at least one link from a stable category list or a fixed related block.

Instrumenting clicks without breaking links

Teams that measure card clicks add tracking to cards. Google's page lists an a element with a real href and an onclick handler as a recommended form, so tracking and crawlability can coexist, provided the link keeps its own address and the handler does not take over the navigation.

Table: Two ways to add tracking

Practical suggestion: attach one listener to the list container and leave the default behavior of the link alone. A redesign of the card then cannot silently remove either the measurement or the link.

Pagination, load-more buttons and the search box

How a list loads decides which cards exist in the first HTML. The documentation read here has no statement on infinite scroll or on pagination design. What it does say is that products reachable only from a search box are a problem: the ecommerce page notes that products may be reachable from a search box but not through category browsing, and it asks for a path from menus to categories to subcategories to products.

Practical suggestion: make the control that opens the next page of a list a real link, and keep the scrolling experience if you prefer it. Cards beyond the first batch should then have an address-based path.

Example scenario: endless scroll in the building-blocks category

Example scenario: the building-blocks category shows twenty cards at load and fetches more as the shopper scrolls. There is no URL for later batches. The team adds paginated URLs, and the "next page" control becomes an a href while the scroll behavior stays the same for shoppers. Later cards are now reachable by links. This is an application of the link rule, not a pattern Google recommends by name.

One component, several list contexts

The same card component appears on category pages, search results, seller storefronts, related-product blocks and the home page. The link requirement is identical in each place, but the reason the link matters differs, and the component owner should know which context is at stake.

Table: Contexts for the wooden toy card

Google's ecommerce page states that products may be reachable from a search box but not through category browsing, and it asks for links from menus to category pages, from category pages to sub-category pages and on to products. A toy that appears only in search results and in no category list is a gap in link structure, and no card markup closes it.

Link text rules with wooden toy examples

A product name works well as link text because it says the subject when read alone. Names that carry variants, brand and model can grow long, and Google's guidance says only "reasonably concise" without giving a length.

Table: Examples for the name link

Google advises against keyword stuffing and asks for natural writing. If the card shows the seller's listing title, then whatever the seller types ends up in the anchor. Practical suggestion: set a length limit and a content rule in the listing form (no prices, no promotion phrases), so the card link text improves together with the title.

Brand names at the start

If a seller's catalog places the same brand name at the start of every title, a list page contains dozens of links beginning with one word. Nothing in the documentation forbids that. The read-it-alone test favors a product type and a distinguishing feature, though. Practical suggestion: put the brand after the product type, or show it in its own element.

Who decides what in a card change

A card component is touched by design, front-end, product and SEO. A clear owner for each decision prevents a regression from slipping through.

Table: Decision owners

Keeping it healthy over time

Card links are not a setting you change once. A design-system update, a new list type or a storefront refresh can undo them. Practical suggestion: from your own crawl data, list how many internal links point to each product page now and then. Google says every page you care about should have a link from at least one other page. Listings with none have not reached any category list or related block. Share that list with the product owner and assign a place from which each active listing is linked. Listings that receive numerous links but have been sold are a separate clean-up list, and pointing those links to a similar active item serves shoppers better.

Verification steps

Crawlability cannot be judged by looking at the page. For anchor text added with JavaScript, Google says to use the URL Inspection tool to make sure the text is present in the rendered HTML. If your interface is not in English, tool names may look different.

1. Pick one list page and one product page. Compare the card links in the raw HTML response and in the rendered DOM.
2. In each card, find an a element with the product name. Its href must be a real address and must not begin with javascript:.
3. If a card shell navigates only through onclick, add a name link inside it.
4. Read each anchor text on its own. Replace "View" or "Details" with the product name.
5. If the photo is a link on its own, check that its alt text names the product.
6. Inspect the list page in the URL Inspection tool and confirm that the card links are present in the rendered HTML.
7. Repeat steps one to six for the related-products block.
8. Look for links in the block that point to items no longer for sale.

These steps are not a one-time exercise. Repeat them each time the card component changes.

Reading the comparison

Table: What a comparison tells you

Practical suggestion: add two automated tests to the component. One looks for an a element with a product name and a real href in the card output. The other compares the number of a href elements with the number of cards on a sample list page. A count that differs from the card count flags a lost link before release.

Example scenario: a redesign that removed every link

Example scenario: a marketplace redesigns its wooden toy cards. The old card was a single a href, the new one is a div with a "View" button. The pre-release check finds 24 cards and 0 product links on the list page. The team restores a name link, keeps the button as a visual cue and adds the count comparison as a permanent test.

Checklist for crawlable cards

Checklist: product card and related block

• Does each card hold an a element with the product name?
• Is the href a real address rather than a javascript: call?
• Does any card navigate through onclick alone?
• Does the link text make sense when read on its own?
• Have price, badge and rating leaked into the link text?
• For image-only links, does the alt text name the product?
• Were duplicate links to one target reduced?
• Does the related block leave out items that are not for sale?
• Does every important product receive a link from a stable list?
• Does the rendered HTML in the URL Inspection tool show the links?

Mistakes to avoid

Binding the card to a click listener instead of a link

Elements without an href that navigate through onclick are the weak pattern. Keep the link and let the listener sit beside it.

Making "View" the only link

If the product name is plain text and the button is the only link, the anchor text is "View". Put the name inside a link.

Stuffing price and promotion text into the anchor

Google asks for descriptive and reasonably concise text. Keep price and promotion labels outside the link.

Chaining links back to back

The page says chained links are hard for readers to tell apart. Give cards clear spacing and structure.

Generating the module at random

A random related list leaves it to chance whether important listings are linked. Keep a stable source of links for products that matter.

Frequently Asked Questions

Is it a problem if the whole card is clickable?

It asks that the URL be extractable from an a element with an href. If the card's link is a real a href, a larger hit area does not conflict with that requirement.

What if I use onclick instead of href?

Google says it cannot reliably extract a URL from an a element that has no href. The recommended form has a real address in href, and an onclick handler may be added on top of it.

Should the link text be the product name or 'View'?

Google describes good anchor text as descriptive, reasonably concise and relevant. 'View' says nothing on its own, while a product name passes the read-it-alone test.

How many links should a related-products block hold?

The documentation says there is no magical ideal number of links per page and gives no count for such a block. Pick a set that helps shoppers decide and keeps to products that are for sale.

Are personalized suggestions crawlable?

Standard a href markup is crawlable. Practical suggestion: also link important listings from a stable, shared source.

How do I confirm Google can see my card links?

For anchor text added with JavaScript, Google recommends the URL Inspection tool to make sure the text is present in the rendered HTML.

Conclusion

Crawlable product cards rest on three habits: a real a href in every card, link text that names the product when read alone, and a stable source of links to products that matter. Click handlers, "View" buttons and random modules each give up one of these without any visible change on the page. A comparison of raw and rendered HTML, repeated each time the card component changes, shows the loss before release.

With card links in order, you can turn to reach. To bring your listings in front of more shoppers, see the ad spaces.