Targeting With Mobile Search #SESLON
Estimated reading time: 7 minutes, 21 seconds
Speaker: Cindy Krum
Cindy Krum is the CEO of MobileMoxie, LLC, a mobile marketing company based in Denver, Colorado. Cindy has previously spoken at SMX ,Conversion Conference and several other events and she has been featured on Search Engine Watch, Search Engine Land and Marketing Land. Cindy is also the author of Mobil Marketing, Finding Your Customers No Matter Where They Are.
Cindy’s presentation was focused on winning at mobile SEO and targeting. Cindy has kindly offered SES London attendees two months of free access to her mobile tool – simple use promo code SESLondon2013 on the checkout.
In the past 18 months Google has launched a smartphone crawler (in addition to their original mobile crawler) and they’ve announced a preference to responsive design.
Mobile website design options:
• Responsive design – One URL with flexible content on a grid that rearranges itself dependant on the device rendering it
• Mixed solution – RESS
• Mobile subdomain
Considerations for mobile design:
• Everything happens on the existing URLs
• Way less taxing on Google’s resurces
• Mobile pages can have too much content – impacts bounce rate
• Harder to target mobile specific keywords with RESS
Google will compare notes with the different crawlers to check that you’re sending the same content to the different devices. Also, with mobile marketing, you need to be more concerned with http headers, with responsive you don’t need to do anything with the response codes.
RESS is responsive design with server side components, this allows you to send different content dependent on the device. With RESS you can have the flexible grid and say that when it’s on a phone, we want you to send the smaller version of the image to improve page load performance. You can also send different or more / less page elements to different devices based on different configurations.
From an SEO point of view, RESS is not cloaking and it can help to provide a great use experience. It’s a more complex solution but the value is in the bounce rate and the improved levels of engagement.
RESS is slightly harder for Google to crawl than conventional responsive design, however Google have said that they like it as a solution.
When you’re setting your http headers, you need to set a varies attribute (this would usually be the same for gzip) – with RESS you need to add “, user agent”.
When the crawlers hit the website, they’re going to get the version you’re emulating – so the desktop crawler will get one version and the smartphone crawler will get a different crawler. Also, sending mobile users to a splash landing page promoting your mobile apps is a risk as the bot won’t get the mobile navigation.
Separate mobile pages (m.) gives you a mobile-specific experience, this can be useful for local content, for example a cash machine finder. The problem with this solution is that it’s taxing on Google’s resources, as your website ultimately needs to be crawled / indexed twice. This can cause issues with SEO and indexation.
Responsive design forces you to mobelise your content and consider mobile users on every page. Cindy recommends that your mobile website structure replicates the desktop version – it makes things easier and also compliments SEO. If you have mobile specific keywords then you need to be using the m. solution as it gives you an additional page to target them with.
If you do want to provide mobile-specific content for keyword targeting with a responsive website, you can append a query string to differentiate.
If you mirror the structure of your websites, you can use the canonical tag to piggy back off of the desktop pages. You can also use rel=”alternate” media=”handheld” to tell Google that it’s a mobile version of the original variation. You can also implement this with your sitemaps – making it safer (not necessarily fundamental).
When you have mobile specific pages, you need to apply user agent redirects – it’s important for SEO that you do this page for page, as otherwise you could provide irrelevant content. Lots of websites will recognize you’re using a mobile phone and take you to the mobile homepage, which is terrible for user experience.
Case study: Infotainment website > came to MobileMoxy for a scalable mobile strategy and they wanted improved rankings. The client had a platform that scraped and re-rendered content for mobiles. The mobile platform was big, but they don’t know anything about SEO. The platform wasn’t pulling across title tags, meta descriptions etc. The client’s platform was also very pro-404s, which was bad for SEO as Google doesn’t like 404 errors.
Also, when the website ran out of server space, pages would start 404ing, which caused lots of issues. The platform thought that the best UX option was to render all types of URLs, which is a very ‘old school’ way of thinking – it caused a lot of duplicate content issues. They were rendering multiple variations of pages based on case, trailing slashes etc.
DUST – stands for duplicate URLs same text > often refers to duplicate content created by the server.
The client also had a situation where only some of the pages we’re being mobilized, meaning you could easily go from a mobile page to a desktop page – which is confusing for users.
Cindy recommended that they implement canonical tags and rel alternate tags, setup better server rules and eliminate DUST, update feeds to ensure that SEO stuff is being pulled too and improve performance.
Next case study: A doctor directory website
The client knows that Google likes responsive design, but their developers are not open to implementing it. They were in the process of implementing a desktop page and were worried about the SEO implications.
The client had very limited multimedia content, which is harder to interact with on mobile. The new m. site didn’t include the whole website and there were serious crawl issues with the website. The structure of the website wasn’t optimized for mobile crawlers and some of the pages of the website wouldn’t be indexed.
The client was doing some compression, but they weren’t doing it properly.
Cindy recommended moving forward with the m. website as planned for the key landing pages of the website and use responsive design for all of the deeper pages. The long-term goal was to move away from the m. as they learnt to develop and move to RESS.
Case study 3: Ecommerce website
The client had a CMS that mobilized the content on a m. website – they had a smartphone site, a WAP site and a desktop site, but they didn’t have a tablet website.
They had a lot of video and quality imagery, which wasn’t ranking well in mobile searches – which raised alarm bells. There were also issues with configuration of www vs non-www, trailing slash canonical issues etc.
They also hadn’t looked at a preview of the search engine listing, which was displaying a display error message as the meta description. One issues with this is using the error message in the first place, it’s unnecessary.
Case study: Video library website
The client approached MobileMoxie to find out if they were doing a good job on their mobile SEO. The issue they were facing was that they had lots of unoptimised user generated video content.
The client was using RESS and it was being implemented well, one of the best implementations that Cindy had seen. The client were also using an m. website which was being used for mobile users. Tablet users were being served the tablet variation.
Mobile Moxie also found that there wasn’t a description tag and they had a very under-optimised URL structure (just random letters and characters). The website was also relatively slow, which provided a bad user experience.
The client’s main issue was that they weren’t optimized for tablet-related keywords, for example iPad XXXX videos (due to their inability to render flash content).
The main recommendation for them was to create some tablet-specific landing pages so that they could target keywords relative to tablets. Cindy also recommended using the rel alternative tag to differentiate the content.
They also recommended providing options, in case the device / user agent redirects if they served the wrong content.