Google Mobilegeddon has rolled out completely, have you been hit? According to TechCrunch 44% of the Fortune500 websites are not optimized yet. Here’s how to get your rankings back after you’ve been hit.


In the following guides, I will give you a crash course to optimize your site for mobile devices. Time is of the essence here, I get that, you want your rankings back, but you should know that it will still take at least a week to work through all of this in a professional manner. Take your time with it, don’t rush the development process too much. To streamline the process, I added “urgency” levels.

Please note that many instructions are particular targeted towards WordPress users, but users of other systems can apply the tips as well but have to do a bit more research on their own:

StepActionUrgency
1Stay CalmHigh
2Evaluate Traffic Loss
3Evaluate Mobile Traffic Loss
4Identify CulpritsHigh
5Take ActionHigh
6Get A Responsive TemplateHigh
7Combine CSS FilesHigh
8Deregister CSS FilesHigh
9Combine JS FilesHigh
10Install APC Cache
11Install W3 Total Cache
12Install NginxHigh
13Debug WordPress
14Optimize UsabilityHigh
15Review Your Work / Analytics

Step 1: Stay Calm

You haven’t learnt how to stay calm when something unexpected happens to your business? Yes, I get it, it’s dramatic and you could scream and cry and complain a bunch, but what good does that do? Take a deep breath and let go of anger. Then focus on the task at hand. Review what went wrong and move forward. That’s the only way. Forward.

Step 2: Review The Traffic Loss – Overall

First, we need some actual numbers to estimate how much damage the mobile algorithm update has done.

1. Log into Google Analytics

2. Click on Behaviour, Overview in the sidebar

3. Click the button Hourly on the top right, then select a Date.

300 Percent Traffic Loss Google Mobilegreddon.png
(Image: Example, not actual representation)

Pick April 22 and the same weekday 7 days ago (Wednesday 15th April). Please note that Google will roll out the update over the course of a week. Upside or downside revisions are possible and you have to keep an eye on this for the entire duration.

Compare Date Range.png

This is what it could look like for some sites: A 300% overall traffic loss, but that’s because it was a mobile-only site that wasn’t properly optimized and was loading incredibly slow on mobiles. (This is just an exaggerated example I made up).

Step 3: Compare The Traffic Loss Per Platform

The Mobilegeddon update only affects mobile searches, not desktop, so we need numbers for visitors from mobile platforms.

1. Click on Audience, Mobile, Overview

Mobile Device Traffic Overview.png

2. Now you will see several platforms, desktop, mobile and tablet. We are only interested in mobile and tablet. How great is the loss?

Mobile Traffic Declines.png

Step 4: identify Possible Culprits

The two most used platforms to optimize websites for mobile are:

You should get a score in the 90’s for page speed and a score of 100 for user experience, anything less is a failure.

The difficult part, making a website load extremely fast on mobile platforms:
Mobile Speed Factor.png

The easy part, optimizing a site for usability on mobile phones:
Mobile User Experience.png

Step 5: How Do We Optimize Our Site?

There are two different areas that require optimization as you see above: Speed and User experience. To improve user experience on mobile devices, Google suggests you use larger fonts, larger buttons and make sure the elements are not too close to each other. You should also make sure the site does not have any elements that fall outside the viewport. Unfortunately, user comments or content often include large words. You can control that using CSS. It’s also important you make those changes using media queries, rather than delivering the same experience to desktop and mobile users alike.

The real issue is most often not usability. It’s not that difficult to make text larger or a site responsive. Making a site faster on the other hand requires many days of work. Here’s a step-by-step guide for WordPress users that will give you a little insight into what server technicians and webmasters are doing to speed up their sites.

Step 6: Getting A Responsive Template

If your WordPress template is not responsive (changes dynamically based on browser size) you need to download one. There are many free ones. Don’t buy one, they are often overloaded with scripts and JS, which you will have to remove manually. Quite a tedious task! Spend 1 hour researching a free, responsive theme that fits your site.

If you really don’t find a free one, head over to themeforest.net, locate a “minimalistic” theme with VERY few scripts in the source code. The more scripts, the longer this will take to clean up and time is of the essence here. Please note, none of the so called premium themes are ready out of the box and all of them have to be cleaned up and optimized for mobile users. I haven’t even seen one theme that properly combines JS or CSS files. (Hint: Quite a niche for a witty theme developer).

The cheapest responsive portfolio theme I could find was $15 on themeforest and included 19(!) different scripts. As you see just from this example, all themes you can buy require extensive re-modeling. You need to bring this down to 2 to max. 3 scripts for an optimized site.

Tempus fugit, so let’s get to it and optimize the hell out of this theme!

Step 7: Combine Multiple CSS Files

