Preparing for Google's mobile-first index: parity, speed, data

Today, Googlebot crawls your desktop pages, builds its index from them, and then adjusts rankings for mobile searchers with signals such as the mobile-friendly label introduced in April 2015. The content being judged is the desktop content.

Under mobile-first indexing, the smartphone Googlebot becomes the primary crawler. The mobile page is the page that gets indexed, its text is what gets matched against queries, its links are what pass authority, and its markup is what feeds rich results. The desktop page becomes the secondary version. Google has said there will still be one index, not two, and that a site with no mobile version will continue to be indexed from desktop. But it will be judged against competitors whose mobile pages are complete.

Mobile already accounts for more than half of US searches, and typical business sites now see 45 to 65 percent of visits from phones and tablets. Google is aligning its index with what most of its users actually see.

How much work you face depends on how your site handles mobile today.

Responsive sites serve identical content to every device, so parity is built in. Check speed and that nothing important is hidden behind CSS that strips it on small screens, but the index switch should be a non-event.

Dynamic serving sites deliver different HTML to phones at the same URL. These need a content audit, because the mobile template was often built lighter. Confirm the Vary: User-Agent header is in place so Google knows to crawl both.

Separate mobile sites on m.yourdomain.com are the real exposure. Many were built in 2011 or 2012 as cut-down versions: shorter product descriptions, no reviews, fewer internal links, no schema markup. Under mobile-first indexing, the cut-down version becomes the only version that counts.

Work through this for each major template: home, category, product or service page, article, location page, contact.

1. Body copy. Is the full text present on mobile, even if collapsed into accordions or "read more" sections? Google has said content in expandable sections is fine on mobile, because that is a reasonable mobile design pattern. Content that is absent is not.
2. Headings and titles. Same title tag, same meta description, same H1 on both versions.
3. Images and alt text. Mobile templates often swap in smaller images with no alt attributes. Restore them.
4. Internal links. Navigation menus, footer links, related products, breadcrumbs. If desktop has 80 internal links on a page and mobile has 12, your crawl paths and link equity change dramatically.
5. Structured data. Product, Review, LocalBusiness, Article, BreadcrumbList and Organization markup must be present on the mobile page. Use JSON-LD, which Google now recommends, so the markup does not depend on the visible HTML layout.
6. Hreflang and canonical tags. For separate mobile URLs, keep the existing rel=canonical from mobile to desktop and rel=alternate from desktop to mobile. Google has said not to change these.
7. Robots access. Make sure smartphone Googlebot can fetch your CSS, JavaScript and images. Use Fetch and Render in Search Console with the mobile user agent and compare the render to what a real phone shows.
8. Search Console verification. If you run an m-dot site, verify it as its own property so you can see crawl errors and mobile usability issues specific to it.

Google's own research published last year found that 53 percent of mobile visits are abandoned when a page takes longer than three seconds to load, and that the average mobile landing page takes 22 seconds. Google has not announced a mobile speed ranking factor beyond the existing desktop one, but its engineers have said repeatedly that mobile speed matters more as the index shifts. Treat it as a requirement.

Realistic targets for a business site on a mid-range Android phone over a 3G connection:

• First meaningful content visible in under 3 seconds
• Full page interactive in under 5 seconds
• Total page weight under 1.5 MB, ideally under 1 MB

The usual culprits, in order of impact:

• Unoptimized images. Often 60 to 80 percent of page weight. Resize to display dimensions, compress, and serve different sizes with srcset.
• Render-blocking JavaScript and CSS. Tag managers loaded synchronously, three sliders, two chat widgets. Defer what is not needed for the first paint.
• Too many third-party scripts. Each ad, analytics, heatmap and social tool adds requests. Audit quarterly and remove what nobody looks at.
• No caching or compression. Gzip and browser caching are a one-hour server fix that is still missing on a surprising share of sites.
• Slow hosting. Shared hosting with a 1.5-second server response time cannot be fixed with front-end work.

Test with PageSpeed Insights, the Mobile-Friendly Test and WebPageTest set to a Moto G over 3G. The Chrome developer tools' audit panel, based on Lighthouse, is also useful and improving quickly.

AMP is worth considering if you publish news or articles and want the Top Stories carousel. For most business and ecommerce sites, a fast responsive page is the simpler path and does not create a second template to keep in sync.

Two existing rules are easy to trip and will matter more once mobile is primary.

Intrusive interstitials. Since January 10 of this year, pages that show a popup covering the main content immediately after a user arrives from search can rank lower. Email capture overlays, app install banners that fill the screen and "sign up for 10 percent off" modals all count. Legally required notices such as age verification and cookie consent, and banners that use a reasonable amount of screen space, are exempt. Move your email capture to a slide-in or a timed banner rather than a full-screen takeover.

Mobile usability errors. The Mobile Usability report in Search Console flags text too small to read, clickable elements too close together, content wider than the screen and viewport not set. Clear every one of these before the switch.

• If you have a responsive site: audit speed and structured data, fix interstitials, and move on.
• If you have dynamic serving: audit parity template by template and close the gaps in the mobile HTML.
• If you have an m-dot site and a redesign is planned within 18 months: bring it forward and go responsive. Do not spend money upgrading the m-dot site.
• If you have an m-dot site and no redesign budget: achieve parity on your 20 most valuable templates and pages first, and keep the canonical and alternate tags exactly as they are.
• If you have no mobile version at all: you will continue to be indexed from desktop, but you are already losing to mobile-friendly competitors and should treat a responsive build as this year's priority web project.

Reacting by stripping the desktop site down to match mobile rather than building mobile up. Blocking smartphone Googlebot with a robots rule that was meant for an old scraper. Keeping structured data in the desktop template only because that is where it was added in 2014. Testing on your own new iPhone over office Wi-Fi and concluding the site is fast. Changing canonical tags between mobile and desktop URLs on a hunch, which can deindex pages.

Discover: we crawl your site with both desktop and smartphone user agents, diff the content, links and markup template by template, pull device-level data from analytics and Search Console, and measure speed on real mid-range hardware. Plan: we agree which configuration you will run going forward, prioritize the templates by revenue and traffic, set a performance budget per template and decide what structured data each page type needs. Build: our website design and development team closes parity gaps or builds the responsive templates, UX and conversion design makes sure the mobile versions convert rather than merely exist, and our technology team handles hosting, caching, image pipelines and third-party script governance. Improve: after launch we watch mobile rankings, crawl stats and conversion by device and iterate. Because brand, growth, web and technology work as one team, the pages we make index-ready are the same pages your paid search and social campaigns land on, so the speed work pays twice.

The Real Estate Platform engagement is the representative pattern. Property search is a task people do standing on a sidewalk with a phone, and the platform's older mobile experience served a reduced subset of listing details and almost none of the markup the desktop pages carried. The rebuild moved to a single responsive codebase with listing, search and neighborhood templates designed for small screens first, structured data generated once from the listing database rather than hand-coded per template, and an image pipeline that served appropriately sized photos to each device. Device-level reporting was in place from day one so the team could see mobile organic visibility and inquiries move together.