How to Make a Website Mobile Friendly: 7 Fixes

Your visitors’ devices and tasks matter more than a global traffic percentage. Google uses the mobile version of content for indexing and ranking, so make important information available there. Start with a quick HTML inspection, then check the rendered page and its interactions.

What is a mobile friendly website?

A mobile friendly website lets people read, navigate and complete tasks comfortably on a phone. Content fits the available width, text and controls remain usable when enlarged, and loading and interaction delays are reasonable. Responsive design, where the layout adapts to the available viewport, is a common way to achieve that result. Keep zoom available even when the default text is comfortable.

A missing viewport meta tag is one common problem. web.dev explains that mobile browsers can otherwise lay a page out at a wider desktop-like viewport, often around 980 CSS px, then shrink it. The tag enables appropriate viewport sizing; responsive CSS must still make the content fit.

Does mobile friendliness affect SEO?

Google announced completion of mobile-first indexing in October 2023. Its June 2024 update said the remaining sites would move to Googlebot Smartphone after 5 July 2024. Content inaccessible to mobile cannot be indexed under that approach. Desktop Googlebot can still appear for some other Search features, so not every crawl request is a phone crawl.

Google’s current mobile-first guidance calls for equivalent main content, structured data, metadata and meaningful image descriptions. Accordions and tabs can save room, provided the content is available to the crawler; do not load primary content only after a tap. Reorganize important information rather than removing it from mobile.

Check your own device mix and completion rates. In Grigora you can add Google Analytics to understand your visitors. Even a smaller group of mobile customers needs a usable route through the site.

Google uses Core Web Vitals in ranking systems, but a good tool score does not guarantee a high position. Mobile-first indexing describes which content is used, not a standalone reward for adding a viewport tag. Fix problems because people need to read and complete tasks; assess performance and useful content together.

Is my website mobile friendly? Start with a short test

Google retired its Mobile-Friendly Test and Mobile Usability report from December 2023 and pointed site owners to other tools, including Lighthouse. Use this short first pass on the home page and an important journey such as booking, contact or checkout. Allow more time for a full review and for tools to finish.

1. Inspect the basics. The free Mobile-Friendly Test Lite reads HTML for viewport declarations and inline warning signs. It does not render the page or provide a mobile-friendliness score. External CSS, actual overflow, spacing and usable controls need browser checks.
2. Inspect layout at several widths. The Mobile Preview Simulator frames your page at selectable dimensions in your desktop browser. It does not run iOS Safari or Android hardware and cannot reliably expose a missing mobile viewport tag. If framing is blocked, open the page directly in browser device mode or a real phone. A mobile screenshot is a static layout check, not an interaction test.
3. Measure loading and responsiveness. Use PageSpeed Insights on Mobile. Its navigation lab test produces Lighthouse diagnostics, while field data covers the previous 28 days when sufficient CrUX samples exist. Check whether field results are for this URL or the whole origin. The default navigation lab run does not measure INP; TBT helps diagnose potential responsiveness problems but is a different metric.
4. Complete tasks on real phones. Desktop emulation approximates dimensions and conditions, not the phone’s processor or every browser behavior. Test available iOS Safari and Android Chrome devices, a realistic connection, both orientations, menu, keyboard, form errors and confirmation. Use a controlled test flow for checkout so a QA exercise does not create an unintended purchase.

A small test worksheet: record the URL, date, device/browser, viewport or zoom setting, task, result and screenshot or issue link. Start with the checks below; a passing row covers that condition only.

Google Mobile-Friendly Test alternatives: what to use now

After launch, compare your task results, field performance and Search Console trends. The Core Web Vitals report needs sufficient data and groups similar URLs; it is not a complete list of every page. Grigora can provide a Search Console verification setting, but view the actual clicks, queries and Core Web Vitals in Search Console. A separate on-page checkup is not a substitute for those reports.

Why is my website not mobile friendly? 12 common problems and fixes

Find your symptom, then read across; the seven fixes below explain each.

