Is Adaptive Web Design Or RESS Better Than Responsive Design For SEO?

Kudos to all of you smart marketers for keeping me on my toes. At SES San Francisco last week, I was asked three good questions that I hadn’t heard before and wasn’t really prepared to answer. The title of this post is one of them: When it comes to SEO, is adaptive Web design or RESS (Responsive Web Design + Server Side Components) better than responsive Web design?

If the person who asked the question had phrased it as, “Is dynamic serving better than responsive Web design for SEO?” it would have been an easy question to answer. Unfortunately, with so many new terms being used to describe these modern Web experiences, it’s sometimes difficult to keep them all straight.

It also doesn’t help when authorities in the space use the terms “responsive Web design” and “adaptive Web design” interchangeably when they’re really not the same. Even Google Search serves [responsive Web design] results with [adaptive Web design] results, since “adaptive” and “responsive” are synonyms outside of Web design.

So, what’s the difference between adaptive Web design, dynamic serving, and RESS? Adaptive Web design and RESS are popular design terms for what Google calls “dynamic serving.” Essentially, all use server-side components (as opposed to a client-side component like CSS, which responsive Web design uses) to deliver content to mobile users.

Adaptive Web design, as far as SEOs are concerned, changes to fit a predetermined set of screen and device sizes. When a user requests content from a server, it detects the device that they’re on and serves them separate HTML that is designed specifically for that platform or device. It uses server-side components to deliver this HTML, but the adaptive layouts use fixed break points instead of fluid grids, and the site is typically fully designed for the user agent it detects, rather than only serving different components to users on different devices. One example of adaptive Web design is Screaming Frog’s website, which offers different site designs when you resize the browser.

adaptive web design seo

Screaming Frog’s site is an example of adaptive web design — a type of dynamic serving.

RESS, on the other hand, is responsive Web design with server side components, which uses fluid grids for layouts. it detects the searcher’s device server side and delivers features that are optimized for the user of that device. It’s not a full redesign, but components like giving a scan prices button to users with compatible phones would be one way to utilize RESS. Notre Dame’s new home page serves as a good example of a website employing RESS.

Both of these differ from responsive Web design in that responsive Web design (as Google defines it) is “a setup where the server always sends the same HTML code to all devices and CSS is used to alter the rendering of the page on the device using media queries.” No request to the server is made, as everything is done client-side.

Now that we’re clear on what these similar concepts are, can we say that dynamic serving is better for SEO than responsive Web design?

I know my colleague Michael Martin is a big proponent of dynamic serving and prefers it to responsive Web design or mobile URLs for SEO. I agree that it can be a great solution to a lot of the issues SEOs have with responsive Web design. Namely, it can be much faster with less work, and you can serve components based on the device’s native functionality that you wouldn’t be able to serve with responsive Web design. You can also do it at a single URL, which makes the bidirectional annotations workaround unnecessary.

The problem is, it’s still not Google’s preferred method of smartphone configuration, and there are still workarounds that need to be implemented if you want to make adaptive design or RESS work for SEO.

Namely, Google recommends that you use the Vary HTTP header to let Googlebot know that the site should be crawled by smartphone and mobile Googlebot. This can cause some additional traffic to your server if you have a content delivery network (CDN) like Akamai, as Akamai doesn’t cache different versions of the site based on user agent and will send the traffic back to your servers.

Google has said this should still be a best practice in spite of this, if a webmaster decides to use dynamic serving; but webmasters who do this with a CDN that doesn’t cache different versions of a web page based on the Vary header should be prepared for an influx of traffic to their own servers.

So, there are drawbacks to dynamic serving, as there are to all of the three mobile configurations that Google supports. But unlike responsive Web design, it can load quickly without a lot of work and display a version of the site that is optimized for a specific device, including mobile keywords and features that work in context. And unlike dedicated mobile sites on separate URLs, there’s no chance of Google splitting link equity because of a mobile site. (Although, as I mentioned earlier, the risk is so low that it’s basically a wash in my book.)

