Everything Mobile with Google’s John Mueller and Mariya Moeva – Virtual Keynote

Mobile, AMP, App Deep Linking, Voice Search and More

Welcome to our third Virtual Keynote with Google! Also, check out our past Virtual Keynotes with Google’s Gary Illyes.

Here’s the video of our #VirtualKeynote conversation with John Mueller and Mariya Moeva of Google. You’ll find a full transcript below the video.

Eric: Hey, everybody. This is Eric Enge, of Perficient Digital. Excited to be doing our third Virtual Keynote, and we’re going to focus today on mobile. As part of that thrilled to have John Mueller and Mariya Moeva, two Google Webmaster Trends Analysts joining us for the first time on a Virtual Keynote event. Thanks so much for joining us today.

Mariya: Thanks for having us.

Eric: Absolutely. As always, Mark Traphagen is with us, so say, “Hi,” Mark.

Mark: Hello, everybody. Good to be with you.

Eric: Mark is going to be active on YouTube, interacting with you with any questions you have over there in the meantime and we’ll manage and drive the Q&A process when we get there in a little bit. Our hashtag for today’s event is #virtualkeynote.

If you need help spelling that, my suggestion is, because it would take too long for me to do it now, use Google. It’s pretty good at helping you correct words like that. But John, you had this important announcement that you were going to make for us today.

John: Oh, man, you’re spoiling it. Okay, I was going to make a joke about us moving to a desktop friendly update, but actually, people are still challenged so much about getting a mobile site out, especially small business owners are something that we’ve noticed. They really have a big problem getting that mobile site out, so I don’t really want to joke about it. I think it’s still a critical thing to do, so no desktop friendly joke today.

Eric: Okay, well there you go. I wanted to see if we could get the audience going there for a minute, but that’s all right.

The Rise of Mobile and Voice Searches

So but as we talk about mobile, I mean, I think the data is out there, there’s tons of data out there that shows that more people are searching on mobile than on desktop devices. I think that crossover happened May of last year.

I remember when you guys announced it on your blog. But also, Sundar shared some data on the proclivity, if that’s the right word, to do more action-oriented queries. What was that data again?

Mariya: Yes, so, we’ve got a lot of…a huge increase in voice queries because as people are using their phone more, a more natural way to interact with it is by speaking what they need. And we are seeing that around 20% of the queries on the Google apps on phones are now voice queries, as well as out of voice queries as a total thing, we get about 30 times more action queries by voice than by typing.

[Tweet “Google gets 30 times more action queries via voice searches than typed ones. More at”]

So there’s definitely a shift happening in that direction. It’s pretty early days, but I think for the people who are coming online now, and especially the people who never went to desktop and their first online device is the phone, it will be a very natural way to interact.

Eric: Perhaps part of that is selection bias. If they have action oriented query, they’re more likely to do it by voice. But it does still call out this idea that behavior will shift as the modes of input shift and it’s a whole other set of things which we probably won’t be able to dissect precisely today, as to how you reshape your mobile strategy around that. But it’s something for people to start thinking about.

What Does Google Mean by Mobile Friendly?

To start, I’d like to talk a little bit about mobile SEO and I want to spend the most time on some things that are the least commonly thought about aspects of that. App Indexing and then AMP. So that sounds like a good agenda. So to start with, I’d love to just get a definition from you on how does Google define mobile friendly? What does that mean to Google today?

Mariya: John, you want to take that one? Or I can also provide some general insights.

John: Yes, I guess the general idea is that we want the same content available on your desktop site to be available on your mobile site and also from the functionality point of view that users shouldn’t have any reason to shift to a desktop device to actually do whatever it is they want to do, which might be to learn more about a specific topic, buy something, maybe engage with other people on your site.

That’s something where, essentially, your mobile should be equivalent to your desktop and given how many people are mobile only or focused mostly on mobile, that’s something that I think shouldn’t be something Google should be driving. It should be something that businesses are pushing for themselves.

Mariya: We’ve identified a few very basic things, very easy things or common sense things like the font should be large enough for people to read it, the content should be fitting on a small screen that you need to be able to click things with your thumbs. So those are pretty common sense things we think.

But what John is saying goes beyond that which is you need to be able to complete whatever action is necessary on the phone. And for that, it requires actually testing it with users. Because even if your fonts are the right size, it might be that it’s still confusing.

Eric: Right, this idea is really interesting. As John said, I’m on this device, I shouldn’t really feel any impetus or need or desire to go to a desktop device. I can get it down here. That, I think, is a really interesting big picture way to capture a philosophy to our mobile design.

One interesting aspect of that is what most people do today is they design a desktop site, and then implement some software, maybe responsive web design or create some new templates, and they squish that desktop site down into a mobile site. Do we need to rethink that approach?

John: Yes, yes, yes, so I think for a large part it really makes sense to start with a mobile site first, and then work your way up to a filled out desktop site. That’s something that I see at Google, as well. So I’m not a real designer, but when we work together with people who are working on new products, new features for search console or whatever, they work with mobile mocs. They do all the mocs, all the approvals on a mobile layout.

