Last night, SwellPath kicked off our brand new series of talks, SwellPath Presents, with a session on responsive design and mobile SEO. Today’s blog post is a long-form blog post version of that talk. Check out the slide deck posted at the end. Also, there may be video coming coon (fingers crossed).

For the first ever SwellPath Presents, we’re talking about something that I’m really excited about; Responsive Web Design and Mobile SEO. Before we get deep into any of that, let’s take a journey back in time to see what led up to making RWD so important and then go back to the future and learn all about what you need to know about mobile SEO in 2013.

How it all began

Back when I first started doing stuff online, web design was easy! You could just fire up Microsoft Frontpage, insert some tables, fill the cells with text and images, and embed a couple style rules. After you hit publish, you’d have a nice site that’d look pretty fantastic on your 800px by 600px screen. Who’d even heard of the term “multiscreen experience” or “mobile UX”?

At that time, a lot of us made calls on a brick. I feel sooo old saying this, but back in my day, cell phones were for phone calls and computers were for browsing the Internet. If we were lucky enough to have a phone that could surf the web, you probably got a nice text-based WAP (Wireless Application Protocol) site. Not too exciting.

Then scumbag Steve made everything a whole lot more complicated. We all started getting the iPhone. A good number of people already had web-enabled phones before that, but I consider the iPhone launch to be the catalyst took mobile browsing over the edge. Later on we got Android (the Android G1 was my first smartphone). Then these tablet things started to take off. Today, between the hundreds of thousands of devices we can choose from to browse the web, we have at least 30 major screen resolutions that websites need to look good on.

So today those WAP sites aren’t cutting it any more. And those “normal” desktop websites aren’t cutting it either.  That artifact that was built using tables and hardcoded style rules isn’t getting anyone excited…about anything. And don’t even get me started on Flash websites.

Sure, our mobile devices have cool features like tap-to-zoom, reader functions, and 3rd party readability apps, but isn’t it kind of embarrassing when we have to rely on someone else’s app or device to try to fix our broken mobile experience? I’m a big believer is “as few clicks as possible”. Why make users click extra buttons just so they can read your website? Couldn’t we just start things off on the right foot and just give users what they want without them having to ask for it?

And we’re only talking about content readability here. We haven’t even touched on ecommerce. 

But in any situation, we know what users want when they’re on mobile; a great mobile experience. When they’re on a mobile device, they want something that looks great on mobile. It’s a really simple idea, but executing on that idea is still a challenge that a lot of us face.

Even though it is a big challenge, we certainly can’t just ignore it, even though maybe we’ve pushed it to the bottom of our list for a few years. This “mobile thing” is a big freakin’ deal. I can’t imagine how this trend is news to anyone. Each following year, we’re seeing a huge increase in the volume of mobile traffic that hits our sites; a huge increase in the amount of time people spend browsing on mobile devices; a massive increase in how many ecommerce transactions occur outside of the desktop environment.

Put yourself in the shoes (or fingers) of a typical user. Or, just think about when you’re not actually doing stuff for work, but you’re looking for information online or trying to buy something. You expect to have a good mobile experience; users expect to have a good mobile experience; our potential customers expect to have a good mobile experience.

Yet most of the time, they don’t get it. Check this out! “79 percent of online shoppers who experience a dissatisfying visit are less likely to buy from the same site again while 27 percent are less likely to buy from the same site’s physical store” (source) Holy crap! Those kind of findings strike fear into my heart, because I still know people who have mobile site’s like this. ::gasps from the audience::

And it gets worse, 57% of users said they expect a mobile site to load nearly as fast, if not faster, than a desktop site (source)! Even though we might think expectations like that are unrealistic, it falls to us, as marketers and developers, to make sure users get the experience they expect on mobile. Otherwise, we may be left scrambling to explain why our mobile conversion rate is through the floor.

Indeed. What about SEO? Out of all inbound channels, organic search has the potential to be any site’s topic traffic driver. Search engine optimization is a huge opportunity to attract people who aren’t familiar with your site or make sure people who already know about you can get to your site easily through search. Without mobile SEO, only the folks who have your site bookmarked or click on an inbound link will know about your sweet mobile experience. SEO is what allows more people to get to your site through mobile search.

