Welcome to the Q&A Forum

It sounds like it may be a misattribution issue rather than an actual traffic loss. This article seems like it could provide a (partial) answer. Do the dates you saw the drop align with the dates mentioned in the article?

Hi Michelle,

You should use the 'switchboard tags', the special mobile canonical tag, when you have a mobile page which is a (duplicate) 'mobile version' of a desktop page.

This allows your mobile version to display in mobile search results, and your desktop version to display in desktop search results. It also indicates to Google that the mobile version is a duplicate version designed for mobile devices, rather than being simply duplicate content.

If you have a noindexed desktop page, and don't want the mobile version indexed either, you shouldn't need the canonical, just treat the mobile version the same as you would the desktop version.

If you have mobile-only content, with no corresponding desktop version, you can treat it the same as any other page; you don't need to add a canonical.

Hi,

This is a good question; for now my answer would be no, I wouldn't bother with rolling it out to non-news pages at the moment. Right now it's only for news/article pages, and if you do have any of that content on your site, it would certainly be worth rolling it out to those, but we don't know how it will play out.

Although it is likely that we could see it roll out further in the near future, for now I think you're best off simply improving other areas (including mobile-related things like mobile-friendliness of the UX and site speed) until we see what direction Google ends up taking this in.

Hi Jennifer,

You should definitely index the mobile site. As long as you correctly implement the mobile switchboard tags (which are basically a mobile-specific version of the standard rel=canonical/rel=alternate approach) this will not lead to duplication but rather to the correct version of the page showing up for mobile searches.

There is some discussion around whether or not Google currently has a separate index for mobile search (in any case they are likely to in future if they don't currently) but they definitely have a separate mobile crawler, which spoofs an iPhone user-agent. If you noindex all the mobile pages and redirect mobile user-agents to mobile versions of your pages, what the mobile crawler will see is your whole site as noindexed.

Hi Ruchy, I've answered your questions below:

1. Risks involved:

Most obvious is that you're duplicating your pages and therefore you'll need to make sure you correctly indicate that these are AMP versions of your regular content. There is also a risk that because the page loads in the search result, you'll see less traffic directly to your site - but usually (at least for publishers) this is worth it nonetheless because the impressions are higher (due to being featured in the news carousel at the top of the SERP).

2. the best ways to implement it:

Depends on your existing setup. If you have a custom CMS, get your dev team to build it into the next iteration of the CMS. If you use Wordpress, you can use a WP plugin - Yoast has a good post about this: https://yoast.com/wordpress-amp-part-ii/

3. why it is worth it:

It may not be. Definitely worthwhile for publishers or sites which publish content for Google News. For other types of site, I would recommend checking whether AMP is a common feature for your primary keywords, and decide accordingly. Also worth it if you're seeing a loss of general traffic and suspect it is due to AMP being more present in search. As James notes, it can help with pagespeed but that's not enough of a reason to do it.

4. Are there any specific questions I should ask a potential developer, or information he should be aware of?

Has he/she done this before? Can they provide working examples? Do they understand how to make sure it's showing up as AMP rather than purely duplicate content? Are they familiar with what elements are supported and unsupported? Are they able to also implement relevant structured data markup?

5. is there a way for it it be done for pages that have more than just text like quote forms, sliding headers etc.? Should we only do it for the blog section of our site?

You can add things like video, forms etc but bear in mind that the goal is to be as minimalist as possible, so any sort of fancy design element will likely not be supported. I would focus on implementing on news or other types of content which currently display AMP results in the SERP.

Great question! I love also that you're thinking about how to give support to your clients beyond just answering their literal question -- you're absolutely right that a lot of people are just feeling a bit of anxiety around being "not ready".

My typical response would be very similar to the points you've outlined, and I typically try to offer reassurance that this change isn't necessarily as drastic as it sounds as long as you already have a functional mobile-friendly version of your website. I suspect that part of the question comes from the issue of what Google views as "ready" to migrate versus what the webmaster might feel they need to do before they feel "ready". But as long as your mobile version is performing well and you have all the content accessible and user friendly, I don't think there's a lot to worry about.

I wrote a post for the Moz blog earlier this year to answer some of the FAQs people have about the shift to mobile-first indexing, you might find it helpful either for your own answer to this question or as a resource to share with people who ask you about it: https://moz.com/blog/mobile-first-indexing-seo

As far as I am aware, the association file is just about which paths the app can handle - I think that if you register the root domain and handle all paths then it will handle all paths across all sub-domains (but you should test this).

When you are actually linking individual web pages to the universal page in the app, it uses a fully-qualified URL with protocol and subdomain so should work fine (see this documentation).

Hi Gaston,

In the past I've used MobileDevHQ (now called TUNE) and AppAnnie. MDHQ used to be free I believe, but now is a paid tool. AppAnnie is a paid tool but there are some functionalities available for a free account I think so they may be worth checking out depending on what you need.

Hi Ingolfur,

Are you still having this issue? I'm seeing AMP results when I search with a US IP on Google US and Google UK, but not seeing any AMP results in Google IS. I checked with both Chrome and Safari and saw the same thing though.

Hi bizzer,

Everyone should ideally have a mobile-friendly website, because the percentage of people accessing your site on mobile devices will only continue to increase. And if you already have a Wordpress site, switching to a responsive theme is a great way to achieve that. But...as you note, there are other considerations, such as potentially lost rankings.

Only you know how much of a drop you can afford. It's a short-term sacrifice for long-term results.

Generally speaking, my recommendation would always be that if you can possibly do it, you should. And Miki and Moosa made some good suggestions above for how to minimise the negative impact somewhat. Combined with good technical SEO going into the new source code, you should hopefully be able to regain your position fairly quickly.

To answer your follow-up question: we don't know for sure, but it seems likely that having a mobile-friendly website could be a quality factor, whether now or later. Google have certainly discussed best practice guidelines for mobile, which seems to indicate that a good mobile experience is something which they care about. Apart from anything else, ~60% of mobile users will bounce if they land on a non-mobile-friendly site and go to a competitor, so that in itself will send a negative signal if you have a significant amount of mobile traffic. (and 15-20% isn't too shabby - even if some of that is tablet traffic, a responsive design will provide a better experience for them as well).

