Mobile Friendliness
Concept
Whether text stays readable and buttons stay pressable on a small screen, which is one of the factors ranking rules use directly.
Why it exists
When web pages were built against desktop screens, how they looked on a phone was something you got to later. That order inverted once search engines moved their evaluation to the mobile view. The bot reads the page at a small width and ranks it on what it finds there, which leaves the people building the page looking at one screen while the judgment happens on another.
Pagedeck's blog sat in that state. Opened on a desktop there was nothing wrong with it, and the post stayed on the second page of results for six months. Opened on a phone, the feature comparison table ran past the edge and pushed the page sideways, and the subscribe and share buttons were close enough together that a finger couldn't pick one.
Under technical SEO, the work of making a site legible to search engines, this belongs to the performance group. Most technical items never have their ranking effect disclosed; the two in this group are among the few confirmed to enter the ranking rules directly.
How it works
Five things get checked.
- Type size. Whether it reads without zooming. Set body text around 16; drop it to 14 because it looks large on a desktop and it stops being readable on a phone.
- Pressable area. There has to be enough room for a finger, plus space between two adjacent buttons. Even where the icon art is 16, the touch target gets set near 44.
- Horizontal scroll. Content must not exceed the screen width. Tables and code blocks overflow most often, and wrapping just those two solves most cases.
- Anything covering the content. A large pop-up that appears immediately for somebody arriving from search is its own penalty. If the first thing they meet is a close button, the page counts as unread.
- The width declaration. Without the one line telling the browser to fit the page to the device width, it renders at desktop width and shrinks the whole thing. That single line is behind most complaints about small text.
Implementation goes through responsive design, where layout shifts with screen size. It looks at something different from Core Web Vitals, the other item in the performance group: this one asks whether things are visible and pressable, that one asks how fast they arrive.
How it sounds at work
"Did you open it on a phone? The table runs off the edge and pushes everything sideways."
Somebody checked on desktop only and moved on.
"Firing this pop-up straight at search traffic is a penalty. Let's push it past the first scroll."
Saying that covering the content affects ranking.
"The viewport declaration is missing, so the whole page renders shrunk."
Tracing small text back to one line.
At Pagedeck, Ravi opens every new post on a phone once. Noa's mockups start from the narrow width, so they cause few problems; the problems usually come from tables pasted into the posts.
Where to go next
- Technical SEO
see which set this item belongs to
- Core Web Vitals
the counterpart in the same performance group
- Responsive design
how this item actually gets implemented
Last updated 2026-09-16