Reconsideration Requests
Show Video

Google+ Hangouts - Office Hours - 18 December 2015

Direct link to this YouTube Video »

Key Questions Below

All questions have Show Video links that will fast forward to the appropriate place in the video.
Transcript Of The Office Hours Hangout
Click on any line of text to go to that point in the video

JOHN MUELLER: All right, welcome everyone to today's Google Webmaster Central Office Hours Hangout. My name is John Mueller. I'm a webmaster trends analyst here at Google in Switzerland. And part of what I do is talk with webmasters and publishers like the ones here in the Hangout. Today, we have as a topic everything kind of around mobile, AMP, app indexing, all this stuff you can do on your smartphones. I have a short presentation prepared. I'll run through it fairly quickly. You're welcome to watch the video afterwards and pause the slides to read everything if there is something specific that you're looking for there. Otherwise, let me just get started, and then we can move on to questions afterwards. Let me just double check. OK. So I guess, as a background, for a lot of you, this isn't really new. The usage on mobile is now exceeding the usage of desktops. So at least from our side in search when we look overall, we see more people are searching on mobile than on desktops. So we really want to make sure that these users have a great experience, that they land on great sites that work really well for them on mobile. From our side, we introduced the Mobile-Friendly label that looks at various things on a web page to see if it works well on mobile, and that includes things like being able to recognize the size of the text, that the primary elements are used in a way that don't work on mobile, all of these kind of things. The Mobile-Friendly Test is something you can do to double check your pages to see how our algorithms would show that. What we're doing there is labeling these results on mobile when you're searching so that people can find them faster, and we're giving them as like ranking boost when people are searching on smartphones. So the options we have available there-- the details are all in our documentation. So if you're curious, and you haven't set up your site to be mobile-friendly yet, these are essentially the three main options that we have. We recommend responsive design. There's also dynamic serving, which is automatically serving content based on the user agent, and then separate mobile pages where you create separate pages that are connected to your main page, which are specific for mobile devices. We recommend responsive for several reasons. It's not a requirement that you go responsive, but if you're kind of on the fence, and you don't know which way to go, than we think this is a good approach. It uses the same URL. So you don't have to make any site structure changes. You don't have any problems with links, there's no extra crawling involved, and it's a lot easier to diagnose problems because you look at the same content every time. You don't have to use a special phone or an emulator to double check your pages to see if there any technical issues on those pages. One important aspect with regards to mobile-friendly specifically is we need to be able to see the page how a user would see the page. That means we need to be able to crawl and index things like the JavaScript on your page. Using the robots.txt file, we need to be able to have access to JavaScript, CSS, those kind of things on the page, so that we can actually render the page how it would be in a browser. One fairly new aspect that we added to this test is that we need to be able to see the content, and if you have an app that you'd like to promote to users, which can be a great idea, just make sure that your app banner is kind of smaller on a page. It doesn't really block the whole content that you're not creating interstitials for users to actually install an app. So both for Chrome on Android and Safari on iOS, there are these banner scripts that you can implement directly that are kind of smart as well to recognize if the app is already installed, and it's a kind of a subtle, smaller banner thing instead of blocking the full page. Sometimes we also see spam on mobile, unfortunately. A lot of this is from sneaky redirects or cloaking. And some of these are actually from scripts that webmasters install, and they don't really realize what they are doing, which might be something like monetization scripts, those kind of things where in the background the script will check for users in certain countries on certain mobile devices and redirect them to other pages, which probably isn't what you're trying to do and might be kind of tricky to recognize if you're not actually double checking your pages from those countries. Speed is really important aspect, especially on mobile where everything is slower just due to the whole networking set up on mobile. And we recognize that people jump out of websites fairly quickly if they don't load fast enough. So for us, that's a sign that we're giving them a bad service by sending to pages that actually don't work that well for them on the mobile devices. So one of the things we've been doing to work against that is the Accelerated Mobile Pages Project, which is an open-source project that essentially makes it a lot easier for people to get through to content very quickly in a very fast way. It loads very quickly. It uses a CDN automatically. You can include things like analytics, ads. It's completely open source. There's also a demo with how it works on Google on smartphones. So you can try that out. You can also try that out within Chrome if you set your device-- if you use the emulator too to activate one of the mobile devices. I think this is the really great thing. I imagine this is going to be a really big topic next year. So if you want to kind of stay of the curve and be prepared for the questions that might come from clients or friends who have questions about mobile stuff, this is probably one topic to understand a little bit better and learn the background it. So essentially, what AMP does is it takes the primary content of your page, and you create a separate AMP page for that. Based on the primary content, it's HTML. You can still do it in the browser. But it's a very limited subset of HTML, which is specifically designed to load extremely quickly. So there are certain restrictions with regards to external content with regards to things like videos and images that you need to keep in mind. But it's meant to really load very quickly. And the setup is similar to separate mobile pages, so it's nothing really new. You've probably seen a lot of this before. You essentially have a rel link element pointing at the AMP page. And then from an AMP page, you have a link rel canonical back to the web page, which is a requirement from our side. And essentially, what this means is we'll focus on the web page for indexing and ranking. The AMP page will be usable for devices where we can show that-- where we can show that in search maybe, but otherwise, we'll focus on the web page for ranking. So you don't have to modify your existing web pages. You don't have to kind of switch everything over to new URLs for AMP. It's essentially an alternate version of your primary content. The general setup is kind of similar to feeds, for example, in that you essentially have your main website, you're publishing set up, your CMS, or whatever you have. On the one hand, it generates HTML pages, which go directly to users. That's something that most of these sites probably already have. Then the system generally also creates some kind of feeds, which could be RSS Atom feeds, which are sent to the feed ecosystem. They also contain the primary content and essentially, similarly, you could take the primary content that you use in a feed and put that into an AMP page, and have that automatically generated by your CMS. So a lot of the CMS systems are working on or have already worked on plug-ins for their CMS that generate these AMP pages for you automatically. So you might not even have to do anything else other than installing CMS and selecting the check box, while installing a plugin and then doing the check box. And the AMP content is then sent to an AMP cache, which is essentially the CDN setup, and then from there, it can used by essentially anyone who is digesting this AMP content, and that's a number of sites apart from Google already. So in search we're currently showing this more for kind of published content where you write an article-- those kinds of situations. We're currently showing more for kind of the newsy content rather than random content on the web, but that doesn't mean that won't change. This is really early days. It hasn't even launched yet on search officially. We just have that demo. The other thing to keep in mind is it's not just for search. So anytime someone shares a URL from your site on Twitter, Pinterest, LinkedIn, or whoever else digests this content, they'll be able to use this AMP content directly as well and maybe show that directly in their UI as well. So it's not just something that you do for Google. It's essentially the way of syndicating your content a little bit better to all these other platforms so that people are able to find your content quickly and then go to your site if they want to find out more. There's a validator built in. So you can just add this #development=1 to the end of URL, reload the page, and look into the JavaScript console, and you'll see right away is this AMP page valid or is it not valid. So it's really easy to double check if things are working right. We plan to introduce this in search towards the end of February next year. So I suspect you'll see lots of people promoting this a little bit until then to encourage more and more sites to actually implement this. My tip is to kind of dig into the details on how this works from a technical point of view and then think about where this actually makes sense for you on your sit, for your clients, for other people that you're talking to so that you can make a better decision at that point or, until then, about whether or not you actually need to do something because it might be that your site is more of a dynamic site that widgets, and it's an interactive set up that isn't really suited for this kind of content. It might be that a part of your site is suited, and the rest isn't. It might be that everything is well-suited for this kind of AMP setup. So that's something where I recommend you take a look at what all is involved, what all can happen with this content, how this actually works, and then making a more-informed decision, rather than jumping in and saying, oh, man Google is doing this. I need to do this as well. A lot of these things aren't really made for all sites all the time. And if you're making your own CMS or you're using your own analytic setup, make sure you check out the GitHub link for the AMP project because that has information on what you need to keep in mind-- how you can tie your setup in. All right, moving slightly away from the website and moving more towards the apps, which are something where we see lots of people are active on apps as well. So from our point of view, we think any kind of unique content that's available in an app should be findable too. Or if there is something that you have in your app that we show in search, and we think your app might actually be a better search result for people who have your app installed, then that's something that we'd like to point people at. So the main requirement here is that your content needs to have direct links to the app content. Sometimes apps will be made in a way that it's kind of a dynamic thing that there's no specific URL when you're looking at part of an app. So that's one thing that you have to think about when making an app or when converting it for app indexing, it needs these so-called app deep-links. And currently, we recommend that your individual app content that you want to use for app indexing has an equivalent on the web so that we can say this page on the web matches this URL on your app. It doesn't have to be that all pages on the web have an equivalent app or all pages have an equivalent on the web, but the content that you want to use for app indexing, we currently recommend that you kind of have an equivalent so that we can understand how to rank this content a little bit better based on your web content. So from a practical point of view, it kind of looks like. You search for something. If you have this app installed, it will have it link directly to the app instead of to the web page. So it swaps that out, similarly how hreflang might swap a URL out. And if you click on that, you can go directly to the app. So essentially, for a user who has this app installed who has already confirmed that they are really interested in is this website, this business, they are able to go directly to the app where they can potentially do a little bit more than just on the mobile website. The setup is, again, similar to the setup for mobile pages. It's not quite the same because it doesn't have that real backlink to the web pages. But you essentially have a link rel alternate to your app URL. And from the app, you use the app indexing API to give that information back to us so that we can confirm that this link is actually correct. And that's something where we just published a new documentation for on the app indexing API. So if you've been stuck in trying to implement this and have some questions and check out the new documentation, I think that's a really big step forward. Another place where apps can show up on phones if you have them installed is now on tap, which is this really neat feature in the newer Android version where you can long press the Home button, and essentially, it will take a look at the content that you're currently seeing on your page and make some recommendations for you. So if you're talking about a restaurant, and you have a restaurant app installed, then it will try to show that directly in the Now on Tap pane here, which lets you go directly to that app that you have installed. So for some kinds of content, this might be really interesting. It's really for the new phones at the moment. So it's not that properly used at the moment. But I think there's a lot of potential here to really drive people to an app if you have something that people like to talk about that is essentially something interesting in general for users. So some tips-- I know the first one is the one everyone is interested in. They hear the word ranking factor, and they jump. But it is a ranking factor from our point of view, because if users go out of the way to install an app, and that's not a small step that they just do, generally they want to use that. And we think it makes sense to show that a little bit more visible in the search results if someone has that app installed. So that's something where if you have an app, and you know that your users are looking for this type of content in search, then we'll try to show that a little bit more visibly for those that have it installed. Apps are generally a long-term investment. It's not something that as a website owner or a company owner, you can say, oh, I'll just make an app and see how it works next week, and if it doesn't work, I'll turn it off again next month. It takes a lot of work to make an app, and it's not something that's really suitable for all sites or all businesses. So you have to think about it, similarly to how I mentioned with AMP whether or not it actually makes sense for your site, your business to invest in an AMP, or maybe it makes sense to just invest more in your mobile website and turn that into something that's really well made. You can test these apps with Search Console. There is the Fetch as Google feature for apps as well, which is really useful to kind of diagnose the issues around the indexing API where otherwise it would be more like a black box that you create your app, and you put it online. You don't really know what's happening there. So that's something that's happening there. We also have some better programs coming up around app indexing. So if you have an app that you have set up for app indexing, I'd recommend checking out, of course, maybe signing up for the better program that we have for Search Console stuff, which is, I think,, all in one word. I can add the link afterwards. But I guess, in general, all of these days add up a little bit in that lots of people are going mobile now. Lots of people are actually using the mobile as their primary internet device. I know when I look at home, and I look at my family and friends, they are much more active on their phone than they are actually on a laptop or on a desktop computer nowadays, and they do essentially everything on their phone. So that's something if your business, your site, isn't really mobile friendly. If you aren't using these techniques in an optimal way to present your content to users and make it possible for them to actually get you everything, then that's probably something you want to reconsider, because other sites are doing these things, and when users a choice, they sometimes stick to that decision. So my recommendation is to be mobile-friendly as default and not focus on being desktop-friendly, because things that are made mobile-friendly using responsive web design will probably work on desktop as well. It's interesting at Google as well when we look at mocks and create mocks for new projects, we usually make those mocks mobile first. So we make the UI think about the user flows with a mobile UI rather than drawing out a desktop UI and comparing how it might work there. So these are things where as we see more and more people are actually using their mobile phone as a primary device, it's important to actually focus on that as well and not treat mobile as this secondary citizen that's, well, they are also out there, and we need to be friendly to them. Essentially, that's more and more the primary way of getting on the web. If you're publishing content, I'd definitely check out AMP and see if that makes sense for you. If you have an app already, I'd checkout app indexing, and in general, with all of these things, I'd really, really recommend that you try it yourself. So if you don't have a smartphone, even if you're kind of holding out and saying, oh, I don't need a smartphone for philosophical reasons, I don't want to be part of this smartphone crowd, I'd definitely recommend going there and trying all of these things out so that you understand a bit better what's actually happening, what's possible, what other people might be seeing when they look at your site, when they look at competitor sites, when they try to interact with the web. All right, and with that, I've come to the end here. Like I mentioned before, if there is anything that's unclear, you're welcome to look at the video afterwards, and pause the slide, and read it in your own time. If you have any questions afterwards, feel free to post them to the event entry, or to the video description, or in the webmaster help forum as well. We probably have some questions here live in the Hangout too. So if you want to ask away first, feel free to jump on in, and then afterwards, I'll try to run through the questions that were submitted as well.