[Tweet “All web design should be done mobile first, desktop second – Google’s John Mueller. More at”]

So every new feature that comes out, is built for mobile and of course, it scales up and shows maybe some different functionalities or different possibilities on desktop, but it’s built essentially for mobile device from the start. Because there we think, in the long run, most users will be.

Mariya: Yes, we really approached this from the user perspective. The users are overwhelmingly on their phones and will be more and more on their phones and whatever type of content you have, you want to make sure that it’s available to them where they are. They shouldn’t have to save your URL to look at it later when they have access to a larger screen. They need to be able to get done what they need right there.

And usually, if it works on the phone, it will actually be lighter and faster on desktop if you just keep the phone version. But yes, mobile first is definitely a smart way to start building these days. And everybody has a phone like that in their pocket, so this disconnect between when I’m going to talk to my developer and what I’m going to do on my phone, is really interesting to me.

Because people somehow don’t seem to think to check their own site on their phone when they do that with every other site every day.

Eric: Right, it is very interesting. So hopefully that’ll be a takeaway for some of you that are watching that mobile first, really actually means mobile first. All right, and start with your design.

Related: Impact of Google’s Second Mobile Ranking Update

Why Vary User Agent Is Important

So I just want to mention one other thing really quickly on the mobile SEO side of things, because I think it’s underappreciated by those people who have mobile subdomains, and that this is this notion of the vary user agent HTTP header, which is, as I understand it, because ISPs tend to cache pages, you have to give them an instruction to let them know that your page…that page varies by user agent.

What that does is it tells the ISP that it has to keep a copy in the cache for each user agent it’s willing to keep, so that it will serve the right version of your page based on whether you have a desktop or a smartphone device. Otherwise, you may have implemented a mobile site and people get the wrong version of the page. Did I get that roughly right?

John: Yes, it’s not something that we made up for SEO reasons. It’s really just a technical thing where we like every network need to be able to recognize that there’s actually different content there. So it’s something where your ISP will be caching the content, some other ISP might be caching the content, and all of that comes together.

So from a technical point of view, you have to say, “Well, actually, this content is different depending on this group of people,” or whatever. So it’s not so much a SEO thing, but more just a general, technical network web development impact thing.

Eric: Well, it’s a user experience thing. Right? Because I could try to get some of these websites from my phone, and then when I get there, I might get the desktop page because it was cached in an ISP and vary user agent is the way to address that problem to make sure that the user is actually getting the version of the page that you painstakingly designed to fit their device.

John: Yes, it gets more complicated with the content, itself, as well. Where if you’re doing this for images, or you’re doing it for CSS or JavaScript files, and suddenly, you have this weird mix of CSS for the desktop site and JavaScript for the mobile site and it just breaks. So that’s something that’s really hard to debug as a webmaster.

So either going the responsive web design route where all of the content is the same, or really making sure that you have that vary headers set everywhere, that’s what we’d recommend there.

Eric: Right, so if you’re on a mobile subdomain, the vary user agent header is a really important thing to make sure is part of your mix.

Related: How to Implement a Vary User Agent Header

Page Speed and Mobile

So we also heard that page speed was going to become a ranking factor in the next mobile update. Can you share any of your thoughts on that?

Mariya: We basically distinguish between very slow and reasonable. So we see a lot of people trying to optimize, if they get a Page Speed Insights tool score of 85 and they want to get to 87, and then someone else has 89. So that distinction is maybe a little bit going too granular. If your site is loading reasonably fast, then we’re good with that. So if you are shaving off a millisecond here and a millisecond there, that might be time better spent in a different place.
But having a reasonable fast-loading site, might make users more eager to browse, so you actually get them to do more stuff on your site. So from a user perspective, even a small change might have an effect on rankings, it’s like being 100 milliseconds more means one position higher, or something like this.
So if you do tests, and think about it from the user point of view, speed up whatever you can for them. But for us, we basically distinguish between a decent site and a slow site.

[Tweet “For mobile speed evaluation, Google simply divides sites between slow and fast enough. More at”]

Eric: Right, so if you’re getting red scores in page speed insights, and I’m not saying that’s your trigger but it’s something that’s so bad that it’s showing as really slow, then you could have a problem and suffer some impact. Right.

Mariya: And again, Page Speed Insights, we’ve built it so that it’s easier for the technical part of the team on a specific site, to be able to see what is happening and what they need to change. But a very easy way to test is just to switch off Wi-Fi and on 3G, or whatever network you have available, just try to load the site and see what happens. And then you’ll get a pretty good idea of are you willing to wait that extra two seconds or three seconds, or are you…is it good enough? So that’s a decent, just common sense test.

To App or Not to App?

