Your website
Does it matter if my website hides content on phones?
The short answer
It matters more than most people expect, because Google states that only the content shown on the mobile site is used for indexing. Hiding content behind an accordion is fine, since the words are still on the page. Removing it on phones, or loading it only when somebody taps, is not.
The desktop version of your site is not the version that counts. Google says so in one sentence: "Only the content shown on the mobile site is used for indexing."
So the question is not whether the phone layout looks tidy. It is whether the words you want to rank for are present on it.
That turns a design decision into a traffic decision. It is usually made by somebody who was asked to make the page look cleaner on a small screen.
Google indexes the phone version, and only that
This is the whole mechanism, and Google states the consequence rather than leaving you to infer it.
If the mobile page carries less than the desktop page, the warning is explicit: "If it's your intention that the mobile page should have less content than the desktop page, you can expect some traffic loss when your site is enabled mobile-first indexing, since Google can't get as much information from your page as before."
Read the reasoning in that sentence. It is not a penalty. Google simply has less to work with, so the page is understood less well and matches fewer searches.
That reframes a familiar conversation. "We trimmed it for mobile" is not a neutral design choice. It is a decision about which version of your content search engines get to read, and the trimmed one wins by default.
Hiding is not the same as removing
Here is the distinction that decides most real cases, and it is finer than the usual advice admits.
Google is comfortable with content that is present but collapsed: "Instead of removing content, consider moving content into accordions or tabs to save space." It repeats the point when describing design freedom: "You can have a different design on mobile to maximize user experience (for example, moving content into accordions or tabs); just make sure that the content is equivalent to the desktop site, since indexing on your site comes from the mobile site."
So an accordion is fine. The words are in the page, merely folded away.
What is not fine is content that does not exist until somebody acts. Google is blunt: "Google won't load content that requires user interactions (for example, swiping, clicking, or typing) to load."
That is the line. Collapsed content is indexed. Content fetched on tap is not, because nothing taps. Two designs that look identical to a visitor sit on opposite sides of it. Only the code tells you which one you have.
Google explains why in one sentence, on a separate page about deferred loading: "The methods mentioned don't rely on user actions, such as scrolling or clicking, to load content, which is important as Google Search does not interact with your page."
That is the rule underneath every example. Nothing scrolls. Nothing taps. Nothing types. Whatever the page has not produced by the time it is rendered does not exist as far as indexing goes.
Deferred loading itself is not the problem, and Google says so plainly: done properly it is "a common performance and UX best practice". The warning is about the implementation: "if not implemented correctly, this technique can inadvertently hide content from Google." The fix is to load content when it enters the viewport rather than when somebody acts. Endless scrolling needs the same treatment. Google asks that each chunk gets "its own persistent, unique URL", so the content exists at an address rather than only part way down a feed.
There is a softer caveat worth carrying too. Even matching content can be read differently: "Even with the equivalent content, differences in DOM or layout between desktop and mobile page can result in Google understanding the content differently."
A completely different fault looks exactly the same
Before blaming the content, rule out a missing tag, because the symptom is identical and the fix is one line.
MDN explains why the viewport meta tag exists, and the reason is stranger than most people assume: "Because mobile browsers tend to lie about their viewport width."
The consequence follows directly: "If you've got a narrow screen layout that kicks in at 480px viewport width or less, but the device is saying it is 980px wide, that user will not see your narrow screen layout."
So without that tag your responsive design never engages. The phone renders the desktop layout and zooms out. Nothing is technically hidden and everything is unreadable. To an owner that looks exactly like a mobile site that dropped content.
MDN gives the remedy in a sentence: "So you should always include the viewport meta tag in the head of your documents."
Worth knowing because the two problems get confused constantly. One is a content decision with a search consequence. The other is a missing line in the page head with no search consequence at all, just visitors who pinch and squint.
What the phone in your hand does not tell you
Your own device is a poor test instrument, for a reason that has nothing to do with your site.
Google describes what it actually evaluates as "the rendered page", which is how Google sees your page rather than how your phone draws it. Those differ whenever a resource is blocked from crawling. They differ when content depends on an interaction. They differ when the mobile page carries different robots instructions.
That last one is worth stating plainly, because it is silent and severe: "If you use a different robots meta tag on the mobile site (especially the noindex or nofollow tags), Google may fail to crawl and index your page when your site is enabled for mobile-first indexing."
A page can look perfect in your hand and carry an instruction telling search engines to ignore it. Nothing about the visible page reveals that.
What to check, in order
Five checks, and the first four are free.
- View the page source on the mobile version and search it for a sentence you want to rank for. If the words are not in the source, they are not indexed, whatever the screen shows.
- Confirm which kind of hiding you have. Collapsed in an accordion is safe. Loaded only after a tap or swipe is not.
- Check the head of the document for the viewport meta tag before investigating anything else. Its absence explains a zoomed-out page instantly.
- Compare the robots meta tags on the mobile and desktop versions. They should match.
- Count the words on both versions before arguing about design. The gap is the size of the problem.
Do that count rather than estimating it, because the arithmetic is blunt and useful. Suppose a service page runs 1,200 words on desktop and the mobile template trims it to 700. Google indexes the 700. The other 500 words, including the phrases somebody chose deliberately, are not part of what the page can match against.
That is a 42 percent reduction in what the page says, produced by a styling decision nobody logged as a content change. The numbers are an illustration, and the method is the point: put the two versions side by side and measure, because the difference is invisible while you are looking at either one on its own.
Working out whether a mobile layout is costing a page its content, and which of these two faults you actually have, is part of what we do on websites.
Sources
- Mobile site and mobile-first indexing (Google Search Central)
- Responsive design (MDN Web Docs, Mozilla)
- Fix lazy-loaded content (Google Search Central)
Last reviewed 2026-09-12.