What a mobile friendly website actually needs, and how Anticode checks it
A mobile friendly website is one a person can read and use on a phone without zooming, pinching or mis-tapping. That comes down to a few testable things: a viewport tag, text that reflows at narrow widths, tap targets big enough for a thumb, and forms that bring up the right keyboard. Anticode's design gate refuses to publish a page without a phone viewport, and every published site can be installed on a phone.
The checks behind "mobile-friendly"
| Check | What it means | How it fails |
|---|---|---|
| Viewport tag | The page tells the phone to use its real width | Without it, the phone shows a shrunken desktop page |
| Reflow | Content fits a narrow screen without sideways scrolling | Fixed-width tables, wide images and long unbroken words push the page sideways |
| Tap targets | Buttons and links are big enough and far enough apart | Footer links packed together; tiny icon buttons |
| Readable text | Body text is large enough to read at arm's length | Small grey text on a busy background |
| Forms | Fields use the right input types and labels | A phone field that opens the letter keyboard; placeholder text instead of labels |
| Speed | The first screen appears quickly on a weak connection | Heavy scripts, autoplay video, oversized images |
Two of these have published standards. The W3C's accessibility guidelines ask for content to reflow at a width of 320 CSS pixels without scrolling in two directions, and for interactive targets of at least 24 by 24 CSS pixels or enough space around smaller ones. Bigger is kinder: many designers aim for around 44 pixels for main buttons.
Phone first changes the content, not just the layout
A phone first website is designed for the smallest screen and then given more room, rather than designed for a laptop and squeezed. The practical effect is on content order. On a phone only one thing is visible at a time, so the first screen needs the answer to why the visitor came: what you do, where, and how to get in touch or buy. Navigation with nine items becomes a menu nobody opens; five is plenty.
- Put the phone number and address as text, not only in an image, so they can be tapped and copied.
- Keep forms short. Every field is a thumb's worth of effort.
- Avoid hover-only effects; there's no hover on a touch screen.
- Test with your thumb, one-handed, on a real phone, not just a narrow browser window. The testing on mobile guide has a short routine.
How Anticode handles it
As a mobile website builder, Anticode treats a phone viewport as a publishing requirement. Since 23 October 2026 its design gate blocks publishing a page that misses basics, and a phone viewport is one of them, alongside a page language, visible keyboard focus, reduced-motion support and alt text on images. The Critic's design checks also cover body text size and hero height, two things that often go wrong on small screens.
Pages from the design engine carry no scripts at all, which helps speed on a slow mobile connection. For app builds such as calculators and games, a self-review step opens a new build in a headless browser at phone and laptop widths, when that service is available, takes screenshots and clicks through, and fixes what breaks.
To adjust how sections sit, use the layout editor: drag an element within its section, or drag its edge to resize, and resizes snap to columns. Check the result at phone width after any change, because a layout that's tidy on a laptop can stack awkwardly.
Installable on the home screen
Every published Anticode site has a web app manifest and icons, so visitors can install it on a phone or desktop and open it like an app, with an offline fallback page when there's no signal. For a restaurant, a club or an event site that people return to, that's often enough to skip building a separate app. If you do need a store listing, see website to app store.
Limits
- The gate checks the basics, not everything. It confirms a phone viewport exists; it can't judge whether your content order makes sense on a phone. Look yourself.
- No separate mobile site. One responsive site serves every screen; there's no m-dot version or different content per device.
- Screenshot review is for app builds. The headless-browser pass covers new apps when the service is available; pages from the design engine aren't screenshotted that way, so open them on your own phone.
- Offline means a fallback page, not the full site working without a connection.
Questions people ask
Do I need a separate mobile version of my site?
No. A single responsive site that reflows to any width is the usual approach and is what Anticode builds.
Does Google care whether my site works on phones?
Google indexes the mobile version of pages, so content that's hidden or broken on a phone is a problem for search as well as for visitors.
Can I make my site open full screen like an app?
Visitors can install any published Anticode site from their browser, and it then opens from the home screen with its own icon.