Eric: Excellent. Let’s actually switch gears a little bit and talk some about apps. And one of the things that struck me is I looked at comScore data, which was from last August or something like that, and at the time, I recall it saying that 44% of all digital media time spent by people is spent in a smartphone app.

That was a fall out of my chair moment to realize…of course, that includes things like Netflix or Kindle apps or book apps, things like that as part of the time spent on YouTube where they can be great time sinks. But that seems to say to me that if you’re in the market to reach customers, which most businesses are, your audience is probably spending some of their time in apps somewhere, and maybe you ought to try and reach them there.

Having said that, one of the things that, I think this is Google data, I forget exactly what it was, something like a quarter of all installed apps never get used and 36% of the apps, if I’m remembering the numbers right, get used daily. And that leads us to the power of deep linking. Is that what you now call “Firebase App Indexing”? Can you just talk a little bit about why Firebase App Indexing is so important?

Mariya: Sure, yes, I just want to preface this was the caveat it’s not something that should be a part of a strategy for everyone. Apps are usually fairly high threshold in terms of people finding them and installing them, so you probably, if you have a cohort of very loyal customers that you see coming back again and again, those would be a very good part of your audience to target with an app.

Because they are already engaged, and you can engage them even more. If you think about apps in comparison to websites, you basically would have to download an entire website just to see one page. So that’s how it works with apps right now and we want to change that.

We want to make the information within apps as accessible and useful as the information from websites. Ultimately, our goal would be for people not to have to even think about where this information is stored. So that’s the benefit that we see for the users. And for content owners or business owners, the benefit is that we send people back to your app, again and again, from search.

We see that a lot of people install apps and then forget about them, so this is a good way to go back to the app. And also, there is a slight ranking advantage for these apps, even if they’re not installed when people are searching for them. So they might show a little bit higher and have a higher chance of getting installed.

So we are looking for ways and different technologies, some of this stuff that we announced at IO, like instant apps and game streaming and so forth, to make the content from apps available. And the benefit for business owners is that they might get more users, but again, this is not something that you should be looking to engage completely new people that have never heard of your brand or your business before.

It’s extremely unlikely that someone who never heard of a business will go ahead and just download a whole app from that business. So if your strategy is smart, then it can be a great thing. But then going and building an app and getting it indexed so that you could get a slight ranking boost, is too much effort for the return you’re going to get.

[Tweet “Does your business need an app? See what Google’s Mariya Moeva says.”]

Eric: If I’m not mistaken, there are three methods that people can use to pursue App Indexing in terms of exposing the URIs, the meta tag method, the API method, and the site map method. Can you talk a little bit about that?

Mariya: So we try to make those as simple as possible, so based on feedback from people, the thing that we are recommending right now and the thing that works the easiest is just to use the API and then connect your site in your app. And then there are fewer changes to be made on the website side, because one thing that we discovered is actually the biggest problem is not the implementation on the website’s side is difficult, or the implementation on the app side is difficult, but it’s the fact people have to talk to each other.

So the web team and the app team, normally are separate. And requiring them to collaborate made this process a lot more cumbersome, so we tried to shave off as much of that as possible and they still have to interact. So if you have an app developer in your company, invite them to lunch, but you just then have to make sure that your app supports HTTP URLs.

That means that the content is addressable and accessible, same as web pages. And then you need to connect your app in your site, and that you can do either from search console or from the Google Play console. So either the webmaster or the app developer can do this. And then after that, we just go to town indexing and calling and rendering content. So that’s as simple as we’ve made it as this stage.

Eric: Right, so when you use the API, the app developer is, for the most part, able to work on their own. Not entirely, but for the most part.

Mariya: Yes, so we’re trying to make this as simple as streamlined as possible and then API also helps send us information about how people are engaging with this app. And if we see that it is really popular, and there’s good engagement, we do provide an additional ranking boost for those apps so that they can show up even higher.

Related: Mobile App Questions Answered by Google’s Mariya Moeva

Google Now on Tap

Eric: Yes. Can you talk a little bit about Now on Tap and what that is?

Mariya: So Now on Tap is a really fun technology that I use a lot on my device. It lets you get into useful apps or search results straight from another app, so you don’t have to change context. When you are within a specific app, you can just press the “Home” button. This is for Android devices.

It will scan the contents of the screen and based on what type of content you have indexed from apps or in search, will offer some suggestions. So this is useful to look up things like movies or restaurants. That’s how I use it, most frequently, usually. And for app owners, it basically means that people don’t even have to search to get to your app.

They can be in a different app and move seamlessly to your app. So the functions of it are expanding and we are making to make it even more useful with more content. So it’s an interesting added benefit. I wouldn’t say it’s the main benefit of app indexing, but it’s an interesting added benefit.

Eric: Right. So if you do the right things with your app implementation, your app indexing implementation, then your app becomes eligible in the right context for participation in Now on Tap.

Mariya: Yes.