Open your website and open all CSS files in new tabs, right-click on them and select “Save As”. Store them on your drive.Then Copy and paste them into a new text file using notepad++ in the correct order they appear on your website in the source code. Then head over to http://cssminifier.com/ and minify the code. Open your style.css and add the entire line of code to the bottom.

Step 8: Deregister / Comment CSS Plugin Files

Open all plugin folders via FTP and comment (add two leading slashes) wp_enqueue_style(*.css) – this will remove the CSS file from your source code. Please note this is a bad practice but will save you time! If this wasn’t a crash course, I would recommend against doing such things. It’s not tidy and you will lose any changes you made whenever you upgrade the plugin.

If you want to do it right, you locate the appropriate deregister functions and add it to your functions.php – if you rarely update the plugins in question, you can comment wp_enqueue and be done with it. How you approach this is up to you.

This is the code I use to deregister scripts and styles. I try to avoid plugins with external sheets whenever possible.

 if ( !is_admin() ) {
function my_init_method() {
wp_deregister_script( 'l10n' );
wp_deregister_script( 'jquery' );
wp_dequeue_script( 'swfobject' ); 
wp_dequeue_style('NextGEN-css'); 
wp_deregister_style('thickbox'); 
}
add_action('init', 'my_init_method'); 
} 

More information about deregistering CSS stylesheets

Step 9: CSS Minifaction & Inlining

Minify your style.css and inline the entire CSS file in your header. CSS files are blocking elements in your rendering path. As long as your CSS file is not over 200KB large you should inline the entire thing. Please note this can be a bad recommendation based on your site and usage of CSS, but from my experience the JS code that Google provides to defer CSS loading is not optimized for ad revenues. I would like to optimize my site for mobile devices, but I also need to consider my revenue.

What does it mean, “inlining”?

Inline means “within the code”, not within an external file. Basically you select the entire content of your CSS file, open your header.php and paste the code between two style tags like this:

<style>CODE</style>

Best practices says you should inline only critical CSS, why do you inline your entire CSS file?

I disagree, even inlining large amounts of CSS is not a problem if you properly compress your site (nginx compression 5-6) and the CSS size does not exceed 150-200K. You can test this yourself and see how much of a difference it makes.

Loading an external CSS file will require an additional DNS lookup and requires additional processing time and should be removed from your rendering path. If all of your CSS is critical for your ad revenues, you can’t simply differentiate between critical and non-critical. It’s a pointless exercise and the loading of the page is ugly and goes less smoothly. It feels “sluggish”.

I strongly advise against deferred CSS loading, unless you find a way to defer the loading ONLY for mobile users, then it would actually makes sense, but since most sites are set up in a way to serve both desktop and mobile users this won’t apply.

The user experience is horrible on desktops if you load CSS via JS.

However, if you would like to try it yourself, here’s the Google guideline on CSS delivery

Step 9: Combine Javascript Files

4. Ok, we now have a responsive template and we have deregistered all CSS files and inlined our entire style.css in the header. Great, no more CSS files that are blocking the page and a responsive site!

I am sure you are a smart gal and have also done the same for all of your Javascript files by now. If not, get on it.

Locate all *.js files in your source. Please note that you may break some functionality by doing this and you need to carefully combine JS files. Sometimes it is better to have two to three separate JS files rather than one large.

Step 10: Install APC, PHP.Net Recommended Cache

The PHP development team recommends using APC rather than XCache, Memcache, etc. Larger sites (50k+) may have to rely on memcache for multi-server load-balancing setups, but we only have a small sites with 1 to 50k uniques per day, so APC will get the job done.

Open a shell and run the following commands. If “shell” is spanish to you, download a copy of Putty, read the starter tutorial and learn everything about the commands “pico, cd, chmod, chown, yum, rpm,”. This should get you started.

yum install php-pear php-devel httpd-devel pcre-devel gcc make

Lets install APC using PECL:

pecl install apc

Done.

Step 11: Install W3 Total Cache, Use APC For Database And Object Caching

Download W3 Total Cache

Use APC for your database and object caches. Use page_enhanced for your page caching. Make sure to configure browser caching.

Step 12: Install Nginx Or Nginx Admin On WHM (Skip If Low On Time)

You are still using Apache? Wrong move. It’s time to upgrade and you don’t even have to rewrite your mod_rewrite rules because we are using Nginx as a frontend proxy and Apache will be our backend to handle rewrite rules and security.

WHM users can install Nginx admin but it is recommended not to do it on a production environment. If you have a development server, try it there first. If you don’t have one rent a cheap one at linode, iweb or wherever you like. If you break something, make sure you are capable of opening httpd.conf and modifying the line “Listen :8080”. You may have to modify this line when something breaks, so if you are unsure whether you can do this upgrade yourself, get in touch with your local geek or server admin and hurry up, we need to move forward.