MALE SPEAKER 1: Quick question, we very recently published our app for our website. We have a medium-sized website with good traffic, and it has really good search ranking. And we're trying to figure out-- we are starting to see some traffic coming through the Search Console, but very, very narrow. And I'm trying figure out if the impressions are for people that have not installed the app yet and are getting the Google Play link. Or are they only for people that have installed the app? And the second question-- I'll let you answer the first one first.

JOHN MUELLER: Both. But there is something changing there-- I guess maybe today, maybe early next week-- with regards to the numbers that we show there with the app install link. So on the one hand, it's the people searching for your app directly. So you're searching for, I don't know, a company named app or a website named app, and we show this Install button directly, that's one of the types of impressions. The other type is when we show it to users who already have the app installed. So that's something that we're separating out a little bit so that in Search Console, in the Search Analytics for your app, you'll be able to see is this an app installed or is this essentially a normal search impression that was shown.

MALE SPEAKER 1: Great. Actually, a good improvement. Another question, so I'm testing the app indexing with the Fetch as Google, and I'm getting partial content, and all of the URLs that we need to fetch from our JSON APIs are basically returning errors. So I'm basically showing to the users an error page. Any explanation? I tried to use the forum as well, but to no avail.

JOHN MUELLER: That's really tricky because it's really hard to figure out exactly why we're seeing a partial or an error page there. One thing that's kind of important is if you have in JSON API or any kind of API on your server, we need to be able to crawl those requests as well with Googlebot. So they need to be, on the one hand, not blocked by robots.txt. On the other hand, with the Googlebot user agent, we need to be able to access those URLs directly. So if you have a server response that's sending a list of items an item description back to the app, then that's something that we need to be able to access with Googlebot so that we can crawl this app page.

