How to Make Your Website Mobile SEO Friendly

By now you’ve heard about Google’s mobile first index.  It’s no longer enough to have a mobile site and an AMP version, you now have to make sure your site is mobile SEO friendly.  Although we won’t have any information until it rolls out on a large % of queries, there are a lot of things you can do to prepare.  Below you’ll find a checklist as well as a detailed explanation of how to make your website mobile SEO friendly.

How to Make Your Website or Blog Mobile Friendly:

• Pages Indexed
• Register in Search Console
• Robots.txt
• Equal Markup & Schema
• Canonical Tags
• Alternate HREFs
• Content
• Image Reduction (Not Size But Quantity)
• Image Reduction in Size
• AMPs
• Speed
• CDN
• Inputs
• Lightboxes or Interstitials
• App Download Prompts
• Mobile Backlinks – Theory
• Other

Pages Indexed

If you have a responsive or adaptive site, you should in theory be good to go.  However, if you have an m. or separate mobile site, start by going to Google and typing in site:www.yoururl.com then do a search for site:yoururl.com and then finally site:m.yoururl.com.  What you are looking for is an equal number of indexed pages in your main site version and mobile version.

If Google does not have your complete mobile version indexed, or at least a similar number, it’s time to look at why.  It could be anything from crawl issues or maybe you’ve blocked Google in your robots.txt and .htaccess.  You may also want to look at the meta tags on your mobile pages to make sure they aren’t blocking Google bot.

It could also be a bad navigation and sitemap or something with your x-robots.  If you’re wondering what an x robots tag is, it’s how you can be more page or category specific with how to crawl your site.  i.e. you can tell Google bot to follow the tags within your blog but to not index the tag pages that have been created.

There isn’t a 100% fix all solution since this is usually a case by case issue, but this is definitely the first thing you want to look at.  I don’t know if anyone else is doing this or if it is important, but I’m going to be creating a mobile version of my sitemap/s and submitting that to search console for the sites that have an m..

Register In Search Console

Next you want to register your mobile version in search console.  Many people may disagree or say it’s overkill, but I prefer to give Google the opportunity to pull and provide crawl stats as well as be able to fetch and make sure everything is rendering properly.  You can hopefully check to make sure you’re being crawled properly and so you can more easily discover errors with the mobile version of my site.  When you finish you should have the following set up in search console “www.” non “www.” and “m.”.

Robots.txt

It’s important to take a look at your robots.txt file.  This is the place Google looks for when they want to know how to crawl your website.  Although you probably have your mobile site cleared to be crawled, double check.  It only takes a second to see.  You may want to add in some additional crawls as well.

• Create a mobile sitemap and add it to your robots.txt
• Make sure that you unblock or have not blocked Googlebot from crawling your mobile site.

Equal Markup, Microdata & Schema

One thing to always check is that your schema, microdata and markup have carried through to the mobile version of your site.  Not every web designer or programmer will remember to do this.  Google search console also has a free tool to help and check that it is correct for you.  Remember, Google is using the mobile index as the primary now so whatever you were using to get your rankings and snippets on your desktop version, you should also check to make sure they are available in an equal way via your mobile site.

Canonical tags

If your site is responsive, you don’t have to worry about canonical tags as much.  They should carry over from your main site.  If you use an m. version for mobile, you’ll want to check and make sure that your canonical tags are properly set up.  But there’s a catch here.

If the mobile first index looks at your mobile version first, but you and Google are currently looking at your desktop version, where should your canonical tags point to?  If you have an opinion on this, please leave it in the comments below because I can’t find an answer to this that I trust.

If you change your canonical to the mobile version, what happens to your desktop version since that is what is currently being used?  Is it no longer the one you want to show?  When do you make the switch?  This could be extremely risky since the mobile first index is not live across all queries and we don’t know when it is being rolled out across all queries.  This is why it’s important to follow some of the Googlers on Twitter and to check the Google Webmaster Blog regularly.  This is how many of us find the updates and know when to start making the changes.

For now I’m recommending my clients keep the canonical tags pointed at the desktop version and on the desktop version you use the href alternate tags to differentiate between the two.  Confused by this, don’t be.  The next section will explain href alternate for this case.

I use this free tool to check canonicals and redirects.

Alternate HREFS

This is another scary sounding tech thing, but it shouldn’t be.  HREF Alternate tags are a way to tell the search engines that there is an alternate version of a page.  It could be anything from languages to screen sizes (i.e. mobile).  You use these to guide the user browser as well as the search engines to the experience that best meets the needs of the searcher.