Hope that helps!

Hi Niall,

AMP is not the same as responsive design. It is a different format for mobile content which removes even more of the "extraneous" stuff in favor of a streamlined, simple design which Google then caches and displays from within a search result page (without the user ever needing to go to your website to view the content). The primary use case is for publishers to streamline their articles and other content, but AMP can also be used for other types of page (including ecommerce, although this is a newer development).

The pros of AMP include: faster load times, getting your content featured in article carousels, and potentially ranking benefit;

The cons of AMP include: creating separate versions of your mobile pages, removing certain elements to streamline the content, and the potential loss of traffic actually landing on your website.

Eric Enge has just put out a blog post here on the Moz blog all about this topic: https://moz.com/blog/amp-digital-marketing-2018

Great, glad to hear it's working now!

Hi John,

When you say that the URLs have the same structure: do you mean that they are different URLs but organised the same way (e.g. www.domain.com is the same as m.domain.com, www.domain.com/page-1 is the sames as m.domain.com/page-1, etc)? Or is it a responsive site with the same URLs regardless of device?

The primary benefit of a sitemap is for discovery by the search engine crawlers. If you have a responsive site, you don't need a separate mobile sitemap. If you have a different set of URLs for mobile devices, even if it follows the same structure as the desktop site, I'd recommend creating a mobile sitemap.

Hope that helps!

Hi Taylor, great question! I think the first thing to remember is that AMP is something you want to implement alongside a mobile-friendly website, not as a replacement.

AMP pages by nature are faster than the typical webpage and so they should not be affected by this, according to Google's statement: "The “Speed Update,” as we’re calling it, will only affect pages that deliver the slowest experience to users and will only affect a small percentage of queries." They also note that query intent is a very strong signal and so in theory a very slow but very relevant page could still outrank a faster, less relevant result.

My take on this update is that it is a sign of Google starting to focus on making the shift to mobile-first indexing. If you want more info on that, I wrote a blog post here on Moz about it recently: moz.com/blog/mobile-first-indexing-seo

It seems likely that the interstitial is at least contributing to this pattern given the correlation during your test and given the fact that Google has specifically noted that they view interstitial pop-ups (at least certain implementations) as detrimental to the user experience. It is also possible that it isn't the interstitial itself that is raising a red flag as a ranking signal, but some other related issue (for instance, if the interstitial causes a significant page load delay, higher bounce rate, or if there is some rendering issue caused by the implementation of the pop-up).

