Do Links Inside Accordions and Tabs Still Count?

Yes, provided the link is present in the rendered HTML before anyone clicks anything. Google indexes and ranks content inside collapsed accordions, tab panels and <details> elements normally, and links inside them are crawled and followed normally. The pattern that fails is different: content fetched or built by JavaScript only when the user interacts.

The confusion is old and worth clearing up, because the advice that "hidden content doesn't count" was correct once and hasn't been for roughly a decade.

The rule that decides every case

Forget how the section looks. One question settles it:

Is the <a href="..."> in the page's rendered HTML before any user interaction?

If yes, it counts. display: none doesn't remove an element from the document — it's in the DOM, the crawler parses it, the link is followed. If no, it doesn't exist as far as a crawler is concerned, because crawlers don't click accordions.

Everything below is a variation on that one test.

Why the old advice existed

Before mobile-first indexing, Google's stance was genuinely different. Hiding text with CSS was a spam technique long before it was a UI pattern, and Google's advice through the mid-2010s was that content hidden by default might be treated as less important than visible content — sensible when the dominant reason to hide text was to stuff it.

Mobile-first indexing changed the calculation. On a phone, collapsing content into accordions isn't a trick, it's the only reasonable way to fit a spec sheet or an FAQ on a small screen. Once Google was indexing the mobile version of pages as the primary version, discounting collapsed content would have meant discounting most well-built mobile pages.

Google's mobile-first indexing guidance now states the position directly: you don't need content expanded by default, and content in tabs and expandable sections is indexed. Google's search advocates have restated it repeatedly since. If you're still working from advice that predates this, see what is mobile-first indexing for the wider shift it belongs to.

Which patterns pass and which don't

Pattern	Counts?	Why
CSS accordion — content in HTML, toggled with `display`/`height`	Yes	In the DOM at load
`<details>` / `<summary>`	Yes	Native HTML, always in the DOM
Tab panels where all panels ship in the HTML	Yes	Only one is visible; all are parsed
Framework-rendered tabs where all panels render client-side	Yes, usually	Present in the rendered HTML after Google's render step
"Read more" that expands existing text	Yes	Text was already there
Content fetched by `fetch()` on click	No	Never in the DOM for a crawler
Tab panel built by JS only when its tab is activated	No	Same problem
"Load more" that appends new items on click	No	Crawler sees only the first batch
Infinite scroll with no paginated URLs	No	Nothing to crawl past the first view
Modal whose contents are injected on open	No	Same problem

The split isn't visible-vs-hidden. It's present-vs-absent. A section can be invisible and count; a section can be one click from visible and not count.

How to check your own pages in two minutes

Three methods, in increasing order of authority:

View the rendered DOM. Open DevTools, use Inspect rather than View Source, and search the Elements panel for the link. View Source shows the HTML the server sent; Inspect shows the DOM after JavaScript has run, which is closer to what Google indexes. If the <a href> is there with the accordion closed, you're fine.

Disable JavaScript and reload. If the links survive, every crawler will see them — including the AI crawlers, which render far less JavaScript than Googlebot does. This is the strict test, and passing it is a real advantage.

Use the URL Inspection tool in Search Console. "Test live URL" then view the rendered HTML. This is Google's own render, so it's the definitive answer for Google specifically.

If a link fails these, it's not a hidden-content problem, it's a JavaScript link problem — and do JavaScript links pass SEO value covers the specific patterns that break.

Indexed and counted is not the same as weighted identically

Here's the nuance most articles skip, and it's worth stating honestly.

Google has been explicit that collapsed content is indexed and used for ranking. That's a settled question. Google has not published anything saying that a link's weight is unaffected by whether its section is expanded by default.

Those are different claims, and there's a reason to think they might diverge. Link weighting is widely understood to involve estimated click probability — the "reasonable surfer" idea covered in does link position on a page matter. A link two clicks deep inside a closed accordion at the bottom of a page is, plausibly, less likely to be clicked than the same link in an open paragraph.

There's no public confirmation either way, so treat it as an unresolved edge rather than a fact. The practical consequence is small but real:

