Mobilegeddon: getting mobile-friendly before and after April 21

The announcement came on February 26 through the Webmaster Central blog, with an unusually clear date attached. Three facts matter more than the headlines calling it "Mobilegeddon."

It is a page-level signal. A site is not mobile-friendly or not. Each URL is evaluated on its own. Your home page can pass while a product page fails.

It affects smartphone searches only. Desktop and tablet rankings do not change. The size of the effect on you depends on how much of your search traffic comes from phones, which for most US businesses is now somewhere between 30 and 50 percent and climbing.

It is binary. There are no degrees of mobile-friendly. A page passes or it does not, and Google already labels passing pages with a gray "Mobile-friendly" tag in mobile results, which is itself a click-through advantage.

Google has also said the signal is significant. Combined with the real-time nature of the update, that makes this the first algorithm change in years with a clear calendar deadline attached.

Do not guess. Run three checks this week.

1. The Mobile-Friendly Test. Paste a URL and get a pass or fail with the specific reasons listed. Run it on your home page, your top ten landing pages from organic search, and one example of every template type you have.
2. Mobile Usability report in Webmaster Tools. This shows the issues Google found across the whole site during normal crawling, grouped by error type with affected URL counts. It is the fastest way to see scale.
3. Your own analytics. Pull organic search traffic by device for the last 90 days. Sort landing pages by mobile sessions. That is your priority list.

If Webmaster Tools shows zero mobile usability errors and your templates pass the test, you are done with this update. Spend the time on speed instead.

The criteria are public and short. Fix these and you pass.

Viewport is configured. A single meta viewport tag telling the browser to render at device width. Missing this is the most common cause of failure and the cheapest to fix.

Text is readable without zooming. A base font size of 16 pixels for body copy is the safe rule. Twelve-pixel footer text will flag the page.

Tap targets are sized and spaced. Links and buttons need to be large enough and far enough apart for a thumb. Roughly 48 pixels of touch area with 8 pixels of space between neighbors clears it. Dense navigation menus and link-heavy sidebars are the usual culprits.

Content fits the screen. No horizontal scrolling. Fixed-width tables, images with hard-coded widths, and embedded iframes all break this.

No Flash or other unsupported plugins. iPhones never played Flash and Android dropped it in 2012. If a page depends on it, the content does not exist on mobile as far as Google is concerned.

Everything else you have read about mobile SEO, including page speed, app indexing and structured data, is real work but is not part of this particular test.

There are three routes, and the right one depends on how your site is built and how much time you have.

Responsive design. One set of URLs, one HTML, CSS that adapts to screen width. This is Google's recommended configuration, it avoids redirects and duplicate content, and it is the default for any new build. If your site runs on WordPress or a similar CMS, switching to a responsive theme can take days rather than months.

Dynamic serving. Same URLs, different HTML served based on the user agent. Works well for large sites where the mobile experience needs to be genuinely different. Requires the Vary: User-Agent header and careful testing so Googlebot for smartphones sees the mobile version.

Separate mobile site. The m-dot approach. It still passes the test if done properly, with bidirectional annotations linking each desktop page to its mobile twin and redirects that go page to page, not home page to home page. It is the most fragile option and the one most likely to be done badly in a hurry.

A decision rule: if your site has fewer than a few hundred templates-worth of variation and a modern CMS, go responsive. If you are a large publisher or retailer with an existing m-dot site that works, fix its annotations and move on, then plan the responsive rebuild for later in the year.

Not everyone will make the date with the whole site. Prioritize.

1. Fix the viewport tag and base font size globally. These are template-level changes that clear two of the five criteria for every page at once.
2. Repair the templates behind your top 20 mobile landing pages. Product pages, service pages, location pages, whatever earns the traffic.
3. Replace or hide Flash elements. A static image or an HTML5 video player is enough for now.
4. Resize tap targets in navigation and footers. Usually a stylesheet change.
5. Use Fetch as Google and submit to index on the pages you have fixed so they are recrawled quickly.
6. Check the Mobile Usability report daily for the next month and watch the counts fall.

Budget for this ranges widely. A theme swap on a small business site might cost $1,500 to $5,000. A responsive retrofit of a custom site with dozens of templates runs $15,000 to $60,000 and more. A full responsive redesign is a separate project with its own case.

Because the update rolls out in real time and page by page, you will not see a single cliff on April 22. Watch mobile organic traffic by landing page over the following four to six weeks. Pages that fail will slide; pages that pass may gain as competitors drop.

Then move to what the test does not measure but mobile users do. Page weight above 1 to 2 MB on a cellular connection is a conversion problem whether or not Google flags it. Forms that are painful on a phone cost you leads. Click-to-call on a business that takes phone calls is worth more than most redesign line items. Mobile-friendly is a floor, not a strategy.

• Redirecting every mobile visitor to the home page of an m-dot site. It fails the user and loses the deep link.
• Blocking CSS and JavaScript in robots.txt. If Googlebot cannot render the page, it cannot see that it is responsive. Google warned about this last year and the Mobile-Friendly Test will tell you if it is happening.
• Passing the test with an interstitial that covers the content on load. The test may pass, the user will not.
• Treating the desktop version as "the real site." Design for the screen most of your visitors will use.

We start with discovery: analytics by device, a crawl of every template, the Mobile Usability report, and an honest look at whether the site is due for a rebuild anyway. From that we plan a route, responsive retrofit or redesign, with a dated list of templates in priority order. Build follows, with the Mobile-Friendly Test run against staging on every template before anything ships. Then we improve, because passing the test only opens the door. Speed, forms, calls to action and content for a small screen are where mobile revenue actually comes from, and that work connects brand, growth, web and technology rather than sitting with a developer alone.

A representative engagement is the digital transformation work we did for an established business whose site predated smartphones as a serious channel. The brief was broader than one algorithm update, but the first phase was exactly this: audit the templates, retrofit responsive layouts to the pages that earned revenue, resolve crawl blocks that hid stylesheets from Google, and then rebuild the rest on a modern platform once the urgent exposure was closed. The sequencing mattered more than any single fix.