Eric: That’s of the example I saw, I think it was Behshad Behzadi did a demo and he had been searching for information about a restaurant and then he said, “Book me a table at 7:00 p.m.,” and it opened up the OpenTable app and actually went through the process of booking it. So it made it really seamless from the user perspective. So you’re almost crossing between web and apps like it’s one environment.

Mariya: Yes, and with things like Instant Apps and Apps Streaming, from search results we’re trying to find ways to make apps, even not installed apps, content from them accessible to users. So stay tuned, but we have multiple efforts going on in making app content more accessible to people.

Google AMP

Eric: Awesome. Alright, so we’ve got some time to cover AMP. I think that’s John’s cue. So can you give a little basic overview of how it works to start, John?

John: AMP is almost like a simplified version of HTML where what you do in practice is you take your desktop site or your mobile site and you create an AMP version of those URLs, and you link those to pages like you would with a separate mobile URL, for example.

Basically, you have a desktop site or your mobile site and your AMP pages, and you link between them so that we know for this specific mobile page we have this AMP page. And within AMP, the JavaScript that’s in there is made so that it almost renders instantly.

What we can do in search then, is provide those AMP pages in the news carousel, which we have there at the moment. You can click on those and almost within probably less than a second, you can get to that content directly.

One of the neat things around AMP is that this is an open platform, it’s open sourced. Anyone can work on that to add more functionality and it supports essentially everything. Maybe not everything but the primary things that most publishers need includes things like analytics, various types of analytics you can do there, ads, monetization to make sure that you actually get something out of that.

Eric: Right, so part of the gain is that the page ends up being a lot more lightweight in terms of total size, page size. Another part of the gain is that the content is largely pre-rendered so you don’t have a lot of back and forth with web servers taking place. And then the final benefit is the caching infrastructure that gets leveraged, so that people are retrieving their data locally.

Just to share some data from our tests here. We implemented AMP versions of our blog pages, reduced page size by 71%. It took us from a page speed insight score of 42 to 88. So from in the red with that 42, to a nice solid green at 88. And that was cool. And yes, so pretty dramatic speed up. Enough so that, Gary Illyes said when asked what the top two recommendations he had for people in his keynote at SMX Advanced, one of the things he cited was AMP. “AMP is going to be big,” he said.

John: Yes, so what I really like about it is that it’s almost a chance to rethink a lot of the things that we organically developed to around the web where we can say, “Well, this doesn’t really doesn’t work that well,” or, “This slows the pages down,” or, “This is problematic because…”

For instance, analytics, it’s something well different parts within your organization want different kinds of trackers, so people just end up adding seven or eight or 10 trackers to any specific page. And with AMP, you just have one tracker that, essentially, pings all of those other separately. So it’s a chance to rethink where the web is now and what it would be if we could simplify things completely, and start with something much smaller and lightweight.

[Tweet “Google’s John Mueller: AMP is a chance to rethink the web, make it simpler and faster. More at”]

Eric: Right and when we go back to the conversation we had earlier, which is, “Well, gee, maybe you should start thinking about your mobile side of things first.” Well, here we are. Here’s AMP, right? Being a mobile-centric way of thinking and that page feed matters in the desktop world, too.

Maybe it’s a little bit better adapted to dealing with more complicated communication because it does still matter quite a bit. So what are the kinds of things that you typically can’t do in an AMP page that you…the people will miss, potentially? Like forms, for example.

John: Forms are coming.

Eric: Excellent.

John: So I think AMP pages, since they’re served over cache, a CDN, it’s a lot harder to make them dynamic. So if you have something that changes completely from day-to-day, then that’s something that’s a lot harder to do with AMP. You can still use iframes for a lot of that, but it gets complicated.

For static content, it’s really, extremely well-suited. If it’s something like an article that you have that you want to present that you have on a news site, on a blog, it’s perfect for that. Any informational, static content, that works really well. But the other things, they’re coming step-by-step. So some of them you can do within an iframe already.

Things like forms are already on the roadmap. They have a public roadmap for this. It’s a GitHub project. You can see what’s happening, what people are working on. So it’s a little bit different from Google search in the sense it’s just all open. It’s open source, it’s something you can see what’s happening, where things are going.

[Tweet “Forms are in the works for AMP – John Mueller of Google. More at”]

Eric: That’s cool. There are other people like Pinterest and Twitter and WordPress, who are all involved. One of the important distinctions about AMP is it’s really an open source initiative with other participants. Google’s obviously playing a very large role in it, but it is a broad industry initiative.

In terms of using iframes to do things that you can’t currently do in AMP, you mentioned that, and that’s your way to create…carve out on the screen where the rest of the page will load instantly and then if you have something that you have to have going on takes place inside the iframe. Are there things that you don’t suggest using iframes to solve?

John: It’s hard to say. I guess from a search point of view, we would probably pretty much take anything that’s valid AMP, but for valid AMP, I believe there are limitations on the size of the iframe and the location of the iframe. So it has to be, to some extent, below the fold, because it’s loading asynchronously. It’s loading later.

