Responsive Web Design Business Challenges

Written by Jason Grigsby on

During the Future of Mobile Web summit that dotMobi sponsored, I brought up a series of responsive web design (RWD) challenges that I’ve been thinking about that have little to do with technical implementations. John Leonard from dotMobi commented that he hadn’t read any blog posts about them. Time to remedy that.

Search Engine Optimization

Google, Bing and Yahoo all have different search bots for mobile. Google’s recommendations on how to make sites mobile friendly are all based around building separate sites and then ensuring that the Google mobile bot is redirected to the mobile version. Matt Cutts has talked about this in a video answer and Google has gone so far as to describe how you should redirect the Google mobile bot in some detail.

What does this mean for sites using responsive web design? Honestly, I don’t know. Nor does anyone else it appears. There is some question about whether or not mobile SEO is even worth pursuing.

But it is worrisome. Google recently announced that mobile website optimization now factors into mobile search ads quality. I’ve seen no indication that Google is considering responsive web design in its definition of mobile optimization. The announcement linked to several case studies and articles illustrating separate sites as the approach.

This is probably a problem with the search engines and not with responsive web design as a technique, but if a company relies on search engine traffic for revenue, it likely won’t matter who is to blame.


There’s been a lot written about the difficulty of incorporating advertising into responsive design. Most of the focus has been on the fact that ads aren’t designed to be responsive breaking responsive layouts.

But there is another more structural issue: sometimes advertisers just want to advertise on one form factor and not another. App developers who want to drive app store purchases may not be interested in advertising on desktop. An advertiser interested in location-based advertising is also unlikely to consider responsive advertising desirable.

Will responsive web designs be able to participate in the growing mobile advertising opportunity?


Most web analytics tools that support mobile provide an option to use a server side way of tracking instead of tracking via JavaScript. This is offered because many older devices either don’t support JavaScript or support it so poorly that using JavaScript-based tracking code is problematic.

Bryan and Stephanie Rieger have talked about how in their experience switching to the server-side code will show a lot more mobile traffic from a wider variety of devices than if you stick to the JavaScript version.

The problem is that you can’t run both the JavaScript and the server-side (mobile) variant on the same page. The analytics vendors recommend using the server-side code on your mobile site and the JavaScript one on your desktop site because the JavaScript version has a lot more data and features than the server-side one.

Sites using responsive web design will need to choose between more accurate data about the total mobile traffic (server-side tracking code) or deeper information about a small set of visitors (JavaScript tracking code).

Content Delivery Networks (CDNs)

On a responsive web design that takes care to provide only the assets that are appropriately sized for the device requesting the page, the images will vary based on the device. This causes problems with content delivery networks that have become accustomed to being able to cache a single asset for all devices or at worst caching a desktop and a mobile version of the asset.

As Ronan Cremin put it, CDNs may now need to cache different images based on the entire spectrum of devices accessing a site. FWIW, depending on how they are implemented, this can be a problem for separate sites as well.

One way in which RWD does not resemble the transition to standards

The move towards responsive web design has been compared by many to the changes that happened when web design went from being table-based to using web standards and CSS layouts. The Boston Globe’s new site has been compared to the impact that the ESPN and Wired redesigns in proving the value of web standards.

It may be that my faulty memory, but I don’t remember a similar list of potential drawbacks from a business perspective to making the change to CSS-based layouts. If anything, things standards-based layouts had great business benefits because of the increased semantic markup leading to better search rankings and the leaner code helping with page performance and bandwidth costs. Yes, like responsive web design, retraining staff and changing infrastructure could be a major undertaking, but there wasn’t concern that making a change would negatively impact search rankings or make analytics more difficult.

And I honestly don’t know how big of a problem any of these things are with the exception of the analytics problem which seems clearly to be a pickle. It may be that search engine rankings aren’t impacted at all. But the fact that we don’t know seems like something that should be sorted out and considered if those things are critical to the success of a given project or client.

And to be 100% clear, I’m not saying people shouldn’t do responsive web design. Even if you were to build separate sites, you should still do responsive web design for the separate sites.

I’m simply saying these are challenges and concerns that I don’t think we’ve currently got good answers for.

Jason Grigsby

Jason Grigsby is one of the co-founders of Cloud Four, Mobile Portland and Responsive Field Day. He is the author of Progressive Web Apps from A Book Apart. Follow him at @grigs.

Never miss an article!

Get Weekly Digests


About analytics tools, StatCounter offers HTML with script and noscript tags. Of course that begs the question of how many mobile browsers will load the JavaScript and then be unable to process it properly.

One of my takeaway of the event is that it is time for analytics tools developers to review their scripts and make them more “responsive”, i.e. load a basic script run it and then decide what else they want to capture about the device. No point in monitoring touch events if the device does not support touch.

Could device detection vendors address the analytics issue with data more nuanced than JS:true/false? eg: supports_ga_js:true/false

Forgot to mention in my comment that my query about device detection vendors was largely in relation to the analytics queries.

Luca had entertained the idea of tracking jQuery support in WURFL, but I wasn’t a fan of the idea. Software moves too quickly and support is rarely binary in that even if it does work, it may not work with sufficient speed.

But I do think there might be a place for an analytics provider to use a device detection database and provide the code as a service. This is how it might work:

