Welcome to the Q&A Forum

Hi JH,

Typically, collapsing lengthier content on a mobile site (with an option to expand/view the content if desired) in order to improve UX is not considered an issue for Google. However, anytime you're using JS, there's a risk that search engine crawlers won't be able to see what you're doing. You may want to test with JS disabled in your browser to get an idea of what they might be seeing otherwise.

What is the reason for the length of the content at the top of the page? Are you creating that content for users or for search engines? I'm guessing it's not really for users if you're auto-scrolling them past it? This is often something that Google can spot and discount the value of.

I would probably recommend (if possible) a "collapse and expand" approach to lengthy content at the top of the page, rather than autoscrolling down to the products. Show the beginning of that content and offer a "click to expand" if users want to read the full text. You could use JS for that expand and default a non-JS experience to simply display the full content, to ensure that search engines do see the full text. Or if the content includes images, consider removing the images or shrinking them for the mobile version of the site. You may also want to test shortening the length of the content on some of your pages and see whether this impacts performance in one direction or the other.

Hope that helps!

From my understanding of mobile-first indexing, your mobile site will become the primary version Google crawlers see when they are looking at your website. So in terms of the impact of hiding the breadcrumbs on your mobile site, Google will see that you've hidden them and may or may not see them on the desktop version because they may or may not bother to crawl the desktop version.

My question to you would be - what value are you seeing from the breadcrumbs on desktop? Can you check your analytics data to see whether users are using these breadcrumbs for navigation? Do you mark up your breadcrumbs with schema to allow them to show up in rich snippets? If the breadcrumbs do not currently add much value to your users and if they don't serve an SEO purpose, you may not need to bother including them on mobile. On the other hand, if you know that they add to a better UX, you may see a benefit from adding them to the mobile version of the site. This is because Google likes to reward sites with a better UX for mobile users. If you are using them more for search engines to have easier crawl access, I would suggest revisiting your site structure more broadly to ensure that no important page is further than 3-4 clicks from the homepage; and/or ensure that you keep your sitemaps up to date with all important pages and submit in GSC and BWT.

So glad if it's useful!

Hi Rajesh,

Based on what you've described, it sounds like a desktop PWA could be a good way to go! But I would avoid hiding any content from Google crawlers. Instead, check out these articles for some guidelines on how to optimize a PWA site for SEO:

• https://moz.com/blog/introducing-progressive-web-apps
• https://searchengineland.com/google-progressive-web-apps-mobile-experience-seo-259866
• https://www.keylimetoolbox.com/news/technical-seo-progressive-web-apps-pwa-javascript-ajax/

Also, be aware that PWAs are not supported by all browsers, so before you go forward with that approach and ditch a regular website, make sure you look into what browsers your customers are using and ensure that all browsers which are used by a significant percentage of your audience have a supported experience. Hope this helps!

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