So if it’s primary content that you want to show to people, then you probably want to keep it in that cached part of the page. But there are some really nice experiments that various publishers have done with iframes with AMP, so it’s definitely worth looking at.

One thing I recommend in general is if you’re working with clients with different companies, then this is a technology that’s not going to go away anytime soon, so it’s really worth taking the time to figure out how this works and what you might need to do to support this in the future.

So for example, for iframes, since these pages are cached on HTTPS, the iframe content also has to be on HTTPS. So if you haven’t moved to HTTPS, then that’s something that you probably want to do, especially if you want to put something in iframes later on.

Eric: Yes, so that’s a good point of emphasis, which is that you need to be on HTTPS. Right. And then, so are we still at the point where only certain sites get shown AMP pages in the results? Is that still the status?

John: It’s not white-listed. It’s not that there’s a manual list at Google which sites get AMP and which ones don’t, but we show it in the news section on top of the page, or depending on the search results, I guess, usually within a carousel, sometimes as normal links within the news section, as well.

If we don’t have that much content, what is different is we don’t show this in all countries at the moment, because newsworthy content depends a lot on the local news. You can’t just show news from the U.S. to people in India, because they expect their local versions, as well. So in order for us to show this AMP content, we need to make sure that there’s actually enough content that we could show there.

So it’s kind of, if you’re in one of those countries where we don’t show AMP yet, then by implementing AMP for your site, you’re encouraging us to jump in and say, “Okay, we have great content to show within AMP now. It makes sense for us to open that up there, too.”

Eric: So does it only show up when you have enough results that you can just play the carousel? Is that what you’re saying?

John: We show either carousel or the individual links. So I don’t think there’s a number of results limit, but especially for the individual links, those are just individual links. It’s not that we need 10 of those to show.

But this is also something that I see moving further through the search results for different types of content, not just news content, where the AMP team might say, I believe we said something around recipes at Google I/O, for example.

[Tweet “Google plans to expand AMP to more kinds of content. More at”]

Mariya: Yes.

John: Where that’s…different parts of the search results where we think static content currently plays a big role and where it’s important for us to say, “We can provide something really fast for the user and by providing something fast for the user, they’re willing to engage more with that within your website, read more and just generally be able to process this information faster.”

Eric: I’ll let you know when the Perficient Digital blogs start rendering AMP pages. How about that?

Related: Eric Enge: 8 Things You Need to Know About Google AMP

All right. Hey, Mark, are you ready to drive the Q&A here?

Mark: Absolutely, we have a lot of good questions.

Eric: Awesome.

Mariya: Let’s go.

Mark: Okay, guys. These are questions that our registered users for the Virtual Keynote submitted to us in advance. And I just want to remind folks who are watching, we’ll be doing these on a fairly regular basis, be watching for them from all of our social media feeds. And if you register in advance, and get on our mailing list, then you can submit a question that will potentially be asked here.

We have a lot of great questions. I’m going to focus mostly on the mobile questions. We got a lot of general SEO types of questions, but since we can keep with the subject matter in the time that we have. But I am going to sneak in one more general question, just because I think it’s fun.

This is from Andy Simpson and Andy asked, “John, when do you think we’re going to be hit by SSLmageddon?” I know you must love that name as much Gary Illyes loves mobilegeddon. Let’s put the question more positively. Is having a secure site going to become a major ranking factor and when?

John: Actually, we’re way past SSL, because SSL is essentially the last generation of the secure protocol that was used for HTTPS.

Mariya: TLS.

John: And I think we switched to TLS five, six, seven years…I’m not sure. But SSL is essentially obsolete. No SSL-geddon.

Eric: But then you got a TLS-geddon.

John: No, no, no, stop.

Mark: Go ahead.

John: But I think HTTPS is something that is not going to go away. It’s not a fad. It’s not something where people will say, “Oh, Google cares about this today, but next week, Google will care about rich snippets.” It’s something that, essentially, needs to be a part of the web by default in the long run. So the earlier you move, the faster you have it behind you and you can move on.
So that’s something where I see, for example, with AMP, if you have embedded videos of iframe content, you need to have HTTPS anyway. You need to have done that. If you want to set up a progressive web app where you have a service worker that creates an offline version of your website that works on your phone, then you need to have HTTPS.

A lot of technologies they essentially require HTTPS to work and it makes sense that they require that. So the earlier you can move to HTTPS, the faster you have it behind you and I imagine, a lot of sites when they start off nowadays, if you start off with HTTPS, the initial cost will be a minimal amount more than just by starting off without HTTPS. So especially if you’re setting up a new site, just do it from the start.

Mark: So people should be thinking about it in terms of if it’s the right thing to do for their users, it’s the right thing to do for some of the things they’ll be able to offer, not so much as a ranking factor in Google?

Mariya: Yes, if you do it for the ranking, you were doing it for the wrong reasons and given how many other signals and factors we have, you probably will be waiting for a long time to see yourself jumping up in the results, because you have HTTPS.