MALE SPEAKER 1: OK, have you got any suggestion how I can get test this? Because I've crawled the API with the Fetch as Google as well, and it seems fine. It responds with 200, and I can see the content with the JSON. Any other app that I should run?

JOHN MUELLER: I don't know. If you could send me the link to your forum thread, I can think take a look at that.

MALE SPEAKER 1: All right, OK, thanks.

MIHAI APERGHIS: Hi, I have a quick question as well. So regarding app indexing, what happens if a user doesn't have the app installed-- he or she will never see the results for the website? Or what exactly happens?

JOHN MUELLER: I missed the first part. Can you repeat that?

MIHAI APERGHIS: What if a user doesn't have the app installed? Does the switch with the actual results go on or--

JOHN MUELLER: We did some experiments with that a while back about showing the link to the app anyway and then guiding the user through the flow through the Play store. But I think we turned that off in the meantime. It's a bit of a complicated situation where on the one hand, you want to encourage users to actually maybe look at the app, but the app has great content. But on the other hand, it's such an extra-long step to actually get to the content if you first happen to install the app, and go through the permissions, and all of that. So that's something where I don't know what the final trade off would be there.

MIHAI APERGHIS: OK, but at the moment, you need to have the app installed otherwise?

JOHN MUELLER: Yes, for the normal content-type queries, you need to have the app installed for the app name, the brand specifically, we'll point to the app engine.

