Mobile Technology Showdown
RWD vs Dynamic Serving vs Subdomain
Since the introduction of the so-called Mobilegeddon in 2015, the importance of mobile devices has been constantly growing, and as SEO experts, we have to consider the changing environment. In the mobile first indexing world only websites that offer a good user experience on mobile devices will count for Google. Which means the pages have to ensure mobile-friendliness and efficiency. There are a few ways in which you can introduce mobile functionality on your website. From our point of view, the first and most significant question arises: which mobile technology will be best for your SEO?
Why Make your Website Mobile-friendly?
Whether you’re building a new website from scratch, or redesigning an existing one, in 2018 and beyond you have to consider that mobile devices will play a significant role as your traffic source. And even though the technical parameters of smartphones are becoming better every year, mobile devices will always have their limitations. The most significant one which directly impacts the mobile page design, is of course the screen size and its orientation. If your mobile website is displayed the same way as the desktop one, that will guarantee a bad user experience.
Another thing worth considering is the fact that, according to Google, about 70% of mobile network connections globally will occur at 3G or slower speeds through 2020. Google was constantly putting more and more emphasis on the page loading time, ultimately making it a ranking signal for all mobile users. Which means that you want your mobile page as fast as it can be, even on slower internet connections.
Google Mobile Speed Test will check the performance on a standard (3G) connection…
When designing your mobile website, you have to consider all the above facts. At the same time you should also pay attention to SEO best practices. At first glance, all of this might seem overly complicated, but hopefully my article can clear up some doubts.
The aim is to sum up the basic information about three major mobile technologies, highlighting the pros and cons of every solution. At the end you should have a rather clear understanding which technology would work best for your website. Remember, the mobile first indexing is rolling out, which means the end is nigh for all websites that cannot adapt to the changing environment.
RWD, Dynamic Serving, or Mobile Subdomain? Which is the Best Solution for Mobile SEO?
Generally, there are three different approaches that aim to achieve the same purpose: Responsive Design, Dynamic Serving, and separate Mobile Subdomain. All solutions have their pros and cons, and in regards to SEO, each of the three technologies can be properly optimized for Google. But that doesn’t necessarily mean that all of them will be the equally good choice in terms of SEO.
Mobile Website on a Separate Subdomain
A few years back it was widely popular to introduce your mobile version on a separate subdomain, and even in 2018 many websites are still following this approach. Subdomain means that you will need a clone of whole your website, which will be built up with mobile friendliness in mind. To make your mobile URLs distinct from the desktop ones, you will create a subdomain, most likely by adding the m- prefix to your root domain name. For example, if your domain is www.iloveonely.com, the mobile version would most likely be m.iloveonely.com.
Pros and Cons of Mobile Subdomain
Having a separate code for your mobile website brings one significant advantage: the code can be built starting from square one, while keeping mobile friendliness in mind. As a result you can acquire a website that guarantees a good user experience, as well as high efficiency on mobile devices.
Unfortunately, using a separate mobile subdomain might bring up a number of problems. Since every page of your website will have a literal copy, you will need to implement solutions for preventing the duplicate content issue. In addition, you will have to figure out the way to deliver the appropriate version of the page to the specific user. I’d like to address a few of such questions, which arise relatively often while working with our clients.
Preventing the Duplicate Content Issue
How to prevent Google from indexing both mobile and desktop versions? Should I indicate the desktop version of the page in the canonical link? Will it be enough to prevent duplicate content?
– Anonymous Onely client
The solution is pretty simple, and was described in detail in the Google documentation. Generally, to markup your mobile pages, you need to use both rel=canonical and rel=alternate elements inside the code of your pages.
On desktop, you should add the rel=alternate markup that will indicate the mobile equivalent of a given page. Additional media markup describes the property of a device indicated in the rel=alternate link. Example:
The code of a mobile page should contain a canonical link element, pointing to the desktop (canonical) version of that page. Example:
The markups should be introduced on a page-to-page level. Which means that every page should contain a markup, pointing to its direct equivalent.
Which version should be optimized for SEO? Desktop or mobile?
Having two versions of a website, which one should I optimize for Search Engines? The mobile or the desktop?
– Anonymous Onely Client
The short answer is: both. Google has already addressed this matter in the official documentation, stating that all your main content should be present on both the mobile and desktop versions of your website. The same applies to all structured data and metadata markups. In other words, your mobile version should be a direct equivalent of the desktop one. And you should also remember that when your website will become affected by the mobile first index, Google will estimate the value of the pages by evaluating the mobile version.
How to Point your Visitors to the Correct Version?
What about link sharing? If someone shares a mobile link on Facebook, such as: m.example.com/its-such-a-poor-example will even the desktop visitors be directed to the mobile website? How can we overcome this issue?
– Okay this one we made up
It is possible to serve the appropriate version of the website, according to the user’s device. This can be done on the server-side, by identifying the type of device by checking the User Agent string. However, this technique can be prone to errors, therefore while implementing it, be sure to keep up with the Google guidelines:
All in all, you can see that the subdomain might be a bit tricky to introduce. The truth is that besides the obvious advantage in performance, it really doesn’t offer you as many bright sides as you’d wish. Perhaps it would be wiser to consider a different approach.
Responsive Web Design
RWD page will transform just like Optimus Prime!
The introduction of Responsive Web Design revolutionized the way of serving content, and really improved the UX of mobile users. RWD means that your website will transform, adjusting its layout as well as resolution to different devices. The same HTML code will be served to mobiles and desktops, and the CSS will determine the appropriate way of rendering pages, according to the device.
While designing an RWD website, you have to make sure that it will offer the same functionality on mobile devices as on desktops. It will have to adapt the layout to fit the vertical orientation of the screen (this usually translates to a lot of scrolling) and the main navigation cannot interrupt your vision. The standard solution for this is called a Hamburger Menu.
Hamburger Menu on Onely.com looks so tasty!
You also have to instruct the browser how it should scale the dimensions of the page, depending on the screen resolution. This can be achieved by implementing the “meta name=”viewport” tag” in the HTML code:
This might sound complicated, but if you will follow the best practices for RWD pages, your mobile website should work perfectly fine.
The Pros and Cons of RWD Pages
The majority of websites today use a Responsive Design to manage their mobile versions. It’s not surprising, as such a solution is relatively easy to maintain: you need only one version of every page, and the URL address stays the same (so no worries about duplicate content). Also, if you have only one code for both devices, you will need to implement all metadata and structured data markups only once. A properly designed responsive page should also ensure an equal experience on both desktops and mobiles for users.
All of that seems so bright, but are there any downsides? Well, in regards to SEO I can name one significant downside. Responsive design means that the code will be rather heavy. On mobile, it will have to contain a lot of unnecessary elements which will have an impact on the page loading time. And we already know that page speed matters for SEO.
Your mobile website should be at least as fast as this chicken.
Of course, as SEO specialists we tend to pay a lot of attention to website performance. There are a number of aspects that can be optimized to reduce page load time to a satisfying level. You do have to keep in mind that a separate, built for mobile, version of the code would always work slightly faster.
However, assuming that the performance aspects are taken care of, and considering the easier maintenance and lesser vulnerability to errors, I’d say that nine times out of ten RWD is a better choice than mobile subdomain.
Even if you serve your mobile version from a separate subdomain, it’s an advised practice to adapt a responsive design to some extent. Just to be able to adjust your site to different mobile screen sizes.
I’ve recently found a website that is using PWA on the mobile version. However, on desktop devices it loads as a standard page. The point is, the URL address stays the same. How do they do that?
Anonymous Onely client
Dynamic serving of content means that after the user types the URL, the server will respond by sending the appropriate version of the HTML and CSS, according to the detected device. This obviously means that on the server-side you will have to implement a solution to detect User Agents, just as in the case of mobile subdomain.
While using dynamic serving it is necessary to inform searching bots that the given page contains an alternate version of the code. This can be done by implementing the Vary HTTP Header. The vary header should be sent in a server response to a request and it should look like this:
GET /page-1 HTTP/1.1
(…rest of HTTP request headers…)
HTTP/1.1 200 OK
(… rest of HTTP response headers…)
This way while crawling a desktop page, Googlebot will get information that it can discover a mobile version of the content after switching the User Agent.
Pros and Cons of Dynamic Serving
The obvious advantage of using dynamic serving is the fact that, just as in the case of mobile subdomain, you will have a separate version of the code dedicated to mobile devices. You can optimize it according to all best practices to ensure mobile-friendliness and fast page load. However, contrary to the inferior subdomain approach, if using dynamic serving both versions of the page will share the same URL address. In other words you don’t have to worry about duplicate content issues.
There are no perfect solutions, and Dynamic Serving also has some downsides. Having two separate versions of the code means that both have to be optimized for SEO, and you have to ensure that the same content will be displayed both on desktops and mobiles. However, the biggest problem with Dynamic Serving is probably the affordability. It will be the most expensive among all the mentioned solutions, and also the most challenging to implement. Yet still, it can outshine RWD in terms of efficiency, and it’s still less prone to errors than the subdomain approach.
But what about AMP?
While writing about mobile SEO you cannot ignore the whole topic of AMP (Accelerated Mobile Pages). The technology was introduced by Google in October 2015, with mobile speed in mind. You can recognize the accelerated pages in mobile search results, by a small AMP logo:
The AMP standard is strongly promoted by Google. We published an article dedicated to accelerated mobile pages, and if you’d like to learn more about the library and how it should be used, you are free to visit the official page of the AMP Project.
What’s really awesome is the fact that AMP is a separate technology, and it can be introduced on its own. For example, you can implement AMP functionality on the mobile version of your responsive website. In such a case, your mobile page can be as fast as if it had mobile-optimized code. You can also enable the option to visit a non-AMP version of the page, if the user doesn’t like the AMP design.
Pros and Cons of AMP Pages
Accelerated Mobile Pages are made for speed, and you cannot ignore the fact that AMP has a significant impact on the page loading time. Below you can see a direct comparison in the terms of performance (measured by gtmetrix.com). It’s the same article, but the first screenshot shows a normal RWD page:
And the second one is an AMP version of that same page:
You can clearly see that the AMP page loads way faster than a responsive page! But how is this possible?
The exceptional speed of AMP pages is partly caused by the fact that Google caches Accelerated pages, to deliver them by its own servers ultra-fast. But the real deal is the AMP code.
The speed comes with a cost (some might say a great cost). AMP pages are built by using special HTML, JS library, and CSS code, which are severely restricted to ensure reliable performance. However, the same restrictions are the reason why many devs out there wish the AMP standard would die. In terms of web design and functionality AMP pages might suffer from these limitations, and there is no doubt that many AMP websites look a lot alike. All in all, nobody likes limitations.
Also, AMP pages will have different URLs, like with the subdomain approach. That means the same issues will apply: you have to correctly mark your AMP pages to prevent duplicate content, and all meta data and structured data have to be implemented here as well. However, AMP can be relatively easy to implement, especially on WordPress, where dedicated plugins can enable the AMP functionality.
While not perfect, the AMP standard gives a visible advantage and it’s definitely worth considering. It works especially well on static pages. Also, you don’t have to introduce AMP to the whole website, you can restrict yourself e.g. to the blog articles, or product pages in your e-commerce store.
All the mentioned technologies have some pros and cons and it’s rather hard to pick an undisputed winner. However, it seems obvious that most would agree that there is really no point in choosing a mobile subdomain. Then, how to choose between Responsive Web Design and Dynamic Serving?
I’d say that the choice should be mostly dependant on your budget. And implementation of AMP on the RWD page can be a real game changer here – as it will make your mobile version as fast as it can be with the mobile-optimized version of the code (if you’re able to accept the AMP limitations). After you‘ve made your pick, all you have to do is stick to the survival guide for the post-mobile-first-indexing world, relax, and watch your rankings grow.