However, even if you know the basics of optimizing your site for search, mobile SEO can be a whole different animal. The search engines have known for years that the needs of someone on a mobile device are different than those of someone who’s searching from a high-powered desktop, with a high-definition monitor, and a strong Wi-Fi connection. Google and Bing both have dedicated mobile spiders that allow the engines to rank your site differently in mobile search than they do on desktop search. For better or for worse, we have to satisfy two different types of crawlers if we want to do modern SEO right. What that means is that we need to make sure our mobile experience looks good to users and to search engines. Wow. That sounds like a lot of work.

The reality is that it’s super freaking hard to provide that user-focused, search engine-friendly experience. I mean, building a world-class desktop website is enough of a challenge as it is. As a marketing team, you want a nice cohesive, branded experience. As developers, your biggest priorities are making sure the website is stable, that the different systems are integrated cleanly, that the site is cross-browser compatible. We’re not even talking about mobile yet!

So when we can finally give a moment’s consideration to mobile design and SEO, we’re overwhelmed by options. What’s even worse is that we’re overwhelmed by a abundance of professional options. Many of which actually contradict other expert opinions. So which one is right? How do we solve the problem of the mobile user experience?

Well, I think we can all think this through together and decide what’s going to work the best based off of what provides the best experience for users, for our website teams, and for search engines. So think about your mobile browsing over the last month. If you can, try to recall a few different experiences. Let’s go over three types: the good, the bad, and the totally awesome.

Let’s say I’m doing a search for “Game of Thrones Episode Recap” and I click on a result I like. The site takes a little while to load, but when it finally pulls up, I notice that I’ve been redirected to a mobile version of the site (m.hollywoodreporter.com). Since it’s a dedicated mobile site, the text is formatted to fill my phone’s screen, non-vital images are small, and the navigation is condensed. It’s pretty nice, even if the user-agent detection and redirections did add a bit of lag.

For another experience that I’d consider good/decent, I did a search for, appropriately enough, “mobile SEO” and click through on an SEOmoz blog post. The site loads up quickly and even though it’s definitely a desktop site, I can just hone in on the main content block, double tap, and it zooms into the content. On mobile safari, I can even hit Reader and bring up just the clean text (I do that a lot). With this one, I can get the information I need but I’m kind of indifferent to the whole experience. Sure, wasn’t really optimized for mobile, but I can deal with that. Not having a mobile experience at all is by far the most common way to deal with mobile users.

For this example, I clicked on a link that someone I follow on Twitter had posted. I click through his shortened link on Twitter and my browser starts to redirect to the article I’m trying to read (something on company culture). Halfway though the page load, I can see that another redirect kicks in and I get a loading screen for about 5 seconds (eternity on a mobile device). Studies say that 40% of customers will abandon a site if it takes longer than 3 seconds to load. Luckily, I have pretty low expectations when it comes to mobile site speed, so I hang around

I wait and wait and when I finally get a page I realize that it’s not even the article I was trying to read; it’s the site’s mobile homepage. The homepage has all their top stories, but I can’t find the article I was trying to get to. Some people could try in vain to navigate to what they were looking for or dig for a search functionality, but at this point, I’m done.

The site essentially has a rule that says to, no matter what page is requested, redirect all mobile traffic to the mobile homepage. If you do this, I hate you. It’s just like the ultimate in lazy BS. I’m sorry, but it’s true. There’s no reason to ever do this.

Let’s take this one step further: I click through on that link, and instead of getting to my content, or even the homepage, I end up with this hard-to-close popup that tells me I should download the companies app. I’m on a mobile device and by nature, my interactions and my attention span are already lightning quick. Not to mention, my connection isn’t the best. You want me to click install, wait for the app store to open, download your app, and then figure out how I’m supposed to find the content I was originally looking for? Fat chance. Good luck with your mobile bounce rate. I kind wish these companies would check that once in a while.

Thank you to Will Hattman for suggesting this wonderful XKCD comic that sums up the experience perfectly.

For this example, I searched Google for “Portland Nightlife”. The site loads in 2 seconds and without any redirection or “loading” screen, the text wraps to width of my phone. The content is the highlight, with an unobtrusive icon for an expandable navigation. There aren’t any social icons and the images are all small and don’t slow down the page’s load time. I decide bookmark that post for latter and I realize it’s just a regular URL, the same thing I’d see on the desktop site. How cool!