Hi, as long as your website is properly optimized for mobile SEO (for instance, if you use dynamic serving for the images, make sure you include the Vary-HTTP header to let Google know that you're doing that) using the same descriptions etc across all versions shouldn't cause any issues. You can also feel free to optimize each version differently if you discover (for example) that users use different search terms when searching for images on a mobile device versus a desktop.

Bear in mind these are images, so you'll want to optimize for the image content, not the target keyword of the page that the image appears on.

Hope this helps!

Istvan has given some great advice here - one other thing I would add about the gibberish URLs though: especially with the format of these, it's possible that the site may have been the victim of a hack.

Make sure you get the site scanned for malware or other hacking activity and going forward have a security expert ensure that the site is secure (especially if it's using a platform like Wordpress which is vulnerable to hackers).

Roman has covered most of the bases with his answer, so I won't retread old ground! But one thing I will note - my understanding is that with mobile-first indexing, content which is default-collapsed (to minimize clutter) won't be discounted. So if there is content you want to have on the site but the long-form nature is making the mobile experience feel cluttered, consider including it in expandable accordion style sections or similar. I would not recommend leaving it out altogether as Googlebot may no longer crawl your desktop site at all and all that content you add to the desktop site only won't give you any benefit.

Hi Robin,

Nigel has offered some good advice here - the one thing I would also add is that you may want to set up mobile switchboard tags to make it clear to Google that the desktop version is the canonical version for PCs and the mobile version is canonical for mobile.

See more info here: https://developers.google.com/search/mobile-sites/mobile-seo/separate-urls#annotations-for-desktop-and-mobile-urls

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

Hi Judd,

If you are only hiding these elements on the mobile view, this shouldn't cause an issue from a rankings perspective. You will want to make sure that they can access your CSS file (sometimes CSS files are blocked from crawlers).

It is possible that having it hidden will mean they discount that content slightly for the mobile version, but as long as they know it's a mobile version of the desktop site they will primarily take the desktop signals into consideration when it comes to rankings (with a small boost for mobile-friendliness in the mobile SERPs).

Once the mobile-first index rolls out this will change but they have stated that with mobile-first indexing, hiding content for space reasons won't negatively impact how they weight that content, so that shouldn't affect your approach practically speaking.

Hi Allison, any updates on this?

From my understanding, it is possible that Google is not indexing the mobile versions of pages if they are simply corresponding to the desktop pages (and indicated as such with the rel=alternate mobile switchboard tags). If they have that information they may simply index the desktop pages and then display the mobile URL in search results.

It is also possible that the GSC data is not accurate - if you do a 'site:' search for your mobile pages (I would try something like 'site:domain/m/' and see what shows up), does it show a higher number of mobile pages than what you're seeing in GSC?

Can you check data for your mobile rankings and see what URLs are being shown for mobile searchers? If your data is showing that mobile users are landing on these pages from search, this would indicate that they are being shown in search results, even if they're not showing up as "indexed" in GSC.

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

Hi Willie,

Is your homepage showing up for other keywords? Are you sure it's been indexed? Make sure you haven't accidentally blocked the homepage from crawlers.

Even if it is in the index already, now that you've made these updates to the homepage you may want to resubmit it to the index in Google Search Console using the Fetch and Render tool.

Also remember that these things can take a little time to update.

Hi romaro,

From my understanding, using these tags as part of a mobile XML sitemap is not necessary and in fact, Google don't recommend having a separate mobile sitemap: https://www.seroundtable.com/google-mobile-sitemaps-20137.html

Instead, for a dynamically served site, the important things are:

• Use the Vary HTTP header to signal your changes depending on the user-agent.
• Detect user-agent strings correctly.

You can read more about Google's guidelines for dynamic serving here: https://developers.google.com/search/mobile-sites/mobile-seo/dynamic-serving

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.

Hi Gareth,

Whatever schema.org markup you're using on that page, you should have the option to include an "image" property to define the image. Hard to get more specific without seeing the page unfortunately. But maybe check out the Schema.org list of recognized types and see which feels like the best match for the content on this page (although as a rule, category pages are a little tricky - usually you'd be using product or article markup on each individual item in the list, so I'm not sure where an image would fit into that).

Hi Gareth, you can certainly use Schema.org markup to suggest a thumbnail image for a SERP - could you share a little more context around the type of result it is for? (e.g. a product page, video thumbnail, etc). If you're comfortable sharing a screenshot that would also be helpful.

Hi Micey, Roman's overview is good, if you want more detailed explanations and recommendations I suggest reading Cindy Krum's 3 part series on her MobileMoxie blog:

• https://www.mobilemoxie.com/blog/understanding-mobile-first-indexing-13-immediate-impact-seo/
• https://www.mobilemoxie.com/blog/understanding-mobile-first-indexing-23-long-term-impact-seo/
• https://www.mobilemoxie.com/blog/googles-mobile-first-architecture-options-for-seo/

Hi Micey,

Is there some additional info you're still looking for? The resources from Martin look pretty comprehensive to me, so I would second his recommendations.

You can also just use Chrome DevTools for emulating different screens as a first step (although you'll always want to do real device testing as well).

Hi James,

Great question! My two cents would be as follows:

Firstly, I'm assuming that there is no way that you can make the responsive pages show up with the same domain as the current non-responsive site.

I'm guessing that you are building these pages on a different platform than the main site, but it is possible to use multiple platforms on a single domain (for instance, many websites build their blog on Wordpress and their main site using something different) - so I'm curious about why in this case you are choosing to make it a totally separate domain.

Assuming that this is the only way to do it, my first question would be: are these pages something that would be indexed normally on the main site? You mention they are 'Action' pages - search engines may not need to index transaction pages, for example, where the only purpose is to submit a payment or sign up for something. Unless you also expect these pages to rank as entry pages, but if users are navigating to these pages primarily from a different landing page, they may not be relevant to search engines at all.

If this is the case, and you are still concerned about appearing to send users to a different website, you could consider making the donate button to these pages initially link to a page on the existing domain (like www.maindomain.org/secure) which could then immediately redirect to the secure version. You could nofollow this link and block the transaction pages on the other domain from search (I usually see no reason to have purely transactional pages indexed, but I may be missing some context in this case.) However, this may run the risk of looking like you are trying to do something sneaky with redirects.

You could also include a note on the first page (the one the user is on before being taken to the secure site), next to that 'donate'/'signup' button/link that states "by clicking this link, you will be taken to our secure platform at 'domain.com' to complete your donation/signup".

I do like the idea of including the name of the charity in this secondary domain if possible, to help make it clear that they are connected. You could optimize the pages' meta data to include the name of the charity as well.

I don't believe there is a negative consequence (generally speaking) to sending a user off-site - unless you appear to be running some sort of 'doorway' page scheme, or using sneaky redirects to show Google one thing and the user something else. My one caveat: I'm not sure what you mean by "booting" the user- I could see it potentially seeming problematic if the user is automatically sent somewhere without choosing to navigate to the other domain...it could even fall under the category of 'malicious behavior'. But as long as the user is choosing to click on a link that takes them to a 'donate' or 'sign up' page, even if it's hosted on a different domain, I don't see that creating a major issue for Google.

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).

Thanks for this!

2 things:

1. I'd suggest that if Site A republishes duplicate (syndicated) content from Site B and references Site B as the original source, you might want to consider simply blocking that content from search engines (on Site A). This will ensure that Google doesn't penalize for dupe content and also will prevent them from seeing the critical errors on the Site B AMP pages.

2. Overall I've tested your example page and couldn't find anything seriously wrong, but one thing I did notice was that in your structured data markup (NewsArticle) you have an error:

On the page: http://m.businesstoday.in/lite/story/reliance-jio-is-preparing-new-tariffs-and-exciting-offers-for-you/1/249662.html

You list "mainEntityOfPage" as "http://m.businesstoday.in/"

However, the Google guidelines state that "mainEntityOfPage" should be the canonical URL of the article page: https://developers.google.com/search/docs/data-types/articles#type_definitions (in this case: http://www.businesstoday.in/sectors/telecom/reliance-jio-is-preparing-new-tariffs-and-exciting-offers-for-you/story/249662.html)

Although the markup does pass the structured data testing tool validation, it is possible that this is breaking the structured data and using NewsArticle markup is something that Google states you must have implemented to feature in the News Carousel.

If fixing this doesn't help, I'd suggest cleaning up the non-critical errors next to see if that fixes the issue.

Hi Jacob,

Is the mobile version significantly different in terms of content? If they're the same, I wouldn't worry too much about this. Google's priority seems to be on a good mobile experience anyway, so I'd be more concerned if this was happening in the opposite direction. But as long as they're correctly seeing that you have a mobile-friendly site (your site looks beautiful by the way!), and they're able to access all of the content regardless of user-agent, I'd consider this a low priority fix.

That said, if you haven't already, I'd suggest checking out your mobile vs desktop rankings (especially if you know when the issue started and can do a before and after comparison) and see if there's a significant discrepancy there. Of course there will always be minor differences in mobile vs desktop but if it's a big difference that could be a sign that this is causing real issues and should be fixed asap.

Hope that helps!

Great, glad to hear it's working now!

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, the first thing I would note is that a responsive design means you have the exact same content on the desktop and mobile versions - if you're considering serving different HTML to different users on the same URL this would be considered dynamic serving and you'll want to make sure you add the Vary-HTTP user agent header.

To answer your other questions:

1) Do you think there is any SEO value in the desktop footer links?

There is certainly some value, although how much is debatable - that would depend on how many total pages there are on the site, how much other content you have, and whether these pages are linked to elsewhere etc. You could test it by removing a handful of the links temporarily and see whether those pages see any sort of negative impact over 3-4 weeks. If you do this, make sure you do link to those pages from somewhere else on the site so they don't become orphaned.

2) Do you have any suggestions about how best to include these 60-odd links in a way that works for mobile?

