New format
Making a site work across screen sizes: why and how
Most visits come from smartphones: people browse the catalog on a phone and often send a lead from there too. A site that floats or needs horizontal scrolling loses both users and quality signals for search.
Below: what screen-size fit means, how responsive differs from a separate m-site, goals for business and SEO, the process, and checks. Layout as a craft is a related article; here the focus is mobile UX.
What making the site work on mobile means
Screen-size fit means the layout and UI stay readable and usable on phone, tablet, and desktop. Usually that’s responsive: one URL, CSS media queries or a modern grid, flexible images.
The goal isn’t “fit everything tiny” — it’s to keep the journey: find a service or product → understand the offer → call or send a request without fighting the menu and form.
Signs of solid responsive design:
- no pointless horizontal scrolling
- text readable without zoom
- buttons and links easy to tap
- menus and filters open predictably
- same content meaning as on desktop
Why it matters for business and SEO
Commerce: part of the purchase path starts on mobile. If the product page or form is awkward, the lead goes to a competitor with decent UX.
Search has long judged mobile experience (mobile-first). A slow or broken mobile page hurts crawl and behavior more than “one more keyword in H1.”
Goals of responsive design:
- don’t lose phone traffic
- keep conversion on a small screen
- simplify maintaining one template
- meet mobile-first indexing expectations
Responsive or a separate mobile version
Responsive site: one address; content and SEO signals don’t multiply. A separate mobile version (often `m.`) means a second template and drift risk — different copy, forgotten noindex, redirect chains.
A separate m. rarely makes sense (heavy legacy, special apps). For a new project and most CMS setups, use responsive plus lighter blocks if needed — not a second site.
Responsive:
- one canonical URL
- simpler analytics and goals
- fewer duplicates
- one content-edit loop
Separate m.:
- needs merging and careful redirects
- easy content drift
- double template maintenance
- higher risk of technical SEO mistakes
How teams build responsive in practice
Start with priority templates: home, key landings, catalog, product, cart/form, blog. Set breakpoints, rebuild grid, type, spacing, nav (a burger isn’t a dump of the whole desktop menu).
Images — srcset/sizes, compression, don’t load desktop 4K on 360px. Tables and wide blocks — container scroll or a simplified view without breaking the whole layout.
Typical process:
- viewport and base grid
- mobile menu and header
- content blocks and CTAs
- forms and clickable phone
- media and fonts
- desktop regression after edits
Benefits of solid responsive design
One site is easier for marketing and engineering. Ads and SEO point to the same URLs. Users don’t jump between a “full” and a “lite” version with different pricing.
For the team, fewer surprises: edit the offer once, check two or three widths — not sync two CMS instances.
What you gain:
- conversion from mobile traffic
- predictable indexing of one canonical
- lower maintenance cost
- better Core Web Vitals when weight is optimized
How to test across screens
Don’t stop at one iPhone in the emulator. Check mid-range Android widths, landscape, real networks (3G/LTE). Test phone taps, input masks, sticky CTAs, and whether chat covers the send button.
Automation: Lighthouse mobile, a crawler with a mobile user-agent if needed, screenshot review of key URLs after release. After a CMS theme change — full template pass again.
Acceptance checklist:
- home / category / product / form
- menu and search
- no clipped text or overlaps
- acceptable mobile speed
- legal links and consents tappable
- retargeting/chat don’t break UX
FAQ
Are responsive design and a mobile version the same?
Not always. Responsive means one URL and markup that adjusts to width. A “mobile version” often means a separate subdomain or template (m.) — less often the default strategy today.
Is a viewport meta tag required?
Yes for normal phone scaling: meta viewport in `<head>`. Without it the page often renders as a tiny desktop thumbnail.
Does responsive design affect SEO?
Yes — indirectly and strongly: usability, speed, bounce, mobile-first indexing. A broken mobile view risks visibility and conversion.
Is shrinking the desktop layout in CSS enough?
No. You need content priority, large tap targets, readable type, usable forms, and sometimes a different block order.
Do I need AMP?
Not required for most commercial sites. First get responsive and speed right; AMP is a separate choice for narrow cases.
How do I check responsive design quickly?
DevTools device mode plus real phones, PageSpeed/Lighthouse mobile, and a pass over key templates (home, category, product, form).
Do people still build a separate m.site?
Sometimes in legacy setups. Downsides: duplicate URLs, redirects, content drift. Prefer responsive on one canonical.
Does responsive design mean a fast site?
Not automatically. Heavy images and scripts kill mobile UX even with a clean grid. Compress media and cut excess.
Desktop looks fine — and the phone form needs horizontal scroll?
We’ll fix viewport, tap targets, and key templates — one responsive URL, not a second m.site.
Discuss the task