But the trust that you’re going to get from users is more important and the fact that more and more in new technologies require this, is also something. It means that even if you want to implement something in the future, you might be blocked because you don’t have that and then you have to do it in a rush.

[Tweet “Go HTTPS not for ranking, but for user trust and ability to adopt new features – Mariya Moeva of Google. More at”]

Eric: Yes, I can tell you we did a test of HTTPS as a ranking factor a while back and we found, essentially, no discernible ranking benefit. This was immediately after it was announced that it was one, but the way that Gary described it to me is you treat like it tiebreaker in a very close ranking situation. And I made the analogy of it being like the Vice President’s vote in the U.S. Senate in case there’s a tie there. It’s come up three times in U.S. history.

I don’t mean to diminish it, but just step back where you could see where it might become more significant of a ranking factor and I’m not speaking on behalf of Google, I’m speaking on behalf of myself, is if nearly everybody has converted to HTTPS and you’re the one who hasn’t yet, then it might be more noticeable to users and be worth putting more weight on. But right now, it’s something that’s going to be a big ranking factor just because…

John: But it’s also something that’s coming from multiple sides. So I’ve seen browser companies say, “Well, we’re going to flag all HTTP content that potentially insecure, because nobody knows what has happened to this content from the time it left the server to when it reaches your browser.” You don’t know. It could have been modified.

There could be tracking elements added to it, people could be injecting ads, it could have malware injected. Obviously, a lot of this is really something that really rarely happens, but when you go to places that have public Wi-Fi in airports, for example, it’s really common that you suddenly have some weird tracking element attached to a page or some ads that are injected in a weird way and that’s something where if you care about your website and how it comes to users, you need to watch out for that.

Eric: Well if you ever want a demonstration, just go to a hotel and sign up for their wifi, and try to go to a webpage, that’s an example of what you can do. You can’t guarantee that the content you as the publisher have published is what the user is going receive without it.

John: And another thing probably worth mentioning, if you have a blog for example, if you’re creating your content while you’re out, while you’re at the airport or at a café with a public Wi-Fi and you don’t have HTTPS, then you’re essentially sending your password for your whole setup in the clear. So anyone who might be monitoring that, might have access to your blog’s username and password.

Eric: That doesn’t sound good!

Mark: All right, let’s jump back to AMP. A lot of people asked us about the expansion of AMP to other types of sites and I know you already alluded to that a little bit. But can you give us any more insight or detail on that? If I have an eCommerce site or something like that, with content on it, is it worth me spending the time to get involved in implementing AMP? Is it going to benefit me eventually? How soon will it be rolling out to other sites aside from sites that get into Google News?

John: So it’s not limited to Google News. I think that’s, maybe, upfront, it’s the in the news section can be any type of content that’s newsworthy, which means you don’t need to think about the type of site but the type of content that you have.

So for an eCommerce site, maybe you’ll still have news articles that you’re putting out on your blog or you have general blog posts that are happening, and those blog posts could be put out in a way that’s compatible with AMP. So you install the WordPress plug-in, and you essentially just have to tweak the template and you’re done.

And suddenly, all of the stuff you put on your blog is available in AMP format and could be showing in search like that. So it’s not so much the type of site, but more the type of content. With regards to other types of content, that’s something where I know the AMP team is working extremely fast.

I think they’re one of the most efficient teams at Google, at least the people at Google that are working on this. So that’s something where I really expect that to flood out into various parts of the search results fairly quickly.

Mark: Thank you. Felix Ofiwe of Blinds.com wants to know if we look out a year from now, how much different do you think the mobile SEO landscape will be? What changes do you see coming down the pipe, say about a year from now?

Mariya: A very interesting question. I think what we see is very different from based on the size and how in touch people are with what is happening. So I would really hope that a year from now a much larger chunk of small business websites and other websites, like educational institutions and stuff like that, will actually have a mobile-friendly version.

So the lag that we see between what is happening from the user side and what we announce and then what is happening in terms of the adoption within the community, is definitely significant. So hopefully, and maybe whoever asked this question can help with that if that’s what they’re working on, more and more of these sites will actually be mobile friendly. Because we see a lot of people just missing out on this whole thing.

Then, in terms of what’s going to happen at the avant-garde, like cutting edge, I think there’s a lot of interesting things happening with voice queries, with all these assistants that are popping up.

So those would be new and interesting surfaces that we’ll engage people on and there’s a lot more in terms of videos and images. So balancing speed with rich content is also another very interesting topic for us.

Then, also, personalized and hyper-local content. So these things, I think, will continue to happen, but the main thing for us is that everybody gets to hear about the importance of mobile. Because there’s still a lot of people out there that are way out, just have a desktop site that they haven’t touched since 2004 and we would really hope that those people will get on board by next year this time.

Mark: Great.

Eric: Yes, I’d offer one thought, too. Just go back to what we talked about earlier. Design your site for mobile first. Right?