I would suggest either leaving them in the footer in a collapsible div to help keep a clean look (maybe with your 5 or so most important links visible and a 'see more' option), or moving them to a hamburger menu on a mobile view.

Hope that helps!

Hey! I have a few questions first of all, just to clarify the situation.

1. has Site A always published the articles from Site B? How do you currently handle the duplicate content aspect?

2. Has Site A's valid AMP content previously performed as expected, and this is a new issue? Or have you always had this issue?

3. Are you verified in Google News?

4. Are you seeing errors in Google Search Console for any of these AMP pages?

Hi John,

Are you still seeing the 'not mobile friendly' warning in the SERPs? I checked just now and wasn't able to replicate.

I think this is great! I agree with all of your thought process. I wish all migrations could be this thorough

It looks like you posted this question a little while ago though, so if you've already started the process I'd love to hear how it's going!

Hi Anouk,

I don't see any reason why you couldn't use the generic Article (rather than NewsArticle) markup on your informational pages, if that is how you want Google to view the content (as an informational 'article'). I'd be cautious with it if you want the content type to be seen as something else by Google, and/or if it is very long-form, heavily resourced content.

You may want to test it on some of your info pages and compare what happens to the pages with the markup vs the AMP versions that don't include the markup. Hope that helps.

Hi George, I'm not sure which image you're referring to? A video snippet/recipe snippet type image? You should be able to suggest a 'featured image' in the structured data markup for those, but Google is not required to follow that suggestion.