How to make your website mobile friendly: 7 fixes in priority order

Your builder may already handle some of these, so tick those off.

1. Check the viewport tag and make the layout fit

The viewport meta tag tells phones to draw the page at screen width, not desktop width. Builders such as Grigora add it for you. In hand-written HTML, it is one line in the head of every page:

<meta name="viewport" content="width=device-width, initial-scale=1">

Inspect what the viewport tag declares, not just whether it exists. The Meta Viewport Checker can flag duplicate or restrictive declarations in fetched HTML. Confirm the final behavior in a browser.

Keep enlargement available. Avoid maximum-scale=1 and user-scalable=no. Browser handling varies, but relying on a browser override is a weak design. WCAG’s Resize Text criterion requires text enlargement to 200% without loss of content or functionality, with stated exceptions. Test zoom and text resizing rather than inferring compliance from one tag.

Then make the layout reflow. WCAG Reflow at AA expects vertically scrolling content to work at an equivalent width of 320 CSS px without loss of information or functionality or two-dimensional scrolling. Necessary two-dimensional content, such as maps and data tables, has exceptions; text inside table cells still needs to reflow. Stack columns, constrain images and put necessary wide tables in a usable local scroller rather than hiding the page’s overflow.

2. Make text readable without zooming

Start around 16 CSS px for body text and form fields, then inspect the actual font, line height and content. That is a practical baseline, not a universal WCAG minimum. Keep headings and long words from clipping. Lighthouse removed its old font-size audit in version 13, so a clean report does not establish legibility.

Use headings, short paragraphs and clear wording. A Readability Score Checker can flag sentence complexity using a formula; it does not test rendered font size, contrast or reader comprehension. For heavy copy, review the wording as well as the layout.

Check WCAG contrast: normally at least 4.5:1 for text, or 3:1 for qualifying large text, with exceptions. The Contrast Checker compares extracted colors from a screenshot. Choose the actual foreground and adjacent background; a dominant-color pair alone does not audit all text or changing backgrounds. Clear type also helps a professional presentation.

3. Make buttons easy to tap, and add click-to-call

Measure the clickable area in CSS pixels, not just the visible icon. Web standards and native-platform guidance use different units:

• 24 × 24 CSS px: WCAG 2.2 AA Target Size (Minimum) includes exceptions for spacing, equivalent controls, inline text, unmodified browser controls and essential presentation. The spacing exception uses non-overlapping 24 CSS px circles around undersized targets; it is not a blanket eight-pixel-gap rule.
• 44 × 44 CSS px: WCAG’s enhanced AAA target size, also with exceptions. This is a useful stronger target for important web controls.
• A practical web baseline: try important buttons around 44–48 CSS px in each dimension, with enough space to avoid neighboring hits. Native iOS points and Android dp are not interchangeable with web CSS px; do not combine them into a single compliance ruler.

Larger controls and spacing usually help, but a size rule does not replace a task test. Grigora’s Accessibility Checker can identify automated accessibility findings for a selected viewport. Review each result and perform keyboard, zoom and touch checks: an automated scan cannot establish full WCAG conformance.

Add click-to-call. For a plumber, salon or restaurant, the call is often the sale. Link your number as tel:+15551234567, with the plus sign and country code, so phones dial it in one tap. See how to add a big, tappable button in Grigora, and a button text generator suggests short labels of two to five words.

4. Shrink images and speed up the page

Measure Core Web Vitals for your audience rather than assuming a global pass rate describes your site. The good thresholds are LCP at most 2.5 seconds, INP at most 200 milliseconds and CLS at most 0.1. The assessment uses the 75th percentile for each metric, segmented by mobile and desktop; all three must meet their thresholds.

• LCP (Largest Contentful Paint): how fast the main content, often the hero image, appears. Good is 2.5 seconds or less.
• INP (Interaction to Next Paint): how quickly a tap gets a response. Good is 200 ms or less.
• CLS (Cumulative Layout Shift): how much things jump around unexpectedly. Good is 0.1 or less.