For your own internal links, don't hide your most important navigation paths inside accordions. It probably doesn't hurt, and putting them in the open definitely doesn't.
For a backlink you've earned or traded, an accordion placement counts, but an in-content paragraph is still the better ask.
Don't rebuild a working accordion out of anxiety. The gap, if it exists, is small next to relevance.

Where collapsed content genuinely hurts

Not through a penalty — through second-order effects:

Nobody links to what nobody reads. If your best explanation is behind a closed tab, it earns fewer citations and fewer links than the same text in the open. The damage is to link acquisition, not to indexing.

AI answer engines render less. Googlebot executes JavaScript competently. Many AI crawlers do far less. Content that depends on client-side rendering to appear is at higher risk of being invisible to the systems that decide what gets quoted in AI answers.

Agents and assistive tech read the accessibility tree. An accordion built from <div>s with click handlers, no button element and no aria-expanded is hard for a screen reader and hard for an automated agent. Native <details> or a properly labelled button solves both at once.

Over-collapsing hides the answer. If the direct answer to the page's core question is inside a closed panel, you've made it harder for a reader to find and harder for a search engine to lift into a snippet. Put the answer in the open; collapse the detail.

Practical guidance

Ship every panel's content in the HTML. Toggle visibility, don't fetch on demand.
Prefer <details>/<summary> or a real <button> with aria-expanded over div-and-click-handler accordions.
Keep the page's primary answer and primary internal links outside any collapsed section.
Never use an accordion as a container for keyword text nobody is meant to read. That's the behaviour the old warnings were about, and it's still a spam signal.
Give paginated alternatives to infinite scroll, so there are URLs to crawl.
Re-test after any redesign. Accordions are exactly the component a framework migration quietly converts to lazy loading.

If you're trading or earning links, this is the sort of thing worth verifying rather than assuming — a placement that lands in a collapsed FAQ block behaves differently from one in the article body. Backlinkster checks each exchanged placement live with code so you can see where a link actually ended up and whether it's still there. Free accounts get five verified swaps a month; the plans are here.

Frequently asked questions

Do links inside accordions and tabs count for SEO? Yes, as long as the link is in the rendered HTML before any interaction. Google indexes and ranks content in collapsed sections and tab panels normally. Links that only appear after JavaScript fetches or builds the content on click are not seen at all.

Does display: none stop Google following a link? No. display: none hides an element visually but leaves it in the DOM, so the crawler parses it and follows the link. Using it to conceal keyword text from readers is still a spam problem, but that's about intent, not the CSS property.

Was hidden content ever discounted? Yes. Before mobile-first indexing, Google's advice was that content hidden by default might be treated as less important. Mobile-first indexing changed that, because collapsing content is a normal and necessary pattern on small screens.

Do links in "load more" sections or infinite scroll count? Usually not. If clicking "load more" fetches new items that weren't in the HTML, a crawler never sees them. The fix is paginated URLs that can be crawled directly, alongside the infinite scroll for humans.

Is a backlink in a collapsed FAQ worth the same as one in the article body? It counts, but an in-content placement is the better ask. Google confirms collapsed content is indexed and ranked; it hasn't confirmed that link weight is unaffected by visibility, and click-probability-based weighting gives a reason for mild caution. The difference is small next to the relevance of the host page.

How do I test whether my accordion links are crawlable? Inspect the rendered DOM in DevTools with the accordion closed and search for the <a href>. Then disable JavaScript and reload — if the links survive that, every crawler will find them. Search Console's URL Inspection "Test live URL" gives you Google's own rendered HTML as the final check.

The bottom line

The question isn't whether content is visible, it's whether it's there. Collapsed accordions, tab panels and <details> elements are all fine; Google has said so plainly since mobile-first indexing landed, and the old warnings are about a different practice. What breaks is content that doesn't exist until someone clicks — and that breaks for AI crawlers far more often than for Google. Inspect the rendered DOM once, fix anything that fetches on interaction, and keep your most important links and your core answer out in the open.