With a bit more specific info I might be able to debug a bit more for you.

Hi Matt,

You can get your app featured in the 'app carousel' if your device is in Google Play, but a knowledge graph box links to a website by its nature so I don't believe it's possible for it to link to an app instead.

All of the above are good answers, but ultimately my advice would be:

• make sure that the relationship between the two page versions is clear (using switchboard tags, as Sean mentioned above), and
• optimize the mobile version for mobile search, and the desktop version for desktop search.

As others have noted already, Google has some flexibility in which signals it chooses to look at - the goal is to provide the best user experience by device.

Hi Johannes,

I've understood your question to be about how to treat a site which uses dynamic serving for mobile content. Is this correct?

If your site keeps the same URLs for mobile and desktop versions, but serves different content based on user agent, then you will simply need to include a Vary-HTTP header. You can learn more about that here.

Hi Francis,

They should be different sessions, they could be the same type of device or even the same device used in a different way.

There is also a report which will tell you exactly what devices were used, which might be helpful.

I have to disagree with the above.

Google absolutely can view mobile content, in fact they have a separate crawler that spoofs a mobile user agent in order to crawl mobile content. They may not have a separate mobile index of that content, but that has nothing to do with whether they view, crawl, and index mobile pages. We know that they do, in fact, given that whether a page is mobile-friendly is a rankings factor for mobile search results.

To answer your question - having the content collapsed shouldn't be a problem as long as the content is viewable with Javascript and CSS disabled. If Javascript is required to expand the collapsed content, the mobile crawler may not be able to see this content. You may want to test the page(s) with the Mobile-friendly Testing Tool and also try a Fetch and Render (for Smartphone) of the mobile page, to see how Google sees the page(s).

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).

Glad I could help!

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, I don't personally have any case studies of sites experiencing a drop in organic traffic on mobile which can be traced to a pop-up interstitial (maybe in part because my clients don't tend to use pop-ups in that way).

When it comes to user-triggered content, I think it depends on a couple things, including how the user arrives at the pop-up and how the pop-up is implemented technically. Google's view of a site's mobile-friendliness is based on the result of a crawl, and so for instance if it's an event that isn't possible to trigger as a crawler, it shouldn't be a problem. I see it being similar to the use of JS navigation for country selection - it becomes an issue when (for instance) Googlebot can't get past a JS popup or drop-down because it can't click on a link to select a country option or to close the window.

This type of situation is often the case for the sorts of popup that occur when the page loads, giving an annoying user experience, rather than because a user has chosen to click on a link to provide an email address (for example). Google have also made clear that the primary concern is around it being a poor user experience, rather than a technical issue.

