Mobile first indexing: make WordPress work on phones

Mobile first indexing starts with your customer

Phones account for more than half of web traffic worldwide in StatCounter's platform data. Your own audience may differ, so check your analytics before deciding which devices deserve extra attention.

Imagine a prospective customer opening your service page from Google while away from their desk. If the phone number is plain text, the menu stays closed or a banner hides the form, they have to solve your website before they can hire you.

• Read the offer

  Make the service, location and next action clear on a narrow screen. Keep useful details available without forcing visitors to enlarge the page.

• Reach a person

  Provide a working tap-to-call link and a usable form. Test the actual contact route instead of assuming a visible button works.

• Keep content visible

  Review the mobile page as carefully as the desktop version. A service explanation removed from the mobile layout no longer helps someone reading on a phone.

Begin with the pages that bring inquiries: key services, contact, booking and any paid landing pages. Our WordPress web design guide connects this work with the wider site plan, while conversion optimization covers the reasons people take the next step.

Mobile first indexing: keep the full useful page

Google Search Central explains that Google uses mobile content for indexing and ranking and recommends responsive design. Keep equivalent main content, headings, metadata and structured data on mobile; avoid requiring a tap to load primary content.

A WordPress mobile friendly theme is a starting point

Responsive design lets one page adapt to different widths. A theme may support it while an added pricing table, embedded booking tool or page-builder section still creates a problem, so review the finished pages with their real content.

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

The viewport tells a mobile browser how to size the page, as explained in web.dev's responsive design basics. Without it, a phone can display a shrunken desktop layout even when parts of the styling are responsive.

For discovery and indexing checks beyond the screen layout, see our WordPress sitemap guide. Treat mobile usability and indexing as connected checks with their own evidence.

Make your WordPress site mobile friendly

Start with the element causing the failure: a fixed-width column, an oversized image, a long heading or a table. Hiding all horizontal overflow can conceal content and focus outlines, so repair the source before applying a page-wide workaround.

.service-title {
  min-width: 0;
  overflow-wrap: anywhere;
  word-break: normal;
}

Our QA rule at 390 px is no page-wide horizontal overflow, centered grids and complete text. We also inspect 360 and 414 px, then 768 and 1024 px, because a layout can fail between a builder's preset previews.

A mobile menu must work after the first tap

A hamburger icon is useful only when the menu opens, its links are reachable and the visitor can close it. Check it after scrolling, with the cookie notice visible and with the phone turned sideways, because competing fixed elements often expose problems.

These screenshots come from fer.marketing, which is built with Next.js. They illustrate the same principles we apply on WordPress: sensible stacking, space for real wording and navigation that deserves its own test.

Make calling and mobile forms easy

Our October 2026 study of 300 law firm websites found simple mobile foundations missing. These are checks of website HTML, not estimates of missed calls or a claim about every industry.

Make the published business phone number a tel: link and confirm it opens the phone's calling interface. For forms, keep a visible label on every field, ask only for necessary details and choose keyboard types that match the information requested.

<label for="phone">Phone number</label>
<input id="phone" name="phone"
  type="tel" autocomplete="tel">

Submit with the on-screen keyboard open and deliberately leave a required field blank. Errors should explain the repair, preserve what the visitor typed and remain visible; then complete a valid test and confirm it arrives in the staff inbox.

WordPress accessibility: six useful foundations

Accessibility helps people who use keyboards, screen readers, magnification or captions. Use WCAG 2.2 as the technical reference: normal text generally needs 4.5:1 contrast, and large text 3:1, with defined exceptions.

• Contrast

  Check text against its actual background, including buttons and error messages. Do not use color alone to explain an error.

• Image alternatives

  Describe meaningful images for their purpose. Decorative images need an empty alternative so screen readers can skip them.

• Field labels

  Associate each field with a clear label. Placeholder text disappears as the visitor types and cannot replace that label.

• Keyboard and focus

  Make actions work without a mouse. Keep the current focus visible and reachable, including inside menus and dialogs.

• Headings

  Use headings to organize the page, with a sensible hierarchy. Choose them for meaning rather than their default font size.

• Captions

  Provide accurate captions for prerecorded videos with speech. Check names and service terms rather than trusting automatic output.

Test the whole task with assistive technology

Our review includes following a service page through to a completed inquiry with a keyboard and a screen reader. We look for practical barriers such as an unnamed menu button, confusing field instructions or a confirmation that is never announced.

What is ADA website compliance?

ADA website compliance concerns access for people with disabilities under the Americans with Disabilities Act. ADA.gov's web guidance explains accessibility duties for covered organizations; the applicable requirements depend on your organization and circumstances.

This guide is not legal advice. When evaluating ADA compliance website services, ask for a defined technical standard, manual testing, a repair list and evidence of retesting; bring questions about legal obligations to qualified counsel.

An overlay widget alone does not establish compliance. W3C WAI explains the limits of automated evaluation: some checks require human judgment, so an automated result cannot prove full accessibility.

Test a website for mobile friendly behavior

Use browser previews to find layout problems, then use real phones to verify interaction. A screenshot cannot reveal a menu that will not open or a keyboard that covers the only way to submit.

1. Step 1

   Choose representative pages and tasks

   Include the homepage, service template, contact form and any booking or checkout flow. Add the longest headings, widest tables and both languages so the review covers difficult content.

2. Step 2

   Inspect five widths and the gaps between

   Review 360, 390, 414, 768 and 1024 CSS pixels, dragging between them. Record horizontal overflow, cut-off text, uneven grids and anything covering the main action.

3. Step 3

   Run the tasks on real devices

   Use iPhone Safari and Android Chrome, with portrait and landscape checks. Open and close the menu, follow the call link, fill out forms and test with the on-screen keyboard visible.

4. Step 4

   Check access and loading separately

   Run automated checks, then test zoom, keyboard, focus and a screen reader journey. Try cellular loading as well as Wi-Fi, and save PageSpeed mobile and desktop results with their dates.

5. Step 5

   Repair on staging and retest

   Work on a protected copy, beginning with blocked calls, menus and submissions. Repeat the failing action after each repair and check shared templates so one fix does not damage another page.

6. Step 6

   Verify live and hand over the record

   After deployment and relevant cache clearing, repeat the main tasks on the public site. Record page, device, browser, width, result and outstanding issues, with an owner for each follow-up.

Theme, builder and plugin changes can affect these results later. Add the critical journeys to your WordPress maintenance checklist, and review page-builder choices when the same layout problems keep returning.

Our mobile scores, with the context included

These PageSpeed Insights captures are Lighthouse lab results for fer.marketing from October 17, 2026. Our own site is built with Next.js; the reports show our pages, while the same testing principles guide our WordPress work.

Caption order is Performance / Accessibility / Best Practices / SEO. Accessibility scored 100 on our homepage, guide and service page on both devices; the law study scored 99 on mobile and 98 on desktop, so the result is page-specific.

The reports showed No Data for field results because traffic was still low, and Agentic Browsing 3/3. Neither that result nor an accessibility score certifies a usable menu, successful form delivery or legal compliance; our WordPress speed guide explains the loading work in more detail.