cd /usr/local/src

wget http://nginxcp.com/latest/nginxadmin.tar 

tar xf nginxadmin.tar

cd publicnginx

./nginxinstaller install 

Step 13: Debugging WordPress, Tuning MySQL And Nginx

Unfortunately, I am afraid switching to Nginx absolutely requires you to debug WordPress. Apache is the master of compatibility and allows you to run a sloppy WordPress setup, but nginx is not so forgiving and rightly so. Debugging WordPress plugins will help you to speed up your site significantly. Outdated plugins are the bottleneck of every WordPress site. They are slow, broken and badly programmed. Hire a programmer if you are incapable of debugging WordPress yourself.

Apache requires some tuning to run better as a backend server. Open httpd.conf and make sure your StartServers, MinSpareServers, MaxSpareServers are directives are not set too high. As a frontend server Apache can handle quite large values but as a backend you will end up with lots of connections stuck in TIME_WAIT, driving CPU load up for your entire site. Not a good thing to happen on a production environment.

You can verify that using the command “top” and netstat:

netstat -nt | sed -r -n 's/^tcp +[0-9]+ +[0-9]+ [0-9\.]+(:[0-9]+).+TIME_WAIT/\1/p' | sort | uniq -c | sort -n

If you continue having problems with many TIME_WAIT connections, you can consider this:

echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse

Please note this is a bad practice too and we’re using that only because we have little time to accomplish what we want and reduce our server load. You absolutely need to debug WordPress and tune your configuration files instead of modifying tcp system values. It’s a bad practice even if tcp_tw_reuse is considered ‘safe’.

Step 14: Optimizing Usability

Now comes the fun part. CSS and media queries are really simply and allow you make buttons and fonts larger for your mobile users.

Break looooong words on mobile devices:

word-wrap: break-word;

Responsive tables:

@media only screen and (max-width:400px){table tr td{word-wrap: break-word;}}
@media screen and (max-width:800px){table tr td img{width:50px}table tr td{width:30%}}
@media only screen and (max-width: 700px)
.entry td, .entry th {
  display: block;
  clear: both;
  float: none;
  width: 100%;
}

Do you see what I am doing there? table data cells are displayed as block and use 100% of the available width. They also break to a new line “Clear:both”. I am also making sure large words within tables actually break using word-wrap: break-word

Make buttons and fonts larger:

@media only screen and (max-width:400px){#breadcrumbs span a, #breadcrumbs a{padding:20px;line-height:40px;height:40px;overflow:hidden;font-size:18px}

Do you see how I change the line-height and the font-size for my breadcrumbs? Google’s mobile inspector complains if touch elements on your site are too close to each other. If they are too close to each other the thinking is that mobile users will accidentally click the wrong element. Simply imagine a nery dev with fat fingers to remember why you are doing this, just kidding.

Step 15: Review Your Work And Keep An Eye On Your Analytics And Metrics

Clean up. Remove useless code and comments. Make sure everything is tidy and organized. Keep an eye on your debug.log and resource usage using top.

  • Consider installing NewRelic on your server to keep an eye on PHP error rate.
  • Make sure Nginx is configured correctly for IPv6.
  • Consider looking into SPDY and HTTP 2.0.
  • Consider starting a changelog for your server changes, your websites and configuration files, possibly even your entire business.

You have done an amazing job following this guide in a little amount of time. Reward yourself, have some patience and wait until Google makes the next update that will hopefully lift your rankings again.

If you found this guide somewhat useful, all I am asking for is that you bookmark our site and if you like connect with me on LinkedIn. I always appreciate endorsements or expertise requests. I am also open to pro-bona consulting for non-profits whenever my schedule allows it.

I’ll be setting up our QA again where you can ask question. For now simply post a comment.

External Links – Further Reading Material

OKO, a certified Adsense partner that helps publishers to manage their ad inventory and optimize their Adsense earnings, has recently published an article about the likely impact this update could have on your earnings:

Searchengine Journal is contemplating whether .edu pages will be buried completely and whether Mobilegeddon was not publicized enough:

Last, but not least, Siliconbeat revealed that many public organizations and services have not caught up to the smartphone era and will most likely disappear from mobile search results completely:

To sum it up, many large companies and organizations are not ready for it, including many Fortune500 companies and public organizations and I consider the update a nudge by Google to advance the web. A legitimate and bold move. However, I also believe they will update this algorithm more frequently and will lift the penalty from all non-mobile friendly pages that have optimized their pages very quickly.

This update does not have the smell of a desperate move by the company board trying to please shareholders. This seems to be a calculated move initiated by web developers that was publicized to a great extent (again, unlike Panda).

Now it’s time to sit back and wait while the search engine gods decide the fate of your hopefully responsive website.