So, if you really want to pay attention to the mobile user experience and serve contextually relevant content to better serve your user and your business, yes, dynamic serving through RESS or adaptive Web design (or mobile URLs) is better for SEO than responsive Web design. There are still workarounds for both, however, so if you can make responsive Web design work well for your users and your business (which isn’t easy, as I’ve said many times before), it’s better to do that than adaptive Web design or RESS.

Thanks to the audience in San Francisco for the question. Keep the great questions coming when I see you at the Getting Mobile SEO Right session during the first day of SMX East!

Opinions expressed in the article are those of the guest author and not necessarily Marketing Land.

Related Topics: Channel: Mobile Marketing | Google: Mobile | Google: Search | Google: SEO | Mobile Marketing Column


About The Author: is the SEO Director at Vivid Seats, is an SEO veteran with more than 14 years experience both agency and in-house, and is a thought leader in permission marketing as a columnist and a frequent speaker on SEO and mobile marketing.

Sign Up To Get This Newsletter Via Email:  


Other ways to share:

Read before commenting! We welcome constructive comments and allow any that meet our common sense criteria. This means being respectful and polite to others. It means providing helpful information that contributes to a story or discussion. It means leaving links only that substantially add further to a discussion. Comments using foul language, being disrespectful to others or otherwise violating what we believe are common sense standards of discussion will be deleted. You can read more about our comments policy here.
  • Barry Adams

    You haven’t explained why RESS is better for SEO than RWD. I grant you there may be some UI/UX advantages when you can serve device-specific content with RESS that you can’t with RWD, but that does not indicate a SEO advantage.

  • Bryson Meunier

    RESS is RWD, but with server side components, so the advantages for SEO are small. Nonetheless, I don’t agree that device-specific content doesn’t indicate an SEO advantage when done correctly. If marketers can engage more people with their content, links and shares and organic traffic can’t be far behind. It’s a principle so basic that Google has mentioned it in its SEO Starter Guide: “Creating compelling and useful content will likely influence your website more than any of the other factors discussed here.” RESS by itself has no inherent advantage for SEO, but it gives you more options for contextually aware, compelling and useful content that does.

    Thanks for the comment, Barry. Good to see you outside of State of Digital.

  • Ryan Connors

    Interesting to read the differences between RESS and RWD. I’m glad that these discussions are coming to the front as businesses understand the value of an optimized website experience across mediums and even get into customization based on user personas. Thanks for sharing Bryson.

  • Michael Martin


    As I like to say, RWD is just changing the deck chairs of the ship while Dynamic Serving allows you to actually steer your site through icebergs of intent, since you can actually adjust the HTML. RWD is the same HTML that just adjusts its visual presentation via CSS while Dynamic Serving provides different HTML under the same URL based on the device, which means for SEO…different Title Tag & Metas plus content specific to the device intent.

  • Markus

    You say “Adaptive Web design: When a user requests content from a server, it detects the device that they’re on and serves them separate HTML that is designed specifically for that platform or device.” And as an example for this you mention But there is no server side detection of the device. always sends the same HTML and CSS to the device. Media Queries then manage the appearance of the webpage.

  • Zach @ ReferralCandy

    The only term I was familiar with (prior to reading this article) was responsive web design, and I took it to mean any design that suited the website’s contents to the device viewing it. So I found the notion of adaptive web design and RESS and how those two are different from RWD very interesting. Thanks for the insight.

    Here’s what I understand now:

    RWD = Send the same HTML/CSS for all devices, CSS alters look based on media queries
    RESS = Send slightly different (only alterations, not a full redesign) HTML/CSS depending on the device, CSS alters look based on media queries as well.
    AWD = Send totally different HTML/CSS to suit device (typically fully designed for the specific user agent)

    Correct me if I’m wrong, but it seems to me that RWD is the cheapest to implement (from a technical perspective – only one codebase to maintain) and also the best for SEO (from Google’s perspective). So I’d go with that if the mobile experience for the website does not need an entirely customised experience.

    So I’m curious to find out whether other websites find it worthwhile to do RESS or AWD and why? What kind of websites do they tend to be?

  • Bryson Meunier

    Good point, Markus. Device detection is frequently used for adaptive web design but the key distinction is fixed break points vs fluid grids. Screaming Frog’s site is considered adaptive because it uses fixed break points instead of fluid grids. So server side detection isn’t an essential component of adaptive web design, but it is frequently used. Thanks for pointing that out.

  • Bryson Meunier

    Glad you liked the article. As for cost, RWD is typically much more expensive upfront than the alternatives. This is part of the reason so many web designers love it. If there’s cost savings because of efficiency you won’t see a return for a while. Also, RWD is only preferred by Google for SEO if it’s best for the user. If it’s not user-friendly they don’t recommend it. That said, from an SEO perspective it does make sense to go with responsive web design over these alternatives if you can make it work well for your users and your business.

  • Andreas Mitschke

    That’s plain wrong.

    First of all, web designers are not web developers and from a professional pov, they shouldn’t be neither. However, most designers also qualify for some front-end development, but they stiLl shouldn’t do that. Same for UX architects, don’t throw all these prowess in a single profession, namely web designers.

    Then, a responsive framework is way more cost-effective than serving multiple ressources based upon true adaptive intentions.

    Not just for the creation part, but also when it comes to serving and maintaining different versions of the same content. Imagine, you’ve to provide different types of the same image file, different back-end files e.g. wordpress you’ll need to maintain multiple php files, css files, probably different js files… a responsive framework won’t end up in a huge pile of files instead it’s just about css hide-methods and queries.

    …and Screaming Frog is NOT an adaptive page. It’s using cluttered media queries without a grid, but they do not exchange any data.

    A last word, which should be read by everyone reading this article:

    The actual best method to simoultaneously boost mobile speed, but without a bulk of coding, is to use a responsive grid including an adaptive image solution.

    The biggest problem with responsive designs is that each agent gets served the same data, reconstructed and in case of images just resized, which implies a certain bandwidth load. Mobile devices are meant to used on the go, thus Google wants us to make the mobile experience as fast as possible, which is not working-out when you serve a 600x600px picture just resized to X, where X is different depending on the browser-window-width.

    A server-side pre-render solution like solves this problem.

    Pros for responsiveness+adaptive images:

    - easy to implement
    ( simple CSS queries, almost entirely cross-browser proof )
    - easy to change
    ( one or few files,which entirely let you control the whole appearance )
    - easy on bandwidth, thus faster page speed
    (each 1s of load time = +10% bounce rate)


    - needs maintainance of additional image files
    ( for some solutions (not mentioned php solution )
    - clutters the HTML with additional Tags depending on Agent
    - Media Queries will never perfectly serve “every” mobile and tablet out there, as you need to generalize all those fragmented devices by screen width.

    The best solution, regarding UX PoV, is still the native mobile App.

    Regarding SEO, it’s clear that serving different kind of architecture is not the way to go. I even bet 90% of SEO guys will fail in telling google to crawl the different file sets.

    Either you make it really complicated and go with the App path, which means no SEO impact at all


    take the best-practice and easiest way and go with responsive design and added adaptive images… which might qualify for that stupid RESS term.

  • Bryson Meunier

    Thanks for the comments Andreas. A lot to address here, but not much that mentions SEO. SEO first: You say “it’s clear that serving different kind of architecture is not the way to go” but I don’t know many SEOs at this point who agree with you. Far from clear, at the very least it’s a point of contention with many SEOs like myself and Michael Martin recommending to serve different content based on smartphone and desktop user agents when it makes sense for the search engine user.

    If making a distinction between front end developers, web designers and UX architects was necessary for this discussion I would have done it. However, it’s not. When I mention web design as a profession when it comes to selling RWD it’s only because many web designers are eager to sell the new service. Part of the motivation is to make the web more usable on different kinds of devices, but part of it is financial.

    Screaming Frog was mentioned as an example of adaptive web design by the number one result in Google for [adaptive web design], Techrepublic: If I’m confused, web designers (and I suppose sometimes UX architects and front end developers) are not helping by sharing bad information on authoritative sites.

    Clearly I didn’t invent the term RESS since I linked to Luke W.’s blog where he lists examples of it. If you have a problem with the terminology please take it up with him.

    Adaptive images is only part of the problem with speed and RWD, but that wasn’t part of my article so I’m not sure why you brought it up. You do need to keep in mind, though, that once you alter Google’s definition of responsive web design by adding something like adaptive images you can no longer claim that Google recommends it.

    When you mention cost effectiveness are you taking into account loss of traffic resulting from not being visible for mobile specific keywords or user frustration at an information architecture that’s not designed for them? Most people don’t, unfortunately.

    An ideal UX solution as you mention might be the native app, but this is an article about SEO and as you say the SEO benefits of native apps are nil.

    Clearly we’re not on the same page here, but I appreciate your comments.

  • Peter Hatherley

    I agree compelling thematic content is where you should be spending your energy. Yet many sites do not cover the smartphone field well. Sure, Google does take ease of visibility into account and more specifically well designed information modelling. But Rich Thematic Content (RTC) that utilises a responsive template has a far, far better chance of succeeding than with one that hasn’t .. as for the splitting of hairs on either or, I’m not so sure if it would make much difference!

  • Instalogic Web Design

    That was well explained and really added a lot to the discussion of adaptive web design.

    Calgary Web Developers

  • web design company los angeles

    Interesting to read the differences between RESS and RWD. I’m glad that
    these discussions are coming to the front as businesses understand the
    value of an optimized website experience across mediums and even get
    into customization based on user personas.

  • Instalogic Web Design

    Thank you so much for posting this.

  • Julian Cassin

    It seems some people are narrowing their definitions of RWD or AWD too narrow.

    Google’s own website for example is both RWD and AWD – it is responsive to device rotations in its most basic form, keeping the content centered but also adapts to the device’s browser capabilities ie: turns on voice recognition where supported.

    RWD is usually controlled via media tags if you do choose to use fluid style grids, but doesn’t really have to be. Just because your web-based CLI (Command Line Interface) has a single cell and responds to device rotation dynamically doesn’t make it not responsive – it might want to change the number of horizontally and vertically available characters or re-arrange the menu system.

    Nor are RWD and AWD mutually exclusive. In addition to being able to mix them, they don’t have to be entirely client or server driven. An example is here which shows an AWD entirely client-side (same HTML/CSS sent to devices whether a mobile device or a desktop). There is a server, but it has no impact on the client what-so-ever. The client adapts in multiple ways, multiple monitor support, direct to printer support, multi-tasking ability, screen resolution, voice recognition to name a few. Having researched the topic thoroughly in order to come up with the optimal performing solution for our requirements, ensuring maximum cache hits are achieved (as an example), or minimal server-communication is required – it was found that client-side was the way to go. To load the entire website having previously visited gets 100% cache hits with the exception of the bootstrapper – typically less than 23kb which includes it’s first package of server-side data.

    AWD is definely more powerful, RESS is interesting but why limit it to server-side components? That limitation makes no sense. For SEO, you can always have a dedicated SEO behaviour that is completely separate to the clients – afterall, a search engine is also just a client.

    It will be interesting to see in 5 years time whether web developers generally still opt for one or the other.


Get Our News, Everywhere!

Daily Email:

Follow Marketing Land on Twitter @marketingland Like Marketing Land on Facebook Follow Marketing Land on Google+ Subscribe to Our Feed! Join our LinkedIn Group Check out our Tumblr! See us on Pinterest


Click to watch SMX conference video

Join us at one of our SMX or MarTech events:

United States


Australia & China

Learn more about: SMX | MarTech

Free Daily Marketing News!

Marketing Day is a once-per-day newsletter update - sign up below and get the news delivered to you!