As you note, if the interstitial is the issue, I would have expected it to affect mobile primarily and desktop less so - so the fact that the result is the opposite is surprising and may indicate a different cause for the traffic dips. I assume that you have compared this data not just WoW but YoY and are certain that the pattern isn't seasonal.

We do know, however, that Google is starting to move in the direction of mobile first in how they rank sites, making the mobile index and experience their primary source for rankings of both mobile and desktop versions.

In any case I would recommend testing a version of your pop-up which is not of a type that Google would consider "intrusive" (see this post for more detail: http://searchengineland.com/google-confirms-rolling-mobile-intrusive-interstitials-penalty-yesterday-267408) or adding a trigger to it (so for instance, don't show the popup immediately but only if the user scrolls a certain percentage of the page, or remains on the page for a set period of time).

Hi Mark,

Is the link part of a navigation menu? If so I don't see any problem with leaving it as 'Home'. If you're linking within the body of a page (for instance in a blogpost), something like 'visit the homepage' or just a branded term should be fine.

Hi,

If you have a separate mobile site with separate URLs, you shouldn't use regular canonicals, you should use the mobile version, called switchboard tags. This will indicate to Google that your mobile version is a mobile version and not simply duplicate content. You do want Google to be able to index your mobile pages as they have a separate smartphone crawler and a mobile index.

To implement switchboard tags:

On the desktop page, add:

and on the mobile page, the annotation should be:

This rel="canonical" tag on the mobile URL pointing to the desktop page is required.

As far as the nofollow question: What I would recommend is that you redirect mobile user agents (which will include the Googlebot for Smartphone) to the mobile version (most relevant page, not just homepage) and redirect desktop user agents landing on your mobile pages to the desktop version. Always include an option to 'view desktop version' or 'view mobile version' so that users can choose to override the redirect. That link should also take the user to the desktop/mobile version of that page, not just the homepage.

Hope that helps!

Hi Pugh,

It sounds like you haven't implemented the rel=canonical tag for mobile. This tag works a bit like the hreflang tag, namely it prevents your mobile site from being viewed as duplicate content and should mean that your mobile URL is displayed in mobile SERPs and your desktop URL is displayed in desktop SERPs.

To implement (for more info see https://developers.google.com/webmasters/smartphone-sites/details

on the desktop page, add:

and on the **corresponding **mobile page, the required annotation should be:

This rel="canonical" tag on the mobile URL pointing to the desktop page is required.

Make sure you are referencing the corresponding URLs (so www.example.com/xyz and m.example.com/xyz, rather than simply referencing the mobile homepage).

Hope that helps!

Hi,

Saijo and Bradley are right in saying that hiding elements on a smaller screen should not be an issue (as it's a correct implementation of responsive design). Bear in mind as well that there is a Googlebot and a Smartphone Googlebot, so as long as the Googlebot is seeing what desktop users see and the Smartphone Googlebot (which uses an iPhone5 user agent) is seeing what mobile users see, it shouldn't be a problem.

The only thing I would add:

If you are going to use display:none to prevent a user from seeing something when they view your site, it's good to include an option to 'view full site' or 'view desktop site'. Also in that case I would question whether you actually need that content on the desktop site at all? Because best practice is to provide all the same content regardless of device.

If it's hidden but still accessible to the mobile user (in a collapsible div for instance) there's no cloaking involved so it shouldn't cause a problem.

As a side note: the Vary HTTP header is really for a dynamically served website (that is, a single URL which checks user agent and then serves the desktop HTML to desktop devices and mobile HTML to mobile devices).

Hope that helps!

Hi Bob,

There's a few key areas which have an impact on app store rankings:

• keywords in title and description
• ratings (therefore make sure you're addressing any issues and responding to negative reviews)
• downloads

You can also translate the title and description into other languages, as this can help increase downloads from other countries (provided your app works internationally, international users will potentially be able to use it even if its primary language is English). And you can promote it on your site; ideally, detect the user agent of your mobile visitors and show them the version for their device.

I'd also suggest testing Facebook promoted posts which allow users to be taken directly to the app store to download your app.

Hope that helps!