Use the report to identify the bottleneck. A slow hero, a blocking script and a shifting advertisement need different fixes:

• Inspect image delivery. Use browser network diagnostics for actual transferred bytes and loading order. The Broken Image Checker can flag resource issues, but its flags alone do not measure rendered mobile performance.
• Prepare suitable files. The Image Compressor exports JPEG, so preserve an original and check transparency before using the result. The WebP Converter offers another format. Choose a format and fallbacks for your supported browsers and actual content; no global support percentage makes that decision for every site.
• Prioritize the visible hero. Avoid lazy-loading an image needed in the initial viewport, especially the LCP image. Lazy-load appropriate offscreen images; do not eagerly prioritize every image.
• Reserve image space. Correct width and height attributes or an appropriate aspect ratio help avoid shifts. The Page Performance Checker Lite inspects fetched HTML and server-response information, not a rendered page or Core Web Vitals. Confirm real layout and loading in browser diagnostics.
• Remove unnecessary work. Review unused widgets, trackers, sliders and long JavaScript tasks. Retest the affected interaction instead of assuming a smaller script count guarantees a good INP.

5. Simplify navigation for thumbs

A menu icon saves space, but it can hide important routes. Nielsen Norman Group’s 2016 study involved 179 people and found navigation usage depended on presentation and site context. It does not establish a fixed percentage improvement for every menu. Use a clear menu label, visible priority links and task testing to decide what belongs in view.

For a small number of main destinations, visible links may be practical; a larger site may need a menu and search. Grigora’s guide covers navigation links. If you use a sticky header, keep it compact and check it does not cover content or keyboard focus.

6. Replace pop-ups with small banners

Google warns against intrusive overlays that obscure the content and suggests small banners where appropriate. Required notices can have different treatment, but still need an accessible, usable implementation. Do not redirect visitors away from the content merely to show a consent or promotion page.

7. Make forms easy to fill in on a phone

Every field is harder with a thumb, so ask only for what you need, then let the keyboard do the work:

• Use persistent labels and suitable email or telephone input types. MDN shows how input types can prompt suitable keyboards. Add appropriate autocomplete tokens and clear validation; a placeholder alone is not a label.
• Start form text around 16 CSS px and test it in the browsers you support. Some iPhone Safari configurations enlarge focused small-text fields; the trigger and restoration behavior are not universal. Do not block zoom to suppress the symptom. Check that the on-screen keyboard does not hide the field, errors or submit control.

If quotes win you work, as they do on a cleaning business website, fill in your own form on your phone, confirmation message included. Selling online? Place a test order on your phone too, on Grigora Commerce or any other store.

Make a classic Grigora template site mobile friendly, step by step

Classic Grigora template sites provide a viewport declaration and responsive styling controls. The standard image pipeline creates AVIF and smaller raster variants for supported uploads, but linked images and formats such as SVG or GIF follow different paths. The browser’s chosen resource depends on the available candidates and layout; do not assume every phone gets a smaller file.

Review each breakpoint rather than assuming the defaults fit your content. Responsive values can inherit from larger breakpoints, and some settings are shared. Regular image blocks can lazy-load by default, so check the hero separately. Use the editor’s device controls and compare Desktop, Tablet and Mobile after each meaningful change:

1. Select Mobile View. Use the control labelled Mobile View. Check the selected device before changing responsive settings. Content edits and non-responsive settings can still affect every view.
2. Stack columns when needed. Select the section and inspect Layout → Direction; choose Rows where that control stacks the layout. Compare all breakpoints afterward instead of assuming every change is phone-only.
3. Check typography. Explicitly inspect the mobile size and inherited tablet/desktop values. Under Site styles → Typography, review Heading 1, Heading 2 and Body for each device. Text styling guidance covers size and line-height controls.
4. Check buttons. Use padding and dimensions to create a comfortable activation area. Test the actual link, including a tel: URL for a call action.
5. Keep important content available. Hide decorative duplicates only when appropriate; reorganize primary content rather than removing the mobile version. Check equivalent meaning and access in the published page.
6. Check image loading and alternatives. Switch Lazy load off for an image needed in the first viewport. Choose Alt Text by purpose: informative images need an appropriate description; decorative images may need an empty alternative. See image and video settings.
7. Test menus and forms. Inspect phone and tablet navigation, open it, follow links and operate it with a keyboard. Choose appropriate field types where available; do not assume the builder offers every HTML option.
8. Publish and verify. Compare all device views, publish through the editor’s normal workflow, and inspect the live URL. Repeat the important tasks on real devices.

