How to Fix Mobile-Unfriendly Elements on a Site
Mobile-unfriendly elements are legacy patterns, like table-based layouts, frames, and Flash embeds, plus broader issues like fixed pixel widths, small tap targets, and undersized text, that break how your page renders on a phone. Google indexes and ranks using the mobile version of your site, so these aren't cosmetic quirks; they're what the algorithm actually sees. Most are fixed by replacing old markup with responsive CSS and auditing touch targets and font sizes.
What this means
This audit's mobile_unfriendly_element check specifically looks for three legacy patterns in your crawled HTML: table-based layouts (a <table> with an explicit width over 600px, or tables nested inside other tables), <frame>/<frameset> elements, and Flash content (<object> or <embed> tags pointing at a .swf file or a Flash MIME type). Each one it finds on a page raises a separate warning, so a single page with several offending tags can generate several warnings.
These three are worth flagging because they're mobile-rendering dead ends. Fixed-width tables force horizontal scrolling on any screen narrower than the table. Frames were never designed with small viewports in mind and are unsupported or barely supported in modern mobile browsers. Flash hasn't run in any mainstream browser, mobile or desktop, since Adobe ended support in December 2020, so Flash content is simply invisible on every device, not just phones.
Beyond what this specific check detects, "mobile-unfriendly" is a broader category Google's mobile-first indexing cares about: tap targets smaller than roughly 44-48px or packed too close together, body text under about 16px that forces pinch-zooming to read, and any element given a fixed pixel width instead of a responsive one, which causes the same horizontal-scroll problem as an oversized table even without one on the page. This guide covers all of it, both what triggers the flag and the wider set of patterns that hurt mobile usability even when this specific check doesn't catch them.
Severity here is a warning, not critical, but don't read that as "safe to ignore." Most searches now happen on mobile devices, and Google indexes and ranks based on the mobile rendering of your page. An element that breaks that rendering is broken in the version of your site that actually counts.
Why it matters
Google has run mobile-first indexing across essentially its entire index for years now: it crawls and evaluates the mobile version of your page as the primary version, not a secondary one. A layout that overflows, a tap target that's unusable, or a Flash element that renders as nothing isn't a minor inconvenience on a subset of traffic. It's a flaw in the copy of your page Google actually uses to rank you.
The user-experience cost compounds the ranking cost. A visitor who hits horizontal scroll, has to zoom in to read body text, or mis-taps a cramped button is a visitor who leaves. That shows up as higher bounce rates and shorter sessions, both of which are exactly the kind of engagement pattern that correlates with weaker rankings over time, even though Google doesn't use a named "bounce rate" ranking factor.
There's a narrower but real angle for how AI systems read your site too. Google's mobile-first crawler and most AI crawlers fetch the same rendered HTML a phone would get. A page that depends on a <frame> to load its actual content, or buries content in a Flash object that never renders, can leave an AI crawler with a blank or partial page to summarize, the same way it leaves a mobile visitor with nothing to read.
One honest note: fixing tap-target size and font size requires judgment, not just a pass/fail check. This audit's automated flag reliably catches the clearest legacy offenders (tables, frames, Flash). Verifying tap targets and text legibility is better done with Chrome DevTools' device mode or Google's Mobile-Friendly Test alongside this audit, not from this check alone.
How to fix it
- 1
Find and replace table-based and nested-table layouts
Search your templates for
<table>tags used for page layout rather than tabular data (a giveaway is a table wrapping your whole page, or tables nested inside other tables). Rebuild the layout with CSS Grid or Flexbox, which reflow naturally at any width. Keep real<table>markup only for actual tabular data, like a pricing comparison or a data set, and make sure those are wrapped in a horizontally scrollable container on narrow screens rather than left to overflow. - 2
Remove frames, framesets, and any remaining Flash
Replace
<frame>/<frameset>structures with a normal single-document layout using includes or a shared component at the template level; frames fragment navigation, break bookmarking, and render inconsistently on mobile browsers. Any<object>or<embed>referencing a.swffile is dead weight since Flash hasn't run anywhere since 2020; replace video with an HTML5<video>tag, replace animation with CSS or a lightweight JS library, and delete anything that was Flash-only functionality nobody has been able to see for years. - 3
Audit tap target size and spacing
Buttons, links, and form controls should be at least about 44-48px in their smallest dimension, with enough space around them that a thumb can't easily hit the wrong one. Open Chrome DevTools, switch to device mode (Ctrl/Cmd+Shift+M) at a 375-390px width, and check your navigation, buttons, and inline links. Icon-only buttons and closely packed link lists in footers are the most common offenders.
- 4
Fix undersized text and fixed pixel widths
Set a base body font size of at least 16px so mobile browsers don't need to auto-zoom to make it legible, and check that headings and captions aren't set smaller. Search your CSS for fixed-pixel
widthdeclarations on containers, images, and wrappers, and convert them tomax-width: 100%, percentages, or flexible units so nothing forces a viewport wider than the screen. This is the same underlying problem as an oversized table, just written in CSS instead of an HTML attribute. - 5
Test on a real device and re-audit
Run the page through Google's Mobile-Friendly Test and, ideally, load it on an actual phone. Check for horizontal scrollbars, zoom in to confirm text is readable without pinching, and tap through your primary buttons and links with a thumb, not a mouse cursor. Once clean, re-run this audit; the flagged tables, frames, and Flash elements should no longer appear, though tap-target and font-size issues are worth re-checking with the Mobile-Friendly Test since this audit's automated check doesn't score those directly.
Example
<!-- Before: table-based layout, breaks on mobile -->
<table width="960">
<tr>
<td width="200">Sidebar</td>
<td>Main content</td>
</tr>
</table>
<!-- After: CSS Grid, reflows at any width -->
<div class="layout">
<aside>Sidebar</aside>
<main>Main content</main>
</div>
<style>
.layout {
display: grid;
grid-template-columns: 200px 1fr;
gap: 1rem;
}
@media (max-width: 600px) {
.layout { grid-template-columns: 1fr; }
}
</style>Replacing a fixed-width table layout with CSS Grid and a mobile breakpoint. The same fix applies to any fixed-pixel container width.
Platform-specific steps
Legacy themes and some page-builder exports (older Elementor or Divi pages, or hand-coded themes from the 2010s) are the most common source of table-based layouts. Check the theme's template files for <table> tags used outside of actual content, and confirm the theme's viewport meta tag and CSS media queries haven't been overridden by custom code in the Additional CSS panel.
Both platforms generate responsive layouts by default in current editors, so unfriendly elements usually come from embedded third-party widgets (an old iframe-based tool, an embedded Flash-based badge) added via an HTML or embed block. Review any custom-code or embed elements on the page; the platform's native sections are rarely the culprit.
Table-based product-comparison sections and old third-party apps are the typical source. Check any app-injected code in theme.liquid or app blocks, and review custom sections built before the Online Store 2.0 update, which are more likely to use fixed-width markup than current template-based sections.
Frequently asked
Three specific patterns in your HTML: a <table> with an explicit width over 600px or a table nested inside another table, any <frame> or <frameset> element, and Flash content served through <object> or <embed> tags. Each occurrence generates its own warning, so one page with multiple offending tags can produce several warnings in your audit.
This automated check only catches the three legacy patterns above. It doesn't score tap-target size, font legibility, or fixed-pixel layouts directly, even though those are just as damaging to the mobile experience and just as relevant to Google's mobile-first indexing. Pair this audit with Google's Mobile-Friendly Test or Chrome DevTools' device mode to catch those.
Yes, indirectly but meaningfully. Google indexes and ranks based on the mobile version of your page, so a layout that breaks on mobile, whether from an old table layout, a fixed-width container, or oversized tap targets, is broken in the version Google actually evaluates. It's marked as a warning rather than critical because a few instances rarely tank a whole site, but the impact compounds as it spreads across pages.
If it's still on your site, yes, and it's arguably the most severe item in this check. Adobe ended Flash support in December 2020, and no current browser, mobile or desktop, will run it. Any content still delivered through a Flash <object> or <embed> is invisible to every visitor and every crawler, not degraded, just gone. Treat this one with more urgency than the warning label suggests.
Does your site have this issue?
Run a free, AI-powered audit and we’ll flag this and 150+ other checks in about a minute. No signup.