MIHAI APERGHIS: OK, and if the user doesn't have the app installed, will it still work as a ranking factor?

JOHN MUELLER: No. If the app isn't installed-- if we don't show the app link in search, then we don't use that as a ranking factor.

MIHAI APERGHIS: OK, and one last one on AMP. So you mentioned AMP is at the moment, focused on publishers, and articles, something like that. Wil it be available for e-commerce websites right now?

JOHN MUELLER: Sure, you can always implement it. It's not something where we would say, you shouldn't do that. But I think at least in the beginning, it won't be visible in search like that. It might make sense that you look at it, and you say, well, people are sharing my content on Twitter or on Pinterest or wherever else, and I'd like to have that implemented properly for that. It might make sense. So it's not something you only need to focus on search for, but at least, from the search side, it's mostly kind of the newsy publisher-type content for the moment.

MIHAI APERGHIS: And you mentioned it's launching at the end of February or something like that. Is there a [INAUDIBLE] going on where maybe a publisher can sign up?

JOHN MUELLER: The AMP demo should show your content if you have everything set up. So it's And if you try that on phone or with Chrome with the emulator, you should be able to see that . If you search for something, I think "The Guardian" has it set up so if you search for something on that, you should see that in the try out.

MIHAI APERGHIS: OK, but for example, one of my clients is a publisher in the automotive industry. If he implements that now, would I be able to see it?