Another notable thing here is that the page showed up well (#1) in Google’s mobile search results. Was it coincidence that it was good content and a good experience? I’ll let you be the judge of that (spoiler alert: it’s not a coincidence).

Overall, once the page loaded (and loaded quickly) it looked great. All the unnecessary elements were gone and the content filled and wrapped to my phone’s screen. Later when I open that same link on my tablet, it has some extra stuff I can tap on that the mobile site didn’t have, but it still looks fantastic. In a week, I can open that link again from my laptop and it looks amazing there as a full-featured site. See where I’m going with this? One single page that looks great on every device I want to use to check it out with.

• The mobile-specific site and the desktop site gave me what I’d call a good experience. Maybe it was just decent, but I’ll upgrade it to a “pass”.
• The mobile site that redirected me to the homepage (or some other ridiculous thing) was a nightmare.
• The magic one-page-fits all gave me an awesome experience. So what the hell was that?

Was it worth the wait for me to finally get to the point? I hope so. Responsive Web Design (or #RWD) is an approach to web design where we architect a single site to provide an optimal viewing experience on any device. We have one domain (www.swellpath.com) and one code base, but all the rules that determine the visual presentation (layout, font size, imagery, and more) are responsive. The style rules respond to the width of whatever browser is being used to view the site.

We can figure out what the width is with this incredible feature of CSS3 called media queries. So on any modern website, most of your styling is specified in an external Cascading Style Sheet. CSS3 media queries allow you to detect the browser size of the device that’s currently accessing the site and the fire up the appropriate section of your stylesheet. And this is all done on the client side so that each user’s experience is tailored specifically to how they’re browsing your site.

That’s amazing! We’ll get into the specifics in a bit, but RWD basically allows us to provide an awesome mobile experience on any device. We’re only limited by our creativity and our ability anticipate browsing conditions.

Ethan Marcotte first coined the term “responsive web design” in 2010. His original piece on A List Apart is a great intro to responsive and certainly worth reading. He also wrote a book, by the same name. When Ethan first called for responsive, he predicted that mobile browsing would outpace desktop web access in three to five years. That’s very interesting since in about two weeks, it’ll be three years since he made that prediction. In arguing for responsive web design, he noted that client requests like, “build me a mobile website”, let us, as designers and developers, compartmentalize and avoid the problem of dealing with a multi-screen reality in an elegant way.

Now one methodology that predated Responsive was this “mobile first” approach with “progressive enhancement”. “Mobile first” centers on building a basic, yet functional mobile experience, and then progressively enhancing that basic foundation; adding in other elements and styling for desktop display.

Now we have Responsive web design that allows us to have a happy medium; the best of both worlds. We have a singular code base and we can style it completely differently for mobile, tablet, desktop, high-def television, or anything else.

Let’s take a look at what responsive looks like. First, we’ll start with the most basic of basic examples. Consider this demo page I put together at mikearnesen.com/rwd/. Looks like a pretty standard, stripped down site. We have a navigation bar, a few headings, and a little bit of text, with each element surrounded by a black border.

Let’s pull up the code so you can see the singular code base; the stable foundation that responsive sites are built off of. Take a look at the body tag first. There’s our H1 heading, the h2 heading, a few simple paragraphs of text. I’m personally a fan of putting your content at the top of your source code with the navigation on top, so the <nav> shows up at the bottom.

If we look at the <head> now, it’s all pretty standard. The important thing to pay attention to is the stylesheet link. That external file handles all the styling for this page. Before we hop into it and look at how the mechanics of responsive work, let’s go back to the user-facing side.

We start of in full screen; a standard desktop display. Since we have plenty of room, the navigation is at the top and our content spans most of the screen.

Then if we resize now let’s resize the window to simulate the width of a small desktop monitor. When we hit this “break point”, a new style rules kick in! The border around out content turns blue! Completely unimpressive, I know, but it illustrates the breakpoint clearly enough.

Let’s take it to standard tablet width. We resize until the breaking point and then BAM! Not only do we get a new border color but the nav also drops down to below the content. This is a very simplistic handling, but we know users on an tablets (and other smaller mobile devices) are primarily concerned with getting to the content, so we make that the highlight. We also see that the font got a bit bigger.

Let’s take it to the final, narrowest width for iPhones and we see that the nav turns square, the headings shrink to fit the smaller width, and the paragraph font size gets bigger so it’s easier to read.

So what exactly made all of that possible? Let’s pull up the code again and open up that stylesheet we talked about. Check it out; after some universal style rules that apply to all screen sizes, we have this “very small screens” comment. That @media on the next like is what makes the magic happen.

The “@media only screen” is a CSS3 media query and allows your site to check what the browser’s current screen size is. You can specify a max and/or a minimum and then everything within that section gets fired off only when those size conditions are met. So in this example, we have a CSS3 media query that specifies what rules go with browsers under 400px in width. The next covers everything from 401px to 800px, the next covers 801px to 1000px. You can break it down into any number of chunks. If you want to get super crazy, you can even specify “oretiation : portrait” or “orientation : landscape”. The standard best practice today is to have at least three “breakpoints”, that’s the point at which Responsive kicks in to reformat things. You want one standard style for your desktop site, one breakpoint to respond to a smaller window, another breakpoint to respond to a tablet, and a third breakpoint to respond to mobile.

Now let’s check out another example that’s not just a demo. Screaming Frog makes an awesome SEO spider tool, which we love at SwellPath, and they also have a beautifully responsive site. Let’s see it in action -> Screaming Frog’s awesome website.

We don’t have time to get into this, but you should be aware that there’s also a step up from RWD known as RESS. RESS stands for Responsive web-design with server-side components. I’m not sure if anyone has a proper explanation for why that got condensed into RESS? RE-sponsive web design with Server Side components? Anyhow, what this involves is using responsive CSS in conjunction with server side scripting (think PHP or ASP) to detect the device that’s requesting a page, then deliver a customized code foundation, which then gets responsive applied to it. It’s basically Inception.

The beauty of responsive is that users don’t even have to think about anything we just went over. All they know is that the site looked awesome on every device they’ve ever viewed it on.

All in all, responsive web design gives users the great mobile experience that they expect. It also makes them more likely to stay on your site; to read your content; to convert. Responsive also allows your site to be super flexible, since you only have one code base to deal with. When a new device comes out, you just need to determine if looks good with your current set up or, if it doesn’t, just add another breakpoint to cover it.

However, what interests me more than any of that, is how responsive performs in terms of SEO. As it turns out, it performs incredibly well. In order to illustrate why responsive is so good for SEO performance, let me break down some of the issues we’ve seen in the past with non-responsive sites.

Let’s consider a brand that has a desktop site and a mobile site, like m.brand.com. That mobile site provides a decent experience for most users but the SEO cost is potentially pretty high. Unless you have your SEO completely dialed, you’re essentially giving search engines two copies of the same site to look at. We know how search engines feel about duplicate content and without proper SEO handling, we’re leaving it up to the engines to figure out the association between these two sites and figure out which one makes sense to return in desktop search and which one makes sense to return in mobile search. That usually doesn’t work out so well. In many cases, I’ll see both versions of the site show up in desktop search. So great, you’re competing with yourself.

Another pitfall is that there’s a potential for dilution of link equity. If people are linking to and sharing URLs from your desktop and your mobile site, that means the SEO authority you’re building is being split up rather than being consolidated in one place.

Another one that we see all to often is faulty redirects. Mobile sites usually rely on detecting the user-agent of a device and then redirecting that visitor to the mobile site, but it only works if the device is recognized. In some cases, we see that Googlebot mobile doesn’t get redirected to the mobile site properly, so Google still thinks you just have a desktop site that isn’t usable on mobile devices. Another downside of relying on redirections is that each one adds additional load time and site speed, which is an increasingly important ranking factor.

If you’re stuck with this configuration though, you can still make the best of it. First, you’ll want to make sure that both Googlebot and Googlebot Mobile can access both versions of the site. As a general rule of thumb, you rarely want to tell Google it can’t access content that your users can. Search engines definitely don’t like that.

After you make sure that both sites are accessible, you need to specify the relationship between those two sites, since they’re basically just duplicates of each other. This is absolutely necessary and will save you a lot of SEO headaches down the road. The way we specify the relationship is through rel=”alternate” and rel=”canonical” tags. Whenever Googlebot crawls the desktop site, we want it to know that there’s also a mobile equivalent of whatever pages it’s on. Rel=”alternate” lets us tell Googlebot that the page it’s crawling has an alternate mobile version. The most important thing to understand here is that every page needs to link to its actual equivalent; you can’t just point everything to the mobile homepage.

The rel=”alternate” tag looks like this.

<link rel=”alternate” media=”only screen and (max-width: 640px)” href=”http://m.example.com/page-1″ >

Take a look at that media attribute. Pretty similar to our CSS3 media query, eh?

Now on the mobile side, we want to have a “canonical” tag that points back to the desktop equivalent. Again, this always needs to point to the actual equivalent, not just the desktop homepage. The tag looks like this:

<link rel=”canonical” href=”http://www.example.com/page-1″ >

Broadly speaking, the canonical tag is used to tell Google about pages that are very similar to each other or exact duplicates. That’s pretty much what we’re doing here, but the rel=”alternate” tag gives Google the signal that we have a mobile-to-desktop relationship.

Now I feel like inserting these tags is pretty easy to do in PHP, but if you don’t have the ability to make code changes, you can also add these notations in the desktop site’s XML sitemap. It looks pretty much the same, except you’re adding these tags in bulk instead of putting them in the source code. However, even with this handling, you still have to add the canonical tags into the source code of the mobile site. It sucks, but you can’t get around it. All in all, making a mobile specific site SEO-friendly is kind of a pain.

Responsive web design is a huge step up from having two sites for mobile and desktop.

• Now duplicate content is a non-issue.
• Any links or social shares automatically pointing to the same place regardless of whether someone gave you that link via desktop or mobile; it’s the same site, so no dilution of link equity.
• Page load time is still quick, since we don’t have to rely on redirects.
• Better yet, we don’t have to worry about our redirects not working or having Googlebot mobile end up going to the wrong site.
• Finally, you never have to worry about adding mobile SEO tags into your source code or building out notations in your XML sitemap.

But perhaps my favorite part about Responsive Web Design for SEO is this. It’s what the world’s top search engines are recommending. Now I’m not saying that everything that Google or Bing says is absolute law, but in the vast majority of cases, it really pays off to follow their guidelines.

Search engines have always had pretty clear goals. I don’t think it’s a surprise to anyone that that goal isn’t making sure SEOs have an easy job. Their goal is to provide search results that give searchers a great experience. That way, people keep using their engines and click on their ad placements. Yeah, Google and Bing are businesses. They just happen to strive to achieve their business goals by delighting their users. It’s a pretty brilliant and all-to-often forgotten philosophy.

Anyhow, both Google and Bing have publicly recommended that you use Responsive Web Design if you want to do well in mobile search. And they aren’t talking about this, but I’m seeing tests like this more and more. These were around of a little bit, special notations in mobile search for sites that were responsive.

At SMX West this year, both Matt Cutts of Google and Duane Forrester of Bing agreed that in the next few years, both search engines feel that there will be little incentive for them to return non-responsive websites.

Overall, Responsive Web Design is far superior for SEO than any other mobile experience delivery option. It consolidates link equity, eliminates technical SEO issues, makes the site equally accessible to Googlebot, Googlebot Mobile, and any other variation of Googlebot that may launch in the future, it keeps your site loading quickly, and gives Google the good user experience that they’re going out of their way to ensure mobile searchers get. I could realistically see Google using the responsiveness of a site as a ranking factor in-and-of-itself in the future. The time to go responsive is right now.

Still, no matter how excited we get about RWD, there can be big obstacles to going responsive. For one, it’s a big development cost to re-architect a site’s code base so that it can be responsive. In a lot of cases, it’s going to be easier to just launch a new responsive site than try to fix the existing desktop one. That’s change is going to be hard sell to management or your C-level clients. It probably won’t win you any friends on the dev team either.

I tried to identify the other major objections I hear to responsive, so here are few realities of the responsive conversation.  The first thing that I hear is that, in responsive design, code that isn’t used in your mobile layout still gets downloaded no matter what, because you still need it for desktop. The CSS3 media query doesn’t affect which sections of code actually get downloaded; it just tells the browser how to display that code. So many developers will argue that this is a major flaw. That’s a point we have to concede. It’s a reality of responsive design, unless you’re using RESS to change the code base that gets delivered on a device-by-device basis.

Second, I commonly hear that a downside of responsive is that it relies on resizing images for mobile layouts. Of course, any image that is embedded in a blog post or a news story needs to be of sufficient resolution to look good on desktop; responsive then needs to scale it down. That’s definitely a reality of responsive, but it’s also a reality to a mobile specific website (unless your CMS creates a low-res copy of every uploaded image to use on the mobile site). Overall, I think it’s a valid concern that I can’t argue with.

Third, I’ll often hear that a lot of mobile devices don’t recognize CSS3. I’m not going to say that they’re wrong, because there are plenty of devices out there that don’t recognize CSS3, specifically media queries. However, to me, that’s like saying you should dumb down your site to make sure that it always works on IE6 and IE7, since a lot of people are still using it. I think the more important question to ask is “how much of our site traffic comes from devices that honor CSS3 media queries?” I’ll stake my reputation on it being the vast majority of your site traffic.

Personally, I’d counter all of these objections with pointing out the long term cost of supporting multiple platforms and the business consequences of putting your company at risk of having customers receive a bad experience when they don’t get to the correct site and the risk of having terrible mobile SEO and losing out on free site traffic every week.

If you want to make the case for responsive with some data, take a look in Google Analytics. There’s a default “advanced segment” that lets you see mobile traffic only. Fire that up and check out your reports. How’s your bounce rate for the mobile visitors? What about your pages per visit? How about goals completions and e commerce transactions? Are they comparable to your desktop users? While your desktop site will typically have more engagement, you shouldn’t be seeing 95% bounce rate from your mobile site. That’s bad. Real bad.

Then take a look at the percentage of organic traffic out of the site total that’s coming to your site. Is the percentage of mobile organic on your mobile site comparable? If not, that may be a big issue that indicates some big problems in mobile search. Take those reports to your boss and let the data tell the story.

I believe that responsive design is the future of search marketing. I’m looking forward to the day when mobile search volume becomes equal to or even overtakes what we now think of as traditional, desktop search. Maybe that’ll force the “laggards” to move on this whole “mobile experience” thing.

Yet this isn’t just about the future; responsive design is also the present of search. I see more experiments in Google’s SERP presentation on mobile than I do on desktop these days. They’re putting a huge effort behind optimizing the mobile search experience and so is Bing. Lucky for us, we have the advantage of knowing what they think is best for users. It’s responsive. When we’re looking to improve our mobile SEO, providing what the search engines ask you to provide is a pretty safe bet.

Responsive design makes the web a better place. It makes the web faster and cleaner. It makes the web more accessible, readable, and digestible. Responsive design delights customers and that’s the ultimate for any marketer.

And responsive brings us one step closer to the future. Why? Because it’s exactly that: responsive. Building our sites on a clean and logical foundation, and allowing it’s presentation to respond to browsing conditions is incredibly future facing. How long do you figure we have until we need to optimize for the Google Glass user experience and Google Glass search. How about in-car dashboard browsing once we have self-navigating cars? How about transparent screen, projected image, Tony Stark madness? Responsive web design allows us to respond to the evolution of the web, remain agile, adapt to new technologies.

Yes. Converting your site to responsive is an investment. It’s hard work, but scalable tactics and strategies in marketing tend to require hard work. Stop looking for the quick fix; the plugin, the mobile-specific website; the phone app Band-Aid for a broken mobile experience. We’ve had to suffer bad mobile websites for long enough. They don’t give us the experience we want as users; they don’t give us the results we want as webmasters and marketers.

It’s time to step up our game, go responsive. Through responsive, we can meet the challenge of creating an awesome mobile experience that gives customers what they want. And you know what happens then? We’re suddenly giving search engines the site that they want to return at the top of their search results. The title of this presentation is “Responsive Web Design, Mobile SEO, and the Future of Search Marketing”. Well, I think that responsive web design is mobile SEO and the future of search marketing.

If you missed the presentation and want to relive the magic, check out the entire slide deck below!