For more detail, see Grigora's guide to setting different font sizes, spacing and visibility for mobile, tablet and desktop.

Using Grigora's AI builder?

Grigora’s AI builder can create a responsive starting site from a description. Treat it as a draft: use mobile preview, request focused fixes with the available selection or annotation controls, and verify the published result. Test real text, long headings, forms and navigation rather than relying on the initial preview.

You can describe the site you want to build or choose a website template. Review the mobile layout before and after replacing the demo content.

Optional: how to make a website mobile friendly with HTML and CSS

Skip this if your builder handles the code for you. If you write your own HTML and CSS, these lines cover most fixes above:

• Images: img { max-width: 100%; height: auto; } prevents ordinary images from exceeding their container. Correct intrinsic width and height attributes reserve space; they do not compress a file.
• Responsive candidates: supply actual smaller files with srcset and an accurate sizes value. The browser considers the slot, density and other conditions. Inspect currentSrc and transferred bytes instead of assuming every phone downloads the smallest candidate.
• Loading order: use fetchpriority="high" selectively for the important LCP image when appropriate. Do not lazy-load images required in the initial viewport; use loading="lazy" for suitable offscreen images.
• Forms: use suitable type, autocomplete and inputmode values alongside real labels and readable text. Test the actual keyboard and error states.
• Breakpoints: start with the narrow layout and add space when the content needs it. For example, .columns { display: grid; gap: 1rem; } can become two columns at a suitable width with @media (min-width: 44rem) { .columns { grid-template-columns: repeat(2, minmax(0, 1fr)); } }. Check long content rather than treating 44rem as a universal device boundary.

On Grigora, the viewport tag is already on every page, so never add a second one through custom code in your site's head. Duplicate tags are exactly what the viewport checker flags.

Outdated mobile advice you can ignore

Many pages that rank for this topic still repeat advice that is now out of date:

• “Run Google’s Mobile-Friendly Test.” It was retired from December 2023. Use current diagnostics and real-device checks.
• “FID is a Core Web Vital.” The current set is LCP, INP and CLS.
• “A global mobile percentage tells you what to build.” Your audience’s devices and tasks are the relevant test coverage.
• “Small fonts and every tap issue will appear in Lighthouse.” Audit coverage varies by version, and automated checks are incomplete.
• “Google requires 48px targets for SEO.” Web accessibility criteria and practical target sizes are separate from a guaranteed ranking improvement.
• “A PageSpeed score of 100 proves the page is mobile friendly.” Google advises improving real experience rather than chasing a perfect score solely for SEO. A score does not test every menu, form, zoom state or supported device.

Old desktop-only site? Patch it, rebuild it or hire help

Whether it runs on WordPress, Wix, Squarespace, Canva or hand-written HTML, the checks are the same. Patch it if your editor or theme lets you change the phone layout, because most fixes are then settings, not code.

Consider a rebuild when the structure repeatedly defeats your users’ needs and incremental fixes are more expensive to maintain. A fixed-width layout alone does not always require starting over: CSS can often repair it. Compare the effort before deciding. See updating a website and planning a redesign; verify what your migration route actually imports before moving.

Hire help if you have time for neither: have Grigora's team build it for you, or compare Grigora plans and start from a trade page such as the bakery website builder.

Retest the same tasks after fixes so you can compare outcomes. Before launch, use the Website Launch Checklist and these website bug-finding tips to broaden coverage beyond the phone layout.

Mobile friendly website FAQs