So I would see it as:

• Interstitial ad or other pop-up that appears on page load = bad.
• Some sort of non-disruptive data entry box like an email form that only appears when a user chooses to open it and which can be bypassed by a crawler = ok.

However! That's just my theory, I don't have data at the moment to prove or disprove that hypothesis. I would love to hear from other people who have other theories or any practical examples of this. Also, if you're not sure how Google perceives a given page, run it through the Mobile-friendly testing tool and they'll tell you.

Hi Tom, this will likely impact your mobile rankings, as the smartphone crawler is the one which primarily feeds the mobile index. Best practice would say to make the mobile content as close to the desktop version as possible, but I understand that sometimes the resources are simply not available.

My concern would be that if you remove all internal links to the pages, the crawler will no longer find that page in new crawls and may eventually remove it from the mobile index, or may discount the importance of the page. Of course, if it isn't mobile friendly, you may end up losing rankings anyway if competitors create a more mobile-friendly experience.

A couple thoughts:

• is the page getting valuable traffic from that position 1 ranking? If so, I'd strongly suggest including it on your list of pages to make mobile-friendly. If not, perhaps it doesn't matter if it loses the high ranking.

• you could create a sitemap which includes those pages, so that the crawler can discover them even if they're not linked to internally. I don't know that this will prevent a negative impact but it could aid discovery.

Hope that helps.

Have you got switchboard tags implemented? That should solve the issue.

Hi Gaston,

As far as I'm aware, inbound links are not a direct ranking factor in the app store rankings.

That said, as Eric mentions, links can impact things we do know are factors, such as downloads. So rather than focus on links as a metric, you're better off focusing on driving downloads and reviews, for which links from other places might be a channel, as we know these are direct factors for ASO.

My understanding is that AMP pages don't need to be HTTPS themselves, but the resources they link to often need to be (see https://www.ampproject.org/docs/reference/validation_errors.html). I think that is so it can be cached by Google and served on an HTTPS site without problems.

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 Gaston,

App store optimization is pretty straightforward, and making sure that your title and description are well optimized is a great starting point. Other app store ranking factors which are very important are number of downloads and positive reviews, so anything you can do to encourage more downloads and more positive reviews (as long as you remain within app store guidelines) should help your app store rankings. I'm not currently aware of any 'external' (i.e. non-app store) factors such as social media or links. You can also set up app indexation if you have website content which is the same as your app content, and this can help with discovery.

You may also find this presentation from Emily Grossman to be useful: http://www.slideshare.net/Suzzicks/app-store-optimization-smx-munich-emily-grossman

Hi Anirban,

Can you tell me a bit more about this page? Why is it only on the mobile site and not the desktop?

I wouldn't expect this to be an issue for SEO (especially not with a single page - maybe if you were doing this for lots and lots of pages we could see an issue). But I would suggest asking yourself whether it makes sense for this page to be mobile only.

If so, how likely is it for a desktop user to even find this page? It likely won't rank for desktop but that's a good thing because it's not really available to desktop searchers (since you've implemented a redirect).

Hi Michael,

Have you figured out what the problem is? I'd suggest that you check it out using the Google Mobile-Friendliness Testing Tool (https://www.google.co.uk/webmasters/tools/mobile-friendly/) - if it passes that test and looks alright on actual devices, I wouldn't worry too much about it as it means Google should give you credit for being mobile-optimized.

I think the other advice already given here is good as well.

Hi there, that's a great question. Unfortunately, as far as I'm aware, this would be difficult to implement; the only way I know of to do this is with cross device tracking via user ID in Google Analytics (Universal Analytics implementation). But that would only work if the user had logged in both on the mobile device and later on the desktop device. You could do a rough estimation of the FB driven later conversions by tracking micro conversions on mobile and then trying to correlate those with macro conversions on desktop, or something like that. But it wouldn't be very precise. Of course if there is a way of doing this more effectively that I'm simply not familiar with I would love to find out!

On a sidenote, it's worth noting that it's important to ensure that whenever you run a Facebook campaign, you tag it with the UTM tracking parameters, otherwise GA will likely misattribute it as direct traffic.