JOHN MUELLER: Yes. You should be able to see it in the demo. The tricky part there is that it doesn't support a site query. So you can't say everything from the site. You have to find the query that has content in this carousel.

MIHAI APERGHIS: Will try, thanks.

JOHN MUELLER: All right, let me run through the submitted questions, and then we can get back to more questions from you all afterwards. "AMP is announced for publishers. But is it also available for shopping sites?" Like I mentioned, you can implement it, but we probably won't be showing it in the first [INAUDIBLE] for these kind of sites. There are no restrictions. You can always use this kind of markup or special pages. Maybe there are other uses outside of search that makes sense for you. So I'd definitely look at that as well. "The app indexing guidelines-- we can specify title and description. Does that mean the description helps us to rank? Partially. We partially use that to understand the page a little bit better. But especially, if there's an equivalent web page, we can use that more for ranking as well. So you could always specify the title and description. The title and description are also shown for auto complete. So if you're in Chrome or in the Google Search app, and you type part of the content that you have in your app, and the user has seen that content in the app, then that's something that will also auto complete the title and the description that you have specified there. "Sometimes for apps with app indexing, it's possible to install directly from search, so you don't have to go through Google Play. When does such a feature work? And how is it possible to influence it?" As far as I know, it always goes through Google Play. So it shouldn't be that you accidentally end up installing an app without explicitly going through the normal install flow. So I suspect maybe you've seen something like this if you have the app installed already, and search wasn't aware of it, showed the Install button, and you click the Install button, and it goes directly to the app, because actually, there's nothing left to install there. But in general, it should always go through the Play Store page so that the app can be installed normally. "Do you have any case studies for app indexing for app-only content?" I don't have any specific case studies. I know there's some people who are working with some publishers to try to create some of these case studies to make it a little bit easier to understand what exactly might happen when you implement app indexing or when you do a specific scenario with app-only content. But I don't think we have any at the moment. "Is it possible to have an estimation of when app indexing for app-only content is going to be published?" I don't have anything new to announce there yet. So I assume towards the end of year this is not something that's going to happen, because we're all locking things down a little bit to avoid making changes that break things over the holidays. But I'm pretty sure towards early next year, you'll probably hear more about these kind of things. "App indexing, Fetch as Google, consistently returns partial results." I think that was you, right?

MALE SPEAKER 1: Yeah, you went through this already.

JOHN MUELLER: OK, so let me just copy the URL out so that I have this on the side. But if you can send me the link to your forum post.

MALE SPEAKER 1: I actually posted on the chat here as well.