John: I mean, you see it with the people when they’re out and about, they’re on their phones. They’re doing something on their phone, they’re using it for everyday activities. Even when I have my laptop in front of me, I’ll pull out my phone and do something on my phone directly just because it’s more convenient. It’s easy to do voice queries.

I think this trend of people doing more and more on their phone, and they’re expecting it to work, and getting frustrated if it doesn’t work, that’s going to keep happening. And another thing that I suspect might happen, if I put a futurologist hat on, is that a lot of the people in some of the emerging markets, they’re essentially growing up without a desktop.

They’re using the internet from the start with their phone. They’re maybe using a laptop or desktop in the office for a couple of hours, but the rest of the day, they’re spending on their phone. And the way things are growing there, I definitely see some things that were designed for mobile there, swap over to the western world. I don’t know what you would call it, but that’s something where I really expect some interesting changes and just with regards to mobile, but with regards to online culture, in general.

Eric: Well, you have to understand that there’s going to be a bit of a journey here, right? Nobody has the perfect answer of what the perfect mobile experience is. We’re dealing with data points like the one Mariya shared earlier, which is 30 times as likely to get an action-oriented query by voice, and I suggested some of that might be selection bias.

But I don’t think there’s any doubt that the behavior of the person with a different keyboard and a different screen size and voice interface is going to be somewhat different. And so that can be a little bit scary for some people to jump into, but for me, I’m always a glass, I’ll call it half full, I think that’s being optimistic, for sure. But the unknown is opportunity.

That’s how you get a chance to get ahead of other people. You’ve got to dive in and take advantage of this opportunity that’s lying in front of us because we have a major disruptive change, which is in process right now. This is where people win and lose. So that’s my…can I get off the soapbox now?

Mark: John and Mariya, in your last comments, you both touched on voice search and the effect of voice. Let me see who this is here. Oh, there it is. Vince Pimentel of GT Nexus wants to know, how is conversational voice search going to affect how long string searches appear in Google Analytics and/or Search Console? So the effect of long string search queries from conversational search. Any particular effect you would see there?

Mariya: So for Analytics, I can speak to what they’re planning to do with this stuff. In Search Console we have very close relations with the engineering product teams and they’re looking into potentially might it make sense to have this distinguished in the Search Analytics report in Search Console so people can split those out.

But there’s so many different elements in the search results phase. We’re way, way beyond the 10 blue link so it’s always a matter of prioritization. Do you show this or do you show that? Last week we had the rich cards as their own element in Search Analytics and there’s more coming. But basically what we’re looking at is what type of elements to show. So what you might see within the next year is that you’ll be able to split by voice queries in Search Console.

[Tweet “Segmented queries from voice search might come in the next year to Search Console – John Mueller of Google. More at”]

Eric: That would be very cool.

Mariya: Yes, so it’s competing with a bunch of other priorities, obviously, so we can’t really promise anything here, but it is one of the things that is being looked at.

Mark: That was a nice little scoop there. Somebody out there in Twitter should be tweeting that out under the hashtag “virtual keynote”.

John: So I guess one of the things there to keep in mind, is we try to make this information that it’s actually actionable for you. So that it gives you something that tells you a bit about what’s happening, but also gives you an opportunity to say, “Okay, if I work more on my site in this regard, then this metric will improve.”

That’s something where voice queries are sometimes tricky, because it’s almost at the phase now where it’s interesting to look at but you don’t really how to respond to that as a webmaster. Because for a large part, we essentially do search results normally. You don’t need to do SEO for voice queries, we can understand what people are talking about and try to bring the same type of results in.

If you have specific use cases where you say, “Well, if I had this split out in Search Console, then I could make this amazing that Google would be proud to show in the search results,” then that’s the information that would be really useful for us, because we can go to the product team and say, “Well, look at this thing that people are willing to do with this information if only they had it.”

Eric: Right, and of course, this gets back to what I was saying before. This is going to be a bit of journey and part of it is learning…you need raw data to learn and then you’ve got to find out what the meaning is in it at some point, right? We don’t know the direction really the voice queries are going to take us in the long run. It’s going to take us somewhere. Maybe not an SEO specific thing that people need to do but certainly a UI design thing that they might learn from.

Mark: That makes a nice segue to a question from Laura Crest here. Not about voice search, but something that probably a lot of maybe beginning webmasters or beginning SEOs might wonder about. Is there a significant difference between SEO best practices for mobile versus desktop? Should you be thinking about SEO differently from mobile versus desktop?

John: Not that I can think of. I mean, it’s something where at some point, what will probably happen is that most people will go to your mobile site and maybe you should think about which one is actually my main site?

Maybe the desktop is almost your alternate site. But when it comes there, obviously we need to make sure that we can actually crawl a mobile site and pick up the links internally, as well. But otherwise, I mean, even that is the same with a desktop site. There’s links, there’s content, there’s a semantic structure.