The good news here is that if you have them set up, you’re already saying show this URL for XY screen size or language.  In a mobile first world you’ll add these to your mobile pages (if they aren’t there already) and place the desktop version as the alternate.  If you’re using responsive or adaptive sites, you probably don’t need to worry about this.  Once we have more information on canonical links, you may want to make the mobile the primary page and then change over the HREF Alt tags and canonicals together.

Content

Once Google begins using the mobile index as the primary index, you’ll need to ensure your content is equal on both versions of your website.  Although Gary Ilyes recently tweeted out that hidden text and other ways to provide a better UX for mobile are ok, I wouldn’t trust it…unless you proceed with caution.

If your mobile experience is poor because of a ton of content, and you use tabs or an accordion to provide a better UX, make sure there is a clear and easily visible “read more” or way to find the rest of the content.  You don’t want a manual review where someone thinks you purposely just hid content for SEO purposes.  Small read more buttons or faded letters or even colored fonts that blend into the design can all potentially be bad and cause a penalty.

Time to rant because I run into this regularly with the hidden text and text for SEO conversations.

The bottom line is that you’re running a business.  You need ad revenue or you need sales.  To get those you need multiple streams of traffic including SEO.  Content is the food that fuels SEO and links are the scent that brings in the mouths to eat it.  (i.e. the search engines and their traffic).  That is why it’s important to listen to your SEO in addition to wanting something to be pretty.  

If your company is reliant on SEO, then people lose their jobs if you get penalized because you tried to hide or reduce content to make something look pretty or balance.   A pretty site is useless if there’s nobody there to see it which also means you make no money.  If nobody is there to see it, you make no money.  If it is ok to hide content for UX, make sure it is obvious on how to find the content and you don’t try to blend it into the design.  

End rant.

Even in the mobile index, content is king and not something that you can sacrifice.  If your competitors reduce or remove it, you should send a nice thank you basket once you take their rankings.

Image Reduction (Not Size But Quantity)

Speed is super important and so is UX.  Add heatmaps (here’s the one I use) to your website and to your mobile version and study them carefully.  Which images are visible but aren’t being used?  Maybe they’re just extra, maybe some of them are sitting in the bottom of a page and are being ignored, maybe they’re there because you were hoping to funnel traffic through them or just because they look nice.  All of these can increase the load time of your site and potentially hurt your mobile SEO.

To begin determining which images to remove, ask yourself:

• What’s not being used (you can always test alternate versions if you are trying to get a click)
• What isn’t important for the actual sales process
• Which images get a click and then cause a person to leave instead of convert
• Which images get clicks but don’t participate or add to the sales funnel
• How many images are actually important for the UX and what is there just to look pretty

By going through this list and thinking about what isn’t important or being used, you can begin to pull the images that don’t add to the UX or sales funnel and are only there because someone thought they looked pretty.  I highly recommend this tool to find and test for this.

Image Reduction (In Size)

One of the quickest and easiest wins for load time is to reduce the size of your images.  There are numerous ways you can do this.  Below are a few of the things we do with our clients.

• File types (changing your logos and icons to svg, determining what should be a .png vs. .jpegs for your images that need higher resolution, etc…)
• Compress them (don’t just rely on your editing software, get a third party compressor and see if they can reduce them further)
• Lazy load them (although this isn’t good for image search (that’s debatable), this could reduce total page load time)

AMPs

Accelerated Mobile Pages are Google’s way to load pages extremely quickly.  Some SEOs joke that it is their way of forcing us into a mobile world so they don’t have to recreate everything for us.  Regardless of what you think, AMPs are now in the wild and showing up on a ton of search queries.

Google did a great job at giving you an easy to follow guide and if you’re on wordpress, there are numerous plugins that will automatically create AMP versions of your site.  AMPs basically strip away everything that isn’t relevant to the content and main UX like the background design and some of the excess coding.

We should expect AMPs to change a lot over the next couple of years but the important thing is you have at least some form of an AMP version ready to go.  You also want to make sure that your users can click from the AMP version to your mobile or responsive site so you can get people onto your actual site instead of seeing the AMP version on Google’s servers.

Speed

Mobile is all about speed.  There’s a lot that you can do to speed up your site.  This tool is free and gives you a ton of data about what is slowing you down.

Other things you can do include:

• Reduce excess code (minify it)
• Move everything inline from Javascripts and font families/sizes to image calls (this reduces overall code as well)
• Remove excess javascripts, pixels and code you no longer use or need
• Host everything within your CSS and HTML
• Enable compression and caching
• Use Gzip to deliver a page
• Define what to load or start loading first (i.e. above the fold vs. below the fold)

CDN