* Browser visits Acme Corp web site.
* Acme Corp web server makes a call behind the scenes to XYZ Analytics provider’s web service and passes the user agent string of the browser making the request.
* XYZ Analytics provider returns either a binary answer that it should be handled server-side or using JavaScript or better yet returns the best code to run for that particular device.
* Acme Corp builds the page and delivers it to the browser.

My assumption is that the JavaScript would be constructed in the manner Andrea describes above so it is as light-weight as possible. Putting this in the hands of the analytics vendor instead of a device detection vendor makes more sense to me because they are the ones who can maintain information about support as the versions of their tracking code changes.

But all of this is just wild conjecture at this point. The analytics vendors have a tough challenge here because of the diversity of capabilities in the devices and the first load problem. Other solutions might get away with having a less than optimal first load, but because of the importance of bounce rate as a key measurement in web analytics, that won’t be an option for analytics providers.

FWIW, I’m pretty sure most analytics providers are already using some form of device detection simply to help build meaningful reports.

I like the idea of relying on the analytics vendors – it’s a surprise Google haven’t already done so given the emphasis they are putting on mobile (eg with the GoMo initiative). Analytics vendors could use the first back end request (carrying the UA string, IP address and a unique pageview ID from the site being visited) to validate their compatibility profiles by sending back the JS version and checking whether a corresponding pageview is recorded via JS. Extra work for sites integrating the analytics package, but worth it for those who care.


Jason, a great post as always.
SEO for mobile is a real mess. Still early. However, I did a deep-dive into this a while back before writing a blog post about it, and to conclude; Mobile First SEO is the answer to all SEO. Mobile is bringing so many new aspects to search, and as we see for web design and other aspects of online, mobile is now pushing the limits and desktop are following. So whether you are doing SEO for mobile or desktop, RWD or mdot, do mobile SEO first.
Regarding CDN, I have been working closely with some CDNs to find solutions for this. RWD-ish approach seem to be a step in the right direction. Put simply, in RWD the markup can be static as most of the adaptation has moved into already static resources like css and js. Images however, still an issue, and best practice will differ from case to case depending on traffic, picture use etc.
I am sure we will find solutions to this, but I doubt they will be based on client side magic only.

I find the Matt Cutts video mildly alarming.

Most sites get the majority of their traffic from search and the bulk of that traffic is Google. So SEO is very important.

I get the sense that Google is advocating an m.domain and split sites. Though he doesn’t flat out state that this methodology is a requirement, he strongly urges it as a “best practice”.

I would like to try and dig into this and what the ramifications are for a RWD site. Since the site has the same url’s, is this a problem to serve up the same url’s to both Google-bot and Google-bot-mobile? Is it interpreted as simply not having a mobile site? Will that, in a way, penalize a site?

Thanks for the post, I hadn’t given much thought to Mobile SEO, especially as it impacts RWD sites. This is something I will have to research.

Good post Jason. A few thoughts from experience:

– If your mobile site and desktop site have the same URLs & domain, Google can tell the difference if you’re using server-side techniques to send back different HTML & templates. If you’re using RWD, it can’t. I tested this by searching for sites on google on my iPhone and looking at the “site screenshot preview” — the server-side sites shows the mobile version in the preview, while the RWD ones showed the desktop version

– For analytics, we’ve been running dual analytics (client-side Omniture and server-side log processing) for one of our largest sites, and the discrepancy is only around 4% between the two. The client-side does miss a number of minute outliers and barely-used older devices, but IMO client-side analytics may be acceptable for mobile sites if the 4% loss of your outliers is compensated by improved analytics tools and reporting on the remaining 96%. Further, the 96% group includes the users who use the site more, who are more invested in newer devices and mobile web, and generally more driven. I would postulate that you’ll see more conversions and activity on a per-user basis in the 96% group than in the 4% group.

Anyhow, see you guys tonight?

– Ben

@James, Google has stated that having content on duplicated on a mobile site will not cause a duplicate content penalty. So at least there’s that. 🙂

Great post, Jason, good portraying of business challenges that should be solved via technical means.

For analytics, the solution I’m sold on is to use two analytics solution, as suggested by Ben. You’ll spend most of your time dealing with the JS data, but can use the server-side piece to validate you’re not missing too much of your traffic.

For SEO, is it possible RWD actually offers an advantage by reusing the same domain? using mdot and www sub-domains likely splits the authority of each sub-domain, even when they point to the same logical content. For instance, if some mobile sites link to your post on your m. domain and other desktop sites link to it on your www. domain, they may not all contribute to the same pagerank.
More importantly, if you’re trying to carry over your “weight” from your (more broadly used) desktop site into your mobile site, it’s possible RWD will actually help that cause.

Like everybody, I’m only guessing on how Google does their voodoo, but it’s possible it’s working in favor of RWD in some cases.

Hi Jason,

great to hear you made it back from Dublin in one piece. Regarding SEO, it could even be worse than just not telling the difference between mobile and desktop site – you could be penalised if you use alot of the display:none. Bots could construe that as a masking technique to cover up keyword laden pages built for search engines. I have my best SEO spies on the case to confirm this.


I agree with Bryan Rieger that responsive web design starts on the server. Most of these issues listed here can be solved by pairing server-side device detection with responsive web design. I believe this hybrid responsive web design approach is the next logical step.

Hi, i came here, using a mobile smartphone browser, from reading your book on head first mobile, but am quite disappointed that this site does not practice what it preach…. it is not based on responsive Web design…not optimized for mobile at all…

Let’s discuss your project! Email Us