Mariya: Yes, whatever helps your mobile will definitely be beneficial for your desktop site. So nobody ever complained that a site is too fast or that it’s very clear where you’re supposed to click or that there’s exactly the amount of information that they need.

So definitely if you make your mobile website work, the benefits will ripple out to your desktop version and, again, based on user studies or query information, however else you’re keeping track of what your clients and users are doing on your site, you might start questioning, “Okay, what is the functionality that I can’t by any means have on my mobile site? What is this distinguishing thing that keeps the desktop version still there?”

Mark: A couple of people asked about a separate ranking index for mobile versus desktop. Is that still coming? If so, how far off is that?

John: I guess we’re still experimenting with those things. So I don’t have anything specific to announce. That’s something whereas we see more and more people going to a mobile site, maybe it makes sense to treat that more like a desktop site, but that’s something where I would say that’s still in the future where we’re looking at various things, doing experiments, but it’s not easy.

I mean, these are things where you’re looking at the long-term development, and that’s something where when you make plans for a company like Google around search, you need to think about on the one hand, where could be in one year? But also where is the web headed in the next five or 10 years?

What do we need to do to make that incremental change in that direction? And those discussions are not that easy. No one has a crystal ball and says, “Well, this is going to happen, therefore, we need to take these 10 steps over the next couple of months to actually get there.”

Mark: Okay, Avinash Conda of Shutterfly asks, “How different are the rankings from device to device?” He says, “We are currently seeing different rankings on different browsers, as well. How big is this difference?” So is there actually a difference in rankings between devices?

John: I’m not aware of it.

Mariya: I never heard of that.

John: Yes, I could imagine maybe for apps you would see some difference. I don’t know for sure. Mariya would probably know.

Mariya: It’s to the extent that some things are available in, let’s say, Android and not available in iOS. So they would simply not trigger.

Mark: That makes sense.

Mariya: But I’m not aware of any difference in the results…like, you were using this phone, or using, I don’t know, that browser, so we’ll show you…

Mark: You’re not serving up search results specifically geared towards different devices other than those features that might not show?

John: Yes, I mean, one thing that might be happening, depending on what they’re looking at, is that maybe they’re looking at different versions of the search results. So maybe we can recognize that this specific feature only works in modern browsers, and you’re currently using an older browser and we show you a simplified version of the search results page that doesn’t show that feature.

But it’s not that we shift the rankings around. It’s more that, well, this specific component of the search results doesn’t actually work on your browser. We won’t show it to you then. So that might be happening. I guess the other thing is just a general, we do a lot of experiments and you might be looking at different data centers, different paths, personalization comes into play.

But I don’t really know of anything where we say, “Oh, you have a Nexus 5 and you have a Nexus 6, therefore, we will show you different results.” I don’t see that making sense.

Mark: I think that’s a good general point that you mentioned testing and we’re hearing about that a lot more in Google presentations that we’re hearing where all this testing going on all the time, in select groups of users at any given time that you might be in a particular test. So people, when they see something odd in the search results, they shouldn’t run right out and say, “Oh, my gosh. Google’s changed this.”

Take some time, see if that results lasts. Are other people getting it? Other people in different parts of the world getting it? It’s good to just ask around and see what’s happening before you run off, right? It’ll save you two a lot of time.

John: Yes, we do a lot of tests, but it’s not that we’re doing these tests to bug the SEOs and make them all freak out. I think this is something that everyone should be doing. It’s something where even if you think you have the perfect website, you should constantly be testing that and checking your assumptions and making sure that what you’re providing, actually works well for your users and that you’re actually doing the best possible for users. And that’s something where you sometimes have to go back and say, “Well, I always thought this was what everyone wanted to see, but maybe I should double check to see if that’s really the case.”

Mariya: Yes, we actually launched a really cool program very recently in the U.S. and a few other countries for developers. So it’s Device Labs and you can get access to a bunch of different devices and limit different things like speeds and types of networks that this device is on.
It’s intended for apps, but you can also do the same principle for testing your site and that is always really helpful because if you are seeing your device or your site on an iPhone 6 Plus, with a huge screen on LTE, it might be a very different experience for someone with a smaller screen on 2G. So if you have that audience, then it’s great to test that, too.

Mark: Let’s see if we can make this one quick. This is from Tylor Hermanson and he says, “Are there any hard and fast rules in striking a balance between content consistency and UX concerns with multiple device views?” So in the world where there are multiple devices, you’ve got UX concerns, right? You’ve got content delivery concerns. How do you strike a balance in there?

John: Very carefully.

Mark: Maybe that’s the only answer that can be given. I don’t know.

Mariya: Yes, I would suggest thinking about progressive enhancement and graceful degradation here. So if you have something that works on the worst possible situation, then you can progressively enhance from there and give more and more to people who have devices with more capabilities. And then the other way around, if you have something that’s really fancy, think about how you can do graceful degradation for that for slower speeds and older devices.

Eric: Thanks John and Mariya!