JOHN MUELLER: OK. Let me just make sure that we pick that up, and if anything breaks, I don't lose it. Not that anything could go wrong, but better safe than sorry. "Can you provide any clarification on the use of external style sheets with AMP? From the documentation, I assume that they're not allowed and in-line style sheets are the way to go." Yes, that's correct. So with AMP, we try to make these pages as fast as possible, and that essentially means that the style sheet has to be within the AMP page directly so that the whole can be sent to the CDN and be cached on the CDN properly. So that's the primary reasoning behind that. I know some sites have gigantic style sheets, and it's really hard to refine that. But I suspect if you're going to make a really sleek AMP page, then probably there'll be ways to reduce the size of the required stylesheet there. "Google Developer Console-- now I can see a number of installs from Google Play Store, Google Search. Do you plan to add app indexing installs that are there as well?" I don't know if we're going to add that to the Developer Console there or to Search Console. So that's one thing that we have been talking about is maybe providing more of this kind of data in Search Console directly and maybe in the search analytics section where we can say, well, we showed your Install button this many times, and people clicked it this many times. But I don't know what the final plans will be. So I can't make any promise in that regard. I do know this is something that where we find metrics that we think might be useful for the app developers to understand how their app is performing. We'll try to expose that in Search Console and in the developer console as well. "With emphasis on HTTPS for websites moving into and beyond 2016, how can a user be assured of a secure experience through an app?" That's a good question. I don't know. I don't know. I know the Android team has been looking into that. But I don't know what the final outcome there is or what the general direction is there at the moment. If you're curious about this, I'd check with Android developer folks, either on Google Plus, or I believe they are also very active on Stack Exchange to kind of see what the current status is there and to maybe express some concerns if this is something that you're worried about or you think might be problematic for your site or your content. "For AMP, is content splitting inside of the domain possible-- some pages with, some pages without AMP?" Sure this is on a per URL basis, so you can have some pages use AMP. Some pages don't use AMP. That's essentially up to you. "Article rich snippet was updated. And according to this one, 14 required properties for AMP. Can I consider the old guide with three required properties still valid for non-AMP articles?" Yes. So I don't know where this link goes. But one thing I pointed people at is this version of that documentation so that you see the more rich snippets focused version of that. We're also looking at ways to update that documentation page so that it's clear which requirements are for AMP and which requirements are for general rich snippets. "I watched a Q&A on AMP with developers. There was a concern about AMP in forms. What's the position on AMP and forms markup for the future?" I don't know. The tricky part with forms is that when they are submitted, they go to some other server, essentially. So if you have your AMP pages hosted on a CDN somewhere, then from there, it'll be submitting to a server on your side, and I don't know how that connection would work. Maybe it's easier to just link to your website directly and do the form there. But I know that the AMP developers scene has been really responsive. So if you have any questions about that, there's I think a Google group around AMP, and you can just contact the AMP developers directly as well, and they've been really friendly so far. So if you're worried about that-- if this is something that's critical for your website, I'd take a look at that with them. Made it through the questions I think this is the first time in a really long time. I guess that's a sign that people are on vacation, which is also a good thing. Time to take a break in between someone. What can I do for you all here in the Hangout?

MALE SPEAKER 2: Hi, John, I also have a question on Google AMP. So I'm just wondering when checking with the demo of that particular page, it [INAUDIBLE] thing. So is it part of the-- like you're ranking things of the 10 blue links or something additional widget like the newsbots thing that will be shown to the users when it's implemented?

JOHN MUELLER: It's really hard to understand you with the noise in the background. But I think the question is with AMP, does that change the model of the 10 blue links-- something around that. Otherwise, feel free to ask again. But I guess this is something where if we can show the content directly in search, or if we can link to that content directly in search in an AMP carousel where you can swipe from one article to the next one, it does change some things in search in the sense that how should that be counted as ranking, for example. So maybe you're ranked in this AMP carousel, and you're the third one on the side, are you ranking third position or are you ranking first position because you're in this AMP carousel, and they're like normal web results below. So those are definitely kinds of questions that are open with regards to maybe Search Console how one should be looking at this data. Also, with regards to impressions, that's something that's also an interesting question for Search Console because an impression is when we see your snippet at the moment. But what happens if someone looks at your whole page in this AMP carousel is that it's somewhere between an impression and actually a click because they're not going to your site directly. But they are looking at the full content of the page that you're showing there. So it's like an almost click, but it's not really a click. So these are interesting topics and decisions that we have at the moment where we're trying to figure out how we need to count that. And that's I think just the tip of the iceberg. That's just the side with the Search Console, understanding how that fits into the model of search in general is something that's probably even more complicated, where the search quality team is looking at that and wondering, well, where does it make sense to actually rank this content. How should we show this content so that it's not a matter of who implements this markup is shown first, but rather, which of these results are most relevant for the user, and how should we show them to the user. So those are almost philosophical and very forward-looking discussions. The ones we see on our side with Search Console are more of the practical nature of what does this mean for our numbers? How should we show them to webmasters so that they understand what's actually happening, and what they need to do, how their site is performing, maybe understand where the issues are with their site and make good recommendations for the future.

