General Manager of Perficient, Eric Enge, explained how to construct a mobile-friendly SEO site with good UX during the “Mobile First Indexing & Mobile Friendly SEO” session at SMX West. Attendees wanted to know about page speed, ranking, interstitials penalties and how SEO for the mobile-first index is different from traditional SEO.
Doesn’t designing a responsive site to the best of the search engine guidelines do away with building a site for “mobile first?” Aren’t we just building “sites” now?
Enge: It is true that with a responsive site you’re seemingly building a single site. But, that’s not entirely true. Most likely, you’ll be creating three different sets of style sheets. These enable you to deliver a different version of the site for desktop, tablet and smartphone users.
How you manage and display information within these style sheets is actually very important. For example, your content font size may be too small, or links too close together so they are not easily “tappable.” You may also want to take large blocks of text content and implement tabs, accordions or drop down boxes to manage how they display on a smartphone device.
So there are many things that still need to happen to be mobile first. Simply being responsive is not enough!
In the case of a dedicated mobile website, passed in mobile-first, is it relevant to keep canonical from mobile to desktop as usually done? And do we change the instruction (from mobile to desktop)?
Enge: You should still leave the rel=alternate and rel=canonical tags in place. I think it’s still useful. However, Google has stated many times there is no need to reverse them in the mobile-first world. From their perspective, while they could ask webmasters to change the direction of these tags, the reality is that it would take publishers years to switch them correctly.
In case all our desktop pages are not available in mobile, do you think it is more relevant to create them in AMP instead of a mobile version?
Enge: You can create pages “natively” in AMP. That means you can have your mobile pages simply be in AMP instead of having traditional HTML/Javascript pages.
How do you balance user experience with your statement that you need to have the same amount of content on your mobile site as you do with your desktop site? Google says it values the experience of a user and a content overloaded mobile page can kill that and potentially decrease your conversion rate if they are swamped in text.
Enge: Let’s look at a scenario contrary the one that you outlined. Imagine that you just learned you have diabetes. Would you be looking for a web page that has four sentences of content and a way to buy their diabetes pills? Or would you prefer as much information as possible in order to learn as much as you could about it?
The point is that the idea that “less is more” on web pages is not always true. In fact it’s often not.
Another example: A user searches for a “Ford Focus.” The right thing to do to have a page full of listings and show only the year, the mileage and the price. But what if they want an S Sedan, SE Sedan, SEL Sedan, or Titanium Sedan? Do you think the color matters? How about the powertrain The exterior options? The interior options? What about the accessories? I think you get my point. Users WANT choices.
At a more fundamental level, if you have a desktop page that offers a Ford Focus SEL Sedan with power heated exterior mirrors at 36,000 miles from 2015, and the user searched that specified the year and the desire for heated exterior mirrors, the desktop page would show up for that search.
However, if the mobile version of that page does not include the mirror information and the year information after a user performs the same search, there is no way for Google to know that you have a vehicle that meets that need. That means you won’t show up for that search.
So yes, you need to include that information. What leaves you with is a CX/UX challenge. Winning sites will present designs that offer the same level of information and use design to make for a great mobile experience.
For the sites that you audited to see desktop vs. mobile, were they m dot sites or responsive sites that had the huge discrepancy in desktop vs. mobile?
Enge: During my presentation at SMX West I showed sample data from sites that used subdomains for their mobile sites. For example, one of those sites had over 700 pages on the desktop version of their site, and the mobile version of their site had only three pages. What this illustrates is that many sites that use a subdomain for the mobile version of their pages have large differences between their mobile and desktop site.
It’s OK to use a mobile subdomain if that’s your preference. But make sure you invest the time to make sure that the site is equivalent in content to your desktop site!
You mentioned Google penalizes interstitials. Has there been any widespread impact to site rankings with the implementation of GDPR in the EU and potentially with the California Consumer Privacy Act, since many sites need to have an immediate display and acceptance of cookies?
Enge: I have not seen any indication that Google has made GDPR and the CCPA – and whether or not your support it – a ranking factor. Over time they could potentially do that, but I’m not sure they will.
Are interstitials that pop up but disappear as soon as the user taps out of it, ok? Or are all mobile interstitials bad? (Working in the multi-family/apartment housing industry for context.)
Google’s main problem with interstitials is if they interfere with the user getting the content with the initial page load. So an interstitial that is in the way of a page load would be a problem for Google, even if it was easy for the user to make it go away. A more progressive way to handle this would be as an interstitial that pops up only when the user moves the mouse cursor towards the address bar of the browser or towards the “x” to close the window.
Which is better – client-side rendering or server-side rendering in regards to speed and ranking?
Enge: I believe there are a few factors that impact the answer to this. The two most important ones are the memory and speed of the web server, and the memory and speed of the client computer. That said, client-side rendering as done by most single page applications will generally be faster after the initial page load. This is because key components of the site are already residing on the client computer and don’t need to be downloaded again.
Angular JS question, you had mentioned that prerender IO could help with indexing, is that similar to Phantom JS?
Enge: No, they are different. What pre-rendering does is take a web page that contains Javascript and execute all those instructions to create the full rendered page exactly the way that a user would see it. That full rendered web page is stored separately. When Google comes to see the content of the page, it gets delivered in the pre-rendered version instead of having to try and execute the Javascript to render the page.
This is very helpful because Google can’t always execute all the javascript successfully, and that can mean that it won’t otherwise see all the content of the web page.
In contrast, Phantom JS is just the way to simulate a web browser in your own programs. So you can use it to attempt to render pages, whereas with prerendering we’re trying to save Google from having to do that.
If your site is an example being mobile indexed because it is mobile indexing ready, but is not mobile friendly (i.e. responsive, but won’t be a good consumer experience), will it be penalized in search rankings?
Enge: It could be. It depends on just how bad an experience it is. But for example, if you have a page where all the links are not tappable, the site might be pretty well unusable on mobile. As a result, it may be a poor page for Google to show in the search results.
We have both non-amp and AMP pages on our website. The non-AMP page is still receiving mobile traffic based on Google Analytics, is it okay? How can we prevent this?
Enge: Yes, this is OK. If the percentage of traffic to the non-AMP pages is high (greater than 25 percent) it may mean that Google is not confident of the quality level of the AMP pages. That may be something that you want to investigate. But, I have not yet seen any sites where the AMP pages get 100 percent of the traffic.
On the case study, what is it about AMP that would lead to improved metrics that wouldn’t appear to be related to page speed (ex session time)?
Enge: I think the primary thing it would be page speed, but not as a direct ranking factor. Users may enjoy the lightning fast and it may make them have far engagement with the site. There may be some aspect of that which Google sees as a ranking signal. That would make the speed an indirect factor. It’s not the speed of the site that Google measures, but the other aspects of the user behavior that improve because users like faster sites.
Even after mobile first, does Google still keep an eye on the desktop version?
Enge: Yes, Google has said that they will still look at the desktop version of a site from time to time. However, the primary source of information Google will use for ranking the site will be the mobile version.
What is considered fast and “slow” when it comes to analyzing your page speed results from Google PageSpeed Insights?
Back in 2010 Google released a YouTube video with Maile Ohye where she said: “Two seconds is the threshold for ecommerce website acceptability… At Google, we aim for under a half second.” Sadly, most of the web has not gotten any faster since then, so two seconds is a good initial target to shoot for.
About The Author
Wendy Almeida is Third Door Media’s Community Editor, working with contributors for Search Engine Land, Marketing Land and MarTech Today. She has held content management roles in a range of organizations from daily newspapers and magazines to global nonprofits.