If you’re not using a Content Delivery Network or CDN, you need to start.  A CDN is a way to serve a website from a server that is closer to the location of the person accessing your site.  If you’re in Japan and getting a site from a US server, it in theory that takes longer than a server based local to them.  If you have a worldwide CDN, it could load your site from Japan instead of the US and your new visitor will have everything quicker.  They’ve become standard for many hosts so write to your hosting company and see if you’re on one.  If you’re not, ask them how to have your site delivered through one.

Inputs

I learned this one from Jon and RavenTools.  Inputs are not being used as often as they should.  Inputs are small pieces of code that tell your mobile device which types of entries to show when filling out forms or fields on a mobile device.  For example, if you are asking for a customer to enter a date, you can use the input for dates instead of just showing a keyboard and making them type it out.

If it’s a series of numbers (credit card entry), you can show the keyboard with numbers and symbols instead of the version with letters.  If it’s an email address, you can use an input to show a keyboard with the @ symbol and .com ending key.  If it’s a month and year, you can use the input that shows those fields in a scroll.  These are really easy to do and are not being used as often as they could be on a per field basis.   In the future, they could easily become a ranking signal because they provide a better UX for mobile users and are easily seen by the search engines.

Lightboxes or Interstitials

I basically covered this in in my post about instertitials and being SEO friendly.  Read that post then come back.

Download Our App Prompts

If your website prompts people to immediately download your app or prevents content from appearing because you feel your app provides a better user experience, this may now be bad for your SEO.   The exception here is for people searching for your site by brand name.  If they search for you by your brand, they’re looking for you and offering your app could be a good thing.  For everything else, hold off on pitching your app.

Google is showing your page because you have a relevant user experience for that query.  It could be the right tshirt for someone looking to shop, content that answers a question or anything else.  The goal of a mobile first is to give the content and then pitch the extras like an email optin or to download your app.  Making someone download an app or pushing for them to download it immediately prevents them from finding the content that Google expected you to show.  This defeats the purpose of Google sending them to you and may prevent Google from sending you more traffic.

Instead of offering your app immediately, offer it after the person finishes your checkout.  You can do it at the bottom of the page after a long post or you can do it via email in a confirmation once an order has been placed.  What you don’t want to do is try to push it on the person or make it a requirement to access the content that Google was trying to show the visitor.  That is potentially a bad UX from Google’s standpoint.

Mobile Backlinks (This is more theory)

Just because Google is crawling the mobile site as the primary site does not mean that backlinks to a mobile site should be built.  If you want to know about backlinks, read this post.  Now lets go into why building links to a mobile version is probably a bad idea.

1. It’s unnatural. Mobile content normally only shows up when you’re on a mobile device.  (I’ve seen a few AMP pages show up on my desktop and in a Facebook feed, but that is a rare exception).  Blog posts and journalists are more than likely not writing an article from their mobile device.  If they would pull a page or reference you, they would normally reference or link to your main site and not the mobile version.  Think about how hard it would be to add links, etc… from a phone, or even write a real post from a phone.If its an editor from a large news site, chances are they’re at their desk writing and would find the desktop version, not the mobile one.  This could change as technology advances, but for now, if someone is pitching build links to your mobile site, you may want to put it on the back burner as that is probably unnatural looking and an excessive amount could cause an unnatural link penalty.
2. Seeing a mobile version from a desktop is weird. If someone is reading an article from a desktop computer and clicks to a mobile version of your site (especially ecommerce), this is a weird experience.  It is highly unlikely that any reasonable or reputable site would be linking to a mobile page (especially an ecommerce site) from an article or post.  That goes back to my point above about having natural links.  This doesn’t apply to responsive since the mobile version would redirect automatically to the proper formatted page.
3. There is an exception. If your site is build almost 100% for mobile like Instagram or a photo site, then there is a chance you only really built a mobile site with no intentions of having a desktop experience.  However, you probably coded it originally without an m. because it is built to view on a mobile device so you actually don’t build mobile site links anyways.

Building links at this point to the mobile version of your site is probably a bad idea.  Keep building them to your main site and once we have more information on how the mobile indexes will work, and if there is a large change where bloggers and media professionals start writing a majority of posts from their phones and tablets, then you may want to think about it again.

Other

There are other things you’ll want to check like making sure your device type redirects are in place.  You can do these a number of ways (Do a search for “device type redirects” and you’ll find a few copy and paste scripts).  They tell your website to look at the user agent and determine which version of your site to show.  This is fairly standard but something to double check.  There’s also making sure that if someone clicks on an image, you don’t abandon them on a page where they can’t click back.  This may cause them to close the session and you lose the visitor before they can convert.  You should also make sure your videos can be paused or turned off easily as well as other things for UX.  They’re all important for mobile UX, but might not be as important for the mobile first index.

If there’s something you think I left out, please feel free to leave a comment below.  Thank you again for reading and let me know if there’s anything I can do to help.