MALE SPEAKER 2: Thank you.

MIHAI APERGHIS: John, you mentioned about caching, and AMP is one of these cases where probably Google is going to focus on caching those pages quite a lot and [INAUDIBLE] as well. In that case, what happens when you change or update, or something like that? Would the change be collected much later than the usual search result?

JOHN MUELLER: So the current plan is to update the AMP page immediately when we update the index page. So if we see that the index page has changed. So if you ping it with a sitemap or if you let us know about that through Search Console or whatever set up you have for letting us know about change pages, we'll pick that up. When we re-index that page, we'll immediately also re-index. The AMP page. So that's something that's really tightly tied together so that both of these versions are essentially as the same as possible. Sometimes there is still this skew between letting us know about our page and actually us indexing it. So that time frame is still open, but we really planned to make it almost immediate so it's a matter of seconds after we index the page that we update the AMP page as well.

MIHAI APERGHIS: OK, and will it be possible to submit to AMP sitemaps in Search Console?

JOHN MUELLER: That wouldn't be necessary, because then you'd essentially just need to ping the HTML pages. And when we re-crawl those HTML pages for re-indexing, we'll pick up the AMP page directly. So you don't need to manually push the AMP pages. You just need to let us know about the HTML. We'll see the link to the AMP page and follow that immediately.

MIHAI APERGHIS: Right, and the rel=amphtml.



MALE SPEAKER 2: John, do you we have to include the AMP URL in the site [INAUDIBLE] just like the canonical version that [INAUDIBLE] site? Is it required or something? And can we just skip that part and Google will take it from the [INAUDIBLE] source code page?

JOHN MUELLER: Yeah, we take it from the-- we take the link from the page directly. You don't need to submit it as sitemap page. It's something you could submit with a sitemap page, but I don't think it would have any real effect because it has a rel canonical back to the HTML page. So we would crawl this AMP page. It's still a valid HTML page. So you can look at in a browser. So theoretically, we could index it separately. But since it has a rel canonical back to your main page, that's the one that we would focus on. I see one more question that was just submitted. "I just installed the AMP plug-in for WordPress, and it created an AMP HTML equivalent URL with /amp appended to the end of the URL. Is there potential for duplicate content issues in search?" No. Like I mentioned, it should have the rel canonical pointing at the web page. So it wouldn't really have duplicate content issues there if it's implemented properly. And from our side, for AMP content, we require this rel canonical. So if we don't see the rel canonical, we won't pick up that AMP page and to reuse it anywhere else. It might be that other services look at it a little bit differently. But at least from our point of view, we're focusing on the main HTML page as the one that we're indexing. We understand the link to the AMP page. We will cache and serve the AMP page separately. But we'll really focus on the HTML page. So you don't need to do link building for your AMP pages. You don't need to put them in sitemap files. You don't need to link to them internally. Essentially, you focus on your normal website the way that you always have it. Let us know about the connection to the AMP page, and we'll take it from there.

MALE SPEAKER 1: Hi, John, another question. In the documentation, I noticed that lately, it's changed for app indexing that if you do not recognize the fact that the website should have an alternative length to the app. And instead, I am seeing mostly that it's talking about support HTTP URLs anywhere. Is there any advantages to having the deep links with the HTTP schema as opposed to using our own schema?

JOHN MUELLER: I think when you recently made that switch, to be a little bit more consistent and to make it a little bit easier to pick up and recognize all of this app content, but you can still use your custom schema as well and link to that as well. So that's something where we're trying to change the recommendations a little bit to be just a little bit more consistent and to make it a little bit easier for us to also understand this web content is equivalent to this app content, even if we don't explicitly see the link between those two pages.

MALE SPEAKER 1: So would you recommend the switching to using to supporting HTTP deep linking and also changing the alternate link in the website? Would that help in search results capability?

JOHN MUELLER: I don't think that would make any difference at the moment. So if you're creating a new app, I'd recommend going that route. But if you have an existing app, I wouldn't go through and change all of those URLs. That's a lot of work, a lot of potential for error as well. So that's not something where I'd say you should do this just to be in line with our current setup.

MALE SPEAKER 1: Right, got it.

JOHN MUELLER: OK, one more question here. "Any recommendation on how to properly index apps where the content is based on the user's location, for example, delivery apps?" That's really tricky because I think essentially what's happening there is the app URL is really dependent on the user's location. And that's something where you end up with millions of URLs based on maybe the geographic location or the geographic area that you have the user located in. So that's something where I don't have any direct answer at the moment. I kind of think about this regarding how a user might see that in search. And maybe it make sense to have individual regional pages that could be found on your website and the app that go to the same thing. But having for every possible longitude and latitude pair a specific app URL install indexed, that's crawled and indexed on your website as well, that's just from a technical point of view, probably not feasible. So that's something where you probably have to find the middle ground and say for these specific regions, I'll have specific pages and web pages and AMP pages that are equivalent, and on a more fine-grained scale, I won't have those pages actually indexable. Maybe I'll have them available in the app directly. But it's not set up in a way that they would actually be indexed for web search independently.

MIHAI APERGHIS: John, regarding AMP pages, is there any potential plans making all of the Google results load AMP versions of pages instead of sending the user to the website?

JOHN MUELLER: I think there were discussions about this in the beginning. I don't know what the current status is there. So like the mobile, separate mobile web pages where you would go directly to the mobile pages, you would go directly to the AMP pages instead. I can definitely see that making sense in some situations. I think it might be a bit confusing or hard to figure out how to balance that so you have your website, you have your separate mobile pages, and then you have your separate AMP pages, and which one should we be linking to at which point. It's almost like a battle between the mobile and the AMP pages. And I suspect we probably just want to figure out how we need to handle AMP pages in general first and then maybe over time it makes sense to find a way to either let the webmaster let us know-- point them to this page instead of that page. Or maybe we'll recognize that more automatically which one actually works better for the specific user. But that's almost a philosophical question for the longer mid-term future where I could definitely see things going in different directions.

MIHAI APERGHIS: So at least for the short term, it's only going to be to be available console on top of the--

JOHN MUELLER: I think so, yeah. For the newsy-type content, that's where at least we think in the moment, it make sense to do that. There's some interesting aspects there that also I guess help play into this. On one hand, you can still get this content implemented on other services. The other neat thing here is, of course, the whole analytics and ads tie in in that you can show ads on these AMP pages. And you can have analytics on these AMP pages so you can track them on your site as well. So you kind of see where they end up being uses. So if you want to be the first person to implement AMP on an e-commerce site, and you have a bunch of users, you can track the analytics and see is this actually being used somewhere. Is this showing up on Twitter, or Pinterest, or wherever? That might be something that you wouldn't have available otherwise with normal web content.

MIHAI APERGHIS: And are there plans to integrate more in Search Console? Like see whether maybe it has some errors regarding the implementation?

JOHN MUELLER: Probably, yeah. It kind of makes sense there because that's where we're crawling and indexing stuff for the web. And this is something we're trying to pick up for the web. So that would be a good match I think.

MIHAI APERGHIS: OK, and until then we have development=1.



JOHN MUELLER: Yeah. All right. It's been really great today. I have to head out a little bit earlier today. We have one more Hangout planned I think on the 29th, so just before the new year. If any of you are crazy enough to actually do something almost work-related, talk about websites, crawling and indexing, feel free to jump on in. I don't have any topic for the Hangout. So submit your questions. Maybe we'll have time to look at individual sites as well-- see how many people actually show up. And otherwise, I wish you a great Christmas if you're celebrating Christmas and Happy New Year. Maybe see you again in one of the future Hangouts.

MIHAI APERGHIS: Happy Holidays, John.

MALE SPEAKER 3: Thanks, John.

JOHN MUELLER: Bye everyone.

MALE SPEAKER 4: Thank you and goodnight, John. | Copyright 2019