 All right. Welcome, everyone, to today's Google Webmaster Central Office Hours Hangouts. My name is John Mueller. I'm a webmaster trends analyst here at Google in Switzerland. And part of what we do is these Webmaster Office Hours where webmasters, SEOs, publishers can join in and ask their web search website Google-related questions. As always, if there are any of you that are kind of new to these Hangouts that want to get started with the first question, feel free to jump on in. John, I'm not new, but can I ask a question? All right, go for it. OK, I want to step in the turn of somebody that is new. But one question that I have is related with what is there an equivalent way of performing what would be fetched as Google, but doing through the Search Console API or with sending a PIM to pub, sub, be equivalent to that? So in which sense the fetch is Google? To submit to the index page that was updated or just created? OK, to submit to the index. OK, that's something you could do with a sitemap file, with an RSS feed, for example. Both of those essentially go through very similar paths internally, where if you submit a changed sitemap file or an updated RSS feed and you ping that to Google, then we'll check that file. And if there's anything new there, we'll try to crawl that fairly quickly. So that's kind of the easiest way to automate that. And most blogs, most CMSs create RSS feeds automatically. So that kind of just works by default. And if you want to do it with a sitemap and sit, you can also do that, of course. Yeah, so when you say a ping is pinging the pub of a bug or something else. Yeah, I mean, if you submit an RSS feed through PubSubHubbub, then that works the same way. Yeah, OK, thanks. Sure. If you just want to test if Google can access a URL, we just released an API for the URL testing tool for mobile-friendly tests. So it's not the desktop fetch, but it's the mobile fetch, and it'll tell you if it worked. So it's like notifying Google that there is a request to submit to the index. It doesn't do submit to index. It's really only to test if Google can crawl the URL and render it. OK. All right. Anything else from some of the new faces here? Yeah, John, can you hear me? Yes. OK, my name is Shanley. I'm with Sharp Health Care. And we've got an Angular site. I know I've listened to your Angular Connect video. I'm working with actually Igor, Jules, Rob, Stephen. They did kind of a full review of our site. And I think Rob actually reached out to you about our site because we've got some really mixed up entries in our index. We've got search terms that don't match a title, that don't match the description. And the URL that it's pointed to don't even match the title and description that's being shown. So it's kind of mixed up all over the place. We worked with Jeff Cross and Victor Safken to put in a resolver to make sure that we weren't introducing some sort of race condition that the bot was able to run into. But from there out, we're trying to figure out what we need to do to kind of clean up our index. It seems like when we use Fetch as Google, it can see it. We have some pages that are being indexed. But it's really just a matter of how do we clean up our index and where do we go from there? Yeah, I'm not completely sure what happened with those pages. So I saw some of those as well. And I suspect what is happening there is that we fetched HTML for those pages, and we started processing them somewhat from with a time offset, I guess. And perhaps the content that we pulled from the server afterwards wasn't really matching the original URL that we were trying to fetch. So kind of like this race condition that you mentioned. So that's something I suspect might have been happening there. It's really hard to tell, especially if you've already done some things to kind of clean that up. The important thing to keep in mind is that when we fetch the HTML page for any URL and the rendering, that's not done exactly at the same time. So it might be that we fetch the HTML page one day and then we wait a day or so and then we actually do the rendering. So if there is anything that changes with the content where you expect kind of like a session to stay in place for a while, then that's something that might break with rendering, because we kind of have this time difference between the two. Also, if you're passing any information along outside of URLs, then that's something that might also get lost. So for example, if you're using cookies or some other kind of session information and trying to pass that on to embedded resources or to server requests, then it's possible that those will get lost along the way. So it's really important that any kind of embedded content is clearly identified by the URL so that we can fetch that URL at some later time and still get the same content and we can reuse that for indexing. So I suspect something like that might have been happening there. If that's cleaned up, if you can do, for example, a site query for your site and do a date restrict and say just for the last 24 hours and those pages look good, then that's really more a matter of things kind of settling down and being recrawled and re-indexed. And for that, it's helpful to have a sitemap file where you specify a new change date. So that we know that these pages changed and that we can recrawl those. And to make sure that your server isn't limited by resources so that we can really crawl at high speed. If you're seeing that we're not crawling fast enough or you think your server can definitely handle a much higher load, there is a form that's linked in the Help Center for the crawl rate help article. And on there, you can send some information to the Googlebot engineers and kind of let them know about, hey, my site isn't being crawled as fast as it could be and we have this problem and it would be really helpful if we could crawl it a little bit faster. And usually the Googlebot engineers will be able to look at that and say, OK, we can increase the crawl rate here by, I don't know, factor two or factor three or whatever you specified there. So those are kind of the things that I would aim for there. OK, great. Just two quick questions that are along the same line. One was we saw that the bot actually put in a Chicago zip code into one of our variables. It looked like the bot had actually put in a New York one, a Chicago Denver and Los Angeles. Now is that common that the bot will do that when it sees a Z variable or some sort of zip code variable in a URL pattern? So to try to discover new HTML pages? Yeah, I'm not actually sure where this came from because we're a San Diego-based company. And when we actually looked at the server request, the endpoint that it was hitting, that the bot was hitting, was requesting. Basically, it was like our search and then the parameter was zip code equals some Chicago zip code. And we didn't know. Initially, we thought maybe it was geolocated. But is that common that the bot would do that? I wouldn't say it's common. But especially when we run across a site where we think we could find more content and we find something like a search form, then we might try different URL variations or search variations to see is there more content that we can actually discover through search that's linked from the search results. So that's something that can happen. I think it's not that common because for the most part, we can crawl normal websites and pick up all of that content. But sometimes that does happen. OK. And then the last question, and this is about trying to help clean up these indexed files. And that would be, when you have a page that has various parameters, say you've got a specialty and whatnot, should we canonicalize those pages? Would that help out? Or should we use the Search Console and the URL parameter management there to basically say which ones are more important? Or should we do a combination thereof? Or should we just let it do its own thing? It kind of depends on what the different URL parameters are kind of pulling up. So with a rel canonical, what happens is we lose the other variations. So for instance, if you, I don't know. I don't know the specific use case on your side. But for instance, if you have one clinic and you have multiple doctor pages and they all work at the same clinic and you set the rel canonical from the doctor pages to the clinic home page, essentially, then what would happen there is we would lose all of those individual doctor pages. So if someone were to search for those specifically, we wouldn't have them. We wouldn't know that they're kind of associated with this specific clinic. So if there's something kind of unique on those pages, then I wouldn't try to pull them together. If it's just like the same content in a different order or just a variation of the same content, then that's a use case where a rel canonical would make sense. OK, OK. All right, thanks for your time, John. I appreciate it. Sure, no problem, thanks for joining. All right, let me run through some of the questions that were submitted. And we can get back to more questions from you all towards the end again. I'd love it if someone from Google could chime in on the topic of manipulating the browser back button. As I see it, more and more sites doing it and ranking well on pages where they apply this tactic, manipulating the back button. I know from looking a bit deeper that Google is giving a fair amount of way to page bounce rates. And by manipulating the browser back button, you're essentially telling Google, hey, no one bounces back from this page. So that's usually something we tend not to have too much problem with from a search point of view. It's definitely not something where you're doing your users a favor by kind of blocking their normal navigation within your website or across different pages on the web. So that's something where I tend to shy away from looking at that too much or implementing that too much. But from a search point of view, I don't think that would cause any problems. There's a link to a forum thread here. I'll try to take a look at that afterwards as well. Maybe there's something I can add to the forum thread there. Why do directories such as thumbtack appear in top 10 search results for service related searches having little or no content to speak of versus standalone websites having optimized content? This is, I guess, always a tricky question because there are essentially two different approaches of providing kind of content for users. On the one hand, some sites combine different kinds of content and show that to users. And that can be useful for users as well. And other sites are just about one specific piece of that topic, which can also be useful for users as well. So it kind of depends on what users are trying to search for. And this is something where our algorithms are always trying to figure out what is it that this person is actually searching for. Are they looking for a list of, I don't know, restaurants? Or are they looking for one specific restaurant? And both are very relevant use cases. And I don't think it would make sense for Google to say, well, we will always show lists of restaurants or we will always show individual restaurants. So this is something where I guess the question, why do you show up? It's because sometimes people do appreciate finding these kind of directories or lists of individual places in the search results. How does Google handle 303, 307, and 308 redirects? What's up with this? So I don't know. The question of redirect is something that always comes up every now and then. From Google's side, we differentiate, essentially, between temporary and permit-type redirects. And we try to treat them in the way that kind of semantically makes sense. So when it comes to a temporary redirect, we will tend to index more the redirecting page. So for example, a really common use case for temporary redirect, which would be normal, would be to redirect from your home page to some lower-level detail page. So for example, if your CMS is set up in a complicated way that has this weird path, then you might be redirecting your home page to that detail page, which is actually your home page. And what would happen there is we would index the home page, or we would try to index the content with the URL of the home page, because that's the more relevant one for the user. On the other hand, there are also permanent redirects, where we know that, essentially, everything has really moved to the destination page, and then we'll tend to index the destination page more. And it's not a matter of passing page rank or passing signals or anything. It's really just a matter of this content we were able to pick up while crawling, which URL do we use to show it in the search results? And that's something that kind of comes into play with these other kinds of redirects as well, where sometimes it's clear that this is more of a temporary redirect, and sometimes it's clear that this is more of a permanent redirect. And some of these redirect types can change over time. So if we see a temporary redirect happening all the time, from maybe one domain to another domain, then we'll probably understand that you probably meant to use a permanent redirect, or for some technical reason, maybe you weren't able to use a permanent redirect, and we'll treat it as a permanent redirect after some time. So it's really not so much a matter of which redirect type do I use to get the most SEO value out of it, but rather which redirect type do I use that is actually the correct type to use in this specific situation on the one hand for users so that they understand what is happening there. Sometimes browsers need a specific type of redirect as well. On the other hand, with regards to which URL you want to have indexed. And for picking the URL that you want to have indexed, we use a number of different factors as well. So even if you need to use maybe a temporary redirect that you want, the destination page index, you can give us that information through other means as well, such as the rel canonical, such as the internal linking, the sitement file, all of those methods help us to understand, well, which of these URLs is actually the one that you want to have used to be shown in the search results? How important is a good informative 404 page? Does it carry any weight in the algorithms? From Google's point of view, we don't look at any of the content on the 404 page. So that's something where, at least on our side, we don't care what you put on your 404 page. Users obviously might care. If the 404 page is essentially empty, then they might get lost and go somewhere else to complete the tasks that they wanted to do. So from our side, it's not that you need to put links to specific pieces of content or that you need to use rel canonical or anything like that. If it's a 404, if it's a 410, then we understand that there's nothing of value for us to index here, nothing that we can index. So we won't use that content in any way. So with that in mind, make sure that the 404 page really works for your users because those are the ones that we'll actually try to use those pages. When I search my brand name on Google mobile search, I see a carousel from my home page list. This is nice, but the problem is the images are always the same or broken. I couldn't find where Google is getting those images. Is there a way to mark specific images to the carousel? Well, I think I saw your post in the forum about that as well. So what I would do there is look at the markup that I believe it's the news article or the blog posting schema.org markup that you can use on pages and wrap your images, the ones that you do want to have shown with the appropriate image markup there so that we can pick up those images and we understand that this is actually the relevant image to show for this specific URL. How can I definitely see non-personalized results in Google search? Is there a way to do this without disabling or removing cookies completely? From what I understand, this is really tricky thing to do because there is so much personalization happening across Google search that it's really hard to say this is the global non-personalized search results because if there were such a way to get that information, then that would not be something that people would see. Because if everyone has their own personalized search results based on things like geo-targeting, based on their search history, other aspects, then that's something where nobody would be seeing these generic search results anyway. So they wouldn't be representative of anything particular. So what I would recommend doing there is on the one hand, I'm using an incognito window that doesn't have any search cookies. That gives you a little bit more information about what users in your region would be seeing in the search results. What you can also do is look at what users in other countries would be seeing. So I believe that's the GL parameter in the URL for Google search, where you can say GL equals, I don't know, UK for the UK-based search results to see what users in those countries would be seeing. But as far as I know, there is no easy way to say, well, these are the completely unpersonalized, undeo-targeted search results, at least not that I'm aware of. Maybe there is a fancy trick that someone knows. If there is something that you're aware of, feel free to add that to the comments. Let's see, until recently, I've been witnessing constant fluctuations of rankings for keyword searches like car insurance or travel insurance performed within a short duration of time, all within the same location, on multiple browsers. What's up with that? So I don't know about these specific queries or about the specific searches that you are doing, but we do run experiments all the time. So pretty much every time you search, you're in a different kind of experiment within Google. And some of those are just small UI changes where maybe we shift things around by a subtle number of pixels, or add a border, or change the color slightly. Some of those experiments are really ranking experiments where we try things out, different ranking results, to see what makes sense. That's one thing you might be seeing there. Another aspect is that we have different data centers where maybe we'll route your query to this data center because the other one is overloaded. And you might see different results from that as well. And I guess the other thing is that the web changes all the time as well. So as we re-crawl and re-index things, then it's very possible that you might see changes in the search results there too. So all of these things kind of add up. And it's from our point, from our side, it's so that we can't guarantee any specific ranking in the search results. So if your site was ranking number one today, then maybe it'll be ranking number two, or number three, or number 20 tomorrow, or maybe even if you tried a little bit later. So these kind of fluctuations are normal from our point of view. It's not a sign that anything is broken, that you're doing anything wrong. It can happen that you see strong fluctuations. It can happen that you don't see any fluctuations for a fairly long period of time too. The website I'm working on is 25 million pages, reading the logs, the site maps, and so on. I notice that the crawl is not efficient. We have site maps, good links, et cetera. 6 million URLs are crawled per day. 80% of this crawl is concerned with verifications made by Google for Google Shopping. Is it possible that my crawl budget is used mainly for Google Shopping verifications? How can I improve that? So I don't know specifically how much Google Shopping would be crawling in a normal situation. I believe they do check the landing pages to double check what is there. I don't know how much that would be in kind of a normal, generic situation. So that's kind of on the side. The crawling that's done, I believe, with the Google Shopping bot is also a part of the normal crawl budget that we have. Similar, if you have AdWords and you have AdWord landing pages and the Google AdSpot checks those pages as well, then that's something that also kind of goes into this big pot of crawl budget that we use for a site. So that said, if you're seeing a large part of your crawl really associated with Google Shopping, then that does mean that we kind of have to limit the crawling that we do for normal web search. With regards to a website of that size, that's hard to say how much crawling would be necessary, for example. So for example, if it's an e-commerce site and a lot of the content doesn't change because the products stay the same for a longer period of time, then from a web search point of view, it might be OK to say we don't need to re-crawl every page every day. Just from re-crawling a page doesn't necessarily mean that we will rank it higher in the search results. So that's something where you don't need to have a specific amount of crawling in order to be visible in the search results. On the other hand, if your content is changing constantly, if it's changing every day and we're only crawling a really small part of that, then that's something that might be worth kind of digging into more and kind of figuring out what can I do to make sure that my constantly changed content is being picked up properly by Google in a more or less efficient way. Another thing you can also do is if you're seeing that this crawling ratio between the different types of crawling that Google does is somehow illogical or doesn't really make sense from your point of view and is maybe causing problems on your server even, then you can also use that form that's linked from the crawl rate setting help center page where you can let the Googlebot engineers know and kind of tell them what you're observing with regards to crawling. And usually, they'll be able to take that information and look around internally and see, hey, is Google Shopping crawling properly or is there something crazy happening here? Or maybe there is something that they can even let you know about to give you some information back. Maybe there are some weird URL parameter things that you're doing on your site that you don't realize that is kind of blowing up the amount of URLs that we need to crawl either for web search or for the Google Shopping side. So that's something that might be worth doing there too. All right, let's see. Can new pages from a site rank well for medium to high search volume pages, keywords? Sure. Theoretically, that's definitely possible. It's not the case that we would say that this keyword is classified in this specific way and therefore only pages that have achieved this age and this number of links and this number of other factors can show up for those kind of queries. It's really the case that we use a lot of different factors to determine crawling, indexing, and ranking. And sometimes it can happen that a really new page is suddenly really important for us and that we would rank it really high even for keywords that are fairly competitive. So that's theoretically possible. On the other hand, if the next question is, how can I do that? I don't have a magic answer for you there. That's something that can be tricky, that can be hard to do, that can be something that you can't directly kind of influence from the SEO side of things as well. So a common use case here that happens every now and then is that something suddenly shows up in the news. So maybe it's a topic that's always been kind of talked about. There are lots of people searching for that information. But suddenly something happens and information about a specific aspect of that topic is in the news and everyone is searching for something that's really on maybe just one page on the internet where it's really new. And then it's important for algorithms to recognize that and say, well, this seems to be something that's really critical and really important at the moment. We really need to make sure that we can show this in search. But for the most part, that's not something that you can tweak with the HTML on your pages to make that happen. Oh, John, with that question, we're really high. So with the context of the same question, I just want to understand when you send it when somebody's that news pops up or maybe somebody's actually talking about the same topic. Let's say, I mean, some publishers write about something going on that's on Valentine's Day. So I mean, we observe that most of the post pages mostly are dominated by the news itself. So I mean, for this kind of context, I mean, how we can make sure that for our website that we're actually banking well on the page itself. And then suddenly the news websites comes up with a new article based on how they can actually just leverage the kind of traffic they can catch up on these specific terms. Then what should the website do in that case? I mean, we just suddenly just go from the page one and that's two and we just lost all of the traffic. It's really hard to understand you, lots of background noise. But I think you're asking, your page is already ranking there very well. And you expect news websites or something else to kind of suddenly jump up and become more relevant and displace you in those higher rankings. And that's not something where you can put a meta tag on your page and say, I always want to rank in the same place. That's something where our algorithms do try to look at everything overall. And sometimes that's something that you can jump on that wave as well and say, well, this is a really important tweak on this topic. And I can provide that information just as well. And Google will look at your pages and say, well, this is actually just as newsworthy as some of the other sites. So that's something that might be possible sometimes. Obviously, it's not easy. It's not something where you can just tweak things on your pages and say, well, I want to remain in this position. Rankings will always fluctuate. And sometimes things will happen where your site will be displaced by others that we think are perhaps more timely or more relevant for this specific use case where people are searching on a specific date. So no magic answer for you there. Sorry. Should I be worried about 404 cache pages for domain alternates? That 301 redirect to a page that caches just fine? For example, HTTPS www.domain.com works, the cache is a 404. Usually, that's less of a problem. So when it comes to the cache page, usually we try to pick the canonical version and just index that or just cache that version in the cache. So that's something that is more of a technical thing on our side than something that would be indicative of anything on your side with regards to ranking. So in particular, the cache is kind of separate from the rest of the search results. And it could happen, for example, that the cache page is not quite the same date as the version that we show in the search results. I generally wouldn't worry about the cache page if your pages are showing up normally in the search results. Another aspect with regards to the cache page that comes up every now and then is if you're using a JavaScript framework like Angular or anything else that's kind of like a single page app architecture, then what would happen there is that the cache page would reflect the HTML page. So not the rendered version, but rather the raw HTML page that we pick up when we crawl that page. So that's something where you might see complete mismatch between the cache version and the actual index version. I don't know if that applies in your specific situation, but if your site does a lot of JavaScript, then that's something to kind of keep in mind. How should we best test individual movie showing times using schema on cinema movie theater websites? Is there any advantage to doing so? We'd like to appear in the carousel, I guess. Should we be using AMP? John, I can clarify that question, I think, a little bit for you. We do a lot of sites for cinemas. And we've managed to get in the one box. So we solved that problem. I think you might remember that a few months back. But now we're wondering if there's any advantage to adding a screening event, data type to actual movie pages. Other, there's carousel results for movies that link to Netflix and so on and so forth. But is there a business case to taking the time to add the schema markup to each individual movie page? I don't know if Google treats those any differently or looks at that data type. So I'm just wondering if it's worth the effort. I don't think we would use that at the moment. So that's something where, from a practical point of view, what I might do there is mark up a small subset of your pages like that and see how that happens, how that works out over time. But since we don't use that by default, it's probably not worth the time and effort to implement that across the whole site and kind of expect any kind of ROI on that. Kind of trying things out, I think, is always a good idea. But I wouldn't expect that to change anything. Excellent. One other question I've got is that we have a lot of, we've got some duplicate content on these sites because the movie descriptions come in from a third-party feed. So essentially, for each cinema location, the movie description is duplicate across lots of different location pages. So we have a cinema, say, in London that has the same movie description as a cinema in Bristol or what have you. And I'm just, these pages are ranking individually. But I'm just wondering if there's a way to ensure that they rank locally for somebody who's in London or a different region of London. We get three cinemas in London, for example. Can't, you know, if we put the name address postcode on those listings pages for the individual movies, is it more likely that they'll show up in the localized geographical results based on IP? Or is it just a case of trying to optimize titles and meta descriptions for the locations? Yeah, so the local search results would mostly come from the Google local pages. So I assume for the movie theaters, you have the local listings set up already to kind of let us know that this movie theater is in this location. I don't know how we would combine that with the individual movie items, though. So that's possible that I don't really know. That's an interesting question. So maybe test it. Yeah, I mean, that's something you can definitely also try out because those are easy things to do. So trying out to see which titles and meta descriptions work well for the site with regards to ranking is definitely worth trying out, but it's also worth trying out to see how users react to that. So if you have different variations of titles and descriptions, then maybe some users find those a little bit easier to understand and go through those pages directly. There was an interesting study, I think in the last couple of weeks around testing meta descriptions and titles for SEO, that might be something to kind of look up and see how they did it there. And maybe that's something that you can try out on your pages as well. I would definitely also make sure that you have the location on the individual pages, of course. So maybe in the footer or somewhere on the side where you have the address of the location so that we can at least have this connection between this is the movie and this is the location. And if our algorithms can combine those two to pick the right version to show, then that's great. If not, at least users also know where everything is. Okay, and would you recommend marking that up using the schema data type? Yeah, yeah, the location definitely. Fantastic, that's great, John, thanks. All right, what could be the reason despite relatively good and useful content that pages don't get to rank on search? What should webmasters do in such cases? Nobody wanted to link to a new website and social links aren't considered for ranking. Yeah, that's always a tricky situation, I guess. So from our side, one of the things that I think is kind of important is that we look at a number of factors when it comes to crawling and indexing and ranking. So it's not the case that you always need to go out and get links to these pages. Obviously, if we see recommendations in a form of links, then that's something that helps us to understand those sites a little bit better. But the other thing that I would also look at here is if you have reasonable content and it's kind of relatively useful just as well as all of the other content out there that's on that topic, then from our point of view, it doesn't make that much sense to say, well, we have 10 pages that are like this and one page that is kind of the same, we should show that one instead of one of the other ones. So what you really need to be aiming for in an ideal situation is to make sure that your website overall across the board is really significantly better than all of the other ones. So that, for example, when you post in the help forum to get more advice on this, it's clear to everyone who looks at your site, who looks at those search results that actually your site is the one that should be ranking number one by far and all of the other ones can disappear from search and this would be the perfect result for users. So that's the kind of situation where when people in the help forum see it like that and when we pass that on to the engineers and the engineers look at that and say, well, this is a bug on our side. It's our fault that we're not ranking your site number one. On the other hand, if your site is just as good as the others and it's kind of relatively useful and relevant, then the engineers will look at that and say, well, lots of sites want to rank a little bit higher. We can't tweak our search results just to show this side a little bit higher because it's kind of the same as all of the other ones. So that's something where you really need to make sure that what you're providing is a step above everything else. On the one hand, for escalations for us, but also, of course, for users. So if users see your page and they see that, oh, this is really a step above everything else that I've been using so far, then they'll be much more likely to recommend it to other people, even if it's a new site, maybe even because it's a new site, because it's something that they haven't seen before. So that's kind of what I would aim for there. Obviously, there's no magic trick to making sure that your site is a significant step above everything else. Yes. Hi. Hi. So my question is about how Google reads the content within Bootstrap Modals. We have a large amount of help and FAQ content that are mostly definite that are available to users on pages. And I was wondering a couple of things about this. One, does the content in the modal skew the relevance for the page's main content? Because in many cases, the modal content is more voluminous than the page content. And secondly, is the content in the modal seen as a duplicate content? And if they do pose a risk for us, what do you recommend? So what kind of modal content would that be? Mostly definitions. They would be the same definitions about the topic on the page. OK. So you kind of have the primary content and then a block with general definitions, general information about the topic? Pretty much, yeah. OK. From our point of view, that's perfectly fine. That's not something that you'd need to hide or kind of change the text on these pages in any way. It's important for us that these pages can't stand on their own. And if there are individual blocks of text on these pages that are duplicated across different parts of the website, that's perfectly fine. So that's not something that you'd need to kind of hide or remove. Even if that duplicated block of text is fairly bulky, if there's a lot of text in there, that's also fine. From our side, what happens from a practical point of view is we'll try to index these pages individually, because we see that overall this page is kind of unique. And if someone is searching for part of the primary content, it's really easy for us to say, well, this is the primary content. We can rank it like that. If someone is searching for something within this duplicated block of text, then we'll generally take one of those pages from the site and show that in the search results. And which one we choose is sometimes a bit tricky. But usually, since it's the same block of text duplicated across the rest of the website, it's less of an issue for the user or for you which one of these pages that we choose. So for kind of the normal search results that you're trying to achieve there, that's absolutely no problem at all. If you want people to also find your pages for this kind of duplicated block of text, what you can also do is just make a separate page for that duplicated block of text that maybe goes into it a little bit more in detail so that we know that actually for people looking for a definition or something like that, this more generic page is the right one to show. All right, let's see. Here's a question about the mobile-first index. What will happen to external links pointing to a URL? The canonical is still desktop, while the desktop ranking will depend on the mobile content. Links will be canonical of which version? So what will happen with the mobile-first index is that we'll essentially take the mobile version of a page and try to index that, because most of the people are using mobile phones at the moment, and we want to make sure that our search results reflect what most of the people would see when they go to a page. And with regards to canonicalization and links, we would essentially, in a situation where you have separate URLs for mobile, we would switch that and pick the mobile version as a canonical. And that would mean that we would forward all of the signals that went to the desktop version to the mobile version as well. So it's not the case that you need to change all of the external links and all of the internal links to go to the mobile version. We'll do that for you. Our goal with the mobile-first indexing change is really to keep it as lightweight as possible for webmasters so that you don't need to kind of think about what kind of linking changes do I have to change, or what kind of canonical changes do I have to make on my website that we'll be able to essentially do all of that for you. So that's- Hi, John. Yes. Sorry, I've pasted on the forum regarding the SERP changes on the third and the eighth of this month. And if there's any kind of feedback on any algorithm changes that have happened, because it's been picked up by many of the kind of forums, et cetera, around quite big changes in the SERP. So I don't know if you've got any feedback. We don't have anything specific to that. So it's not, I don't know, like a Panda update or Penguin update or anything crazy like that. These are essentially just normal changes that we always make. Sometimes they come together and they all go out at the same time. And it looks like something bigger. But for the most part, these are just normal quality, normal ranking changes that we would usually make. So no magic answer for you there. Sorry. John, thanks for the original question you were answering. If your site's responsive, then you need to not worry and do nothing, presumably, with the mobile first. Exactly, yeah. Makes it a lot easier. So we've been telling people to go responsive. But of course, we support those other setups as well. If you're using kind of dynamic serving or you're serving different content, then you need to watch out for, I guess, a different set of issues with regards to making sure that you have the same content that you're providing with dynamic serving, so the images, the videos, all of the embedded content as well. If you're using separate URLs, then you have kind of this problem with the separate URLs and you would see the change for mobile indexing a little bit more visually in the search results because we also have separate URLs that we could show there. But if you're unresponsive, if you've set everything up for responsive, then you essentially don't need to make any changes at all because all of the content is already there. All of the markup is there. The videos, the images, they're available for us to kind of pick up and use automatically. So if you're still kind of moving to mobile-friendly page and you don't know which one to choose, then I'd still recommend responsive. And if we're moving from currently in the UK, we have mobile version and a desktop version. But within the next two or three months, we're going to move to responsive. We'll go from two URLs to one. So I think at the moment the desktop is the canonical version. Will we see any dips? Do you think whereby the mobile was probably getting a bit of a better result in mobile? But the canonical was going to desktop, but now we're moving to responsive. So Google will just immediately say, OK, well, they're all just as good as each other. I assume there's going to be some fluctuation anyway. Yeah, I think the fluctuation that you would see in a case like that is more based on essentially doing a redesign of your website. And some of the content might be changing. Some of the internal linking might be changing. The layout might be changing subtly. And those are changes that we would pick up from an SEO point of view as well. So for example, if you've never marked up your headings and suddenly your headings are marked up, then that gives us a little bit more information to understand those pages a bit better, which could result in positive changes in the search results. On the other hand, if you're changing your layout so that all of your headings are disappearing and a lot of your content is being moved into an image instead of in text form, then obviously that makes it harder. So just shifting from separate URLs to responsive, if you kept everything exactly the same, you probably wouldn't see much of a change. But if you do make layout changes along the way, which is probably the more usual situation, then that's something where you would potentially see changes in search based on those layout changes. But not much of that would be based on the fact you're going from two URLs to one, and then suddenly you have 5,301s from the M to the. That doesn't matter. No. OK. John, one last thing I mean. If the mobile first index is going to happen, I mean, for example, let's take an example of the e-commerce website. So I mean, with our current website, with our category, which is mostly you can see listing pages, it's like, I mean, we have a lot of spaces, and we can just go around with the content, which is usually for the user. But when it goes to the mobile first, it might be having, you can say, the space crunch over there, which is only going to be put on products. So how we will see this kind of change, and then switching from having a whole content, having pages, and it goes into one of the products specific listing. So how we should go about this thing, how we can make our page more useful, content rich, in that case. Really hard to understand you with the background noise. I think what you're asking is you have product listing pages, and on desktop you see a lot more different products on there, and on mobile you have a kind of a simplified view. How does that change with the mobile first index? And from our point of view, of course, if the mobile version has less content, then we would be indexing less content. So if the mobile version is limited in any way, then that's what we would use for kind of the normal generic index as well, the limited mobile version. So if you really have significant differences with regards to the content or the functionality that you have on the mobile pages, then that's something I'd recommend cleaning up. On the one hand, before we make bigger changes with the mobile first index, but also for your users. At least from just speaking for myself, this is something that I find really frustrating, where maybe I look at something on my laptop or on desktop and see, oh, this is actually a good website. And I'll bookmark it or I send it to myself by email so that I can take a look later on. And then I look at it on my phone and I can't do anything that I was seeing on my desktop version. So kind of this drop of functionality, this drop of content is something that's sometimes really frustrating with mobile versions. And since the majority of our users are using smartphones nowadays in search, they see this kind of frustrating difference as well all the time. So that's something that I would really recommend cleaning up and making sure that from a functionality point of view, from a content point of view, your mobile pages are as equivalent as possible to your desktop pages. And obviously with the responsive design, that's sometimes a lot easier to do because the functionality is there by default. So that's something where if you're aware of this difference between your mobile and your desktop pages, then that's something I would address, regardless of any mobile first indexing change that's happening on our side. For example, really common situation is that comments are not available on the mobile version. You can look at a news article on mobile, but you can't comment on it. Where on the other hand, a lot of people are using mobile phones to actually read news articles, and they would be in that perfect kind of state of mind to actually leave a comment, but they can't do that because you don't provide the functionality on mobile. So that's something where I'd really recommend resolving that before kind of waiting for Google to force that move on you with regards to the mobile first index. We're kind of at time. I have a bit more time, so we can definitely pull it out for 10, 15 minutes more if that works for any of you if you have some more questions that we need to go through. John, can I quickly ask if you managed to look over my message regarding the website, the university website with a subfolder that isn't appearing at all in the results after four or five months being up? I pass that on to the team. I don't have anything back from them that I can share at the moment. So they're looking into that. I don't know if I will have anything to share back. Sometimes they have to work on their things over time, and they say, oh, we can't tell the webmaster anything because we have to do something. Sometimes it's something where there is an obvious thing that maybe the webmaster is doing wrong that we can tell them to kind of let you know back. But at the moment, I don't have anything that I can share. OK, but at least from what you noticed, this shouldn't be happening. This is not the normal. It looks kind of odd, yeah. It's good to know. Yeah, it doesn't seem like something that usually would be happening like this. It's hard to say whether it's a bug or whether it's kind of by design with the way our systems are set up there, but it does look a bit odd, yeah. So I figured out what's really useful. I was wondering since Google launched, I mean, added the support for courses schema markup. Would that make any difference or that doesn't seem to be related? That shouldn't make any difference. So I believe that the courses markup is only in the US at the moment. Yeah, the US site is a university in the United States. Yeah, so I suspect that if you implemented the courses markup, we would be able to use that with the functionality for courses. So that could help, but it shouldn't be kind of preventing the site from showing up normally. So usually with rich snippets, with rich cards, what happens is we can show the same content maybe in different ways and bubble it up like that. But it's not that it would change the ranking of the normal web result. Oh, OK. Well, good to know, at least I can show this to the client. Yeah, I mean, it's something you can also try out and maybe put it on, I don't know, a subset of the pages where you know they're kind of relevant, where you can measure a difference and see how that works out. But with the courses markup, if the subfolder that hosts the new study program of the university, so it has the first page, which is the kind of introductory page that has a page for prerequisites and another page for tuition and things like that, should all of them be marked up or is just the first page, so to say? I don't know. I'd have to look into the courses markup. So I haven't looked into what specifically you'd need to markup there. But that should be documented fairly well. Usually they're pretty good with the documentation for the markup types. OK, one quick other questions regarding crawling and how it shows up in Search Console. So when I do a fetch as Google, I can see the resources that are being fetched. So some are CSS, some are JavaScript, some are Ajax. I was wondering if those are included in what shows as being pages downloaded or pages crawled in the Search Console? Yes, yes, they should be. So it should be any resource that's fetched, so any URL that's fetched. So in that sense, maybe the title should be changed to something like URLs to make it a little bit clearer. Yeah. OK, OK, cool, thanks. And that's also included in the average size. So that's something where if you have a lot of big PDFs or big video files or images that are being downloaded, you'll see this rise there. Whereas if you have a lot of really small embedded resources that are being downloaded with rendering nowadays, you'll probably see the average page size go down there. So that's something where you can't look at that graph and just say, oh, this is good or this is bad. You kind of have to understand what your pages are and what the embedded content on those pages is as well. By the way, regarding that, I asked you last time regarding canonicals for very big e-commerce websites that have filters and all sort of combinations that create different thousands, tens of thousands of URLs. You mentioned the URL parameter of tooling in Search Console. So in that case, if a filtered category has a real canonical to the unfiltered version, in the URL parameters tool, should I set it as doesn't change the content of the page in order to behave like a canonical? Because if I set it to narrow the page, then that's kind of a signal to tell Google, well, the content is different. So you should try to crawl it and index it. I don't know. That's an interesting question. Yeah. So with the URL parameter handling tool, what generally happens is it guides our crawling. So we've discovered a bunch of these URLs. And with the parameter handling tool, we will be able to figure out, well, out of these URLs, we can probably ignore these, and we don't even have to crawl them. On the other hand, the canonical is, once we have crawled the URL, this is the one that we should actually be choosing. So they're kind of at different stages in the process. The parameter handling tool is before we crawl, and the canonical is when we have crawled it, this is what we should be doing. So obviously making sure that they're kind of in sync makes sense, so that you don't set a canonical to URL that you're telling the parameter handling tool not to crawl. So that kind of makes sense, but it's not the case that you need to always align them completely. So if you're saying this narrows, and at the same time, when those URLs are crawled, it actually sets a canonical that's slightly different, then we're still crawling those. We're picking up the canonical. We're kind of passing things on to the canonical, then that's fine. I just make sure that they're not conflicting. So you're not setting a canonical to something that you're saying shouldn't be crawled in the parameter handling tool. Hi, John. Hi. Hi. Can I just ask a follow-up question to my other question about Bootstrap Modals? So if the modal window has more content than the page, will that affect my search ranking, or will I be penalized? That's perfectly fine. That's perfectly fine. So that's not something where you need to kind of tweak that. So I guess from a more technical point of view, what happens there is we try to understand which part of the page is the primary content, and we try to see that which parts of the page are actually duplicated across the rest of the site, that we can kind of devalue, we call it boilerplate. So that's something where we would probably see this modal block of text as being more like the boilerplate content, and we would focus on the primary content instead. And if the primary content is fairly small, that's still primary content that we can use. So it's not the case that we would count the words or the amount of text and compare that. Thank you. Hey, John. Real quick question from Sharp. We have some pages that we were using that fetch as Google tool just to make sure that they were looking right. And then we also did some indexing because we were trying to figure out why they weren't indexed yet, and they are in our sitemap. And out of the last week, I think we did about 17 of them. It looks like nine of them have been indexed and stayed in the index, and about eight of them are in the index or were in the index, and about a week later, they've fallen out of the index. Is that normal? Can that happen? Is there an explanation for that? That can definitely happen. So the submit to indexing tool is essentially a way to fast track these for indexing, but that doesn't mean that they'll remain indexed like that. So what can happen on the one hand is that they switch into the primary indexing mode, and we index it normally. That can happen immediately afterwards or overlapping where you wouldn't see any drop. Sometimes what happens is that the more normal indexing happens in a later step, where a URL will be indexed first with this kind of fast track indexing and drop out for a couple of days or a while and then be indexed normally again. So that's something that can definitely happen. It's usually not a sign that there's anything wrong with those pages. It's really just that, well, we haven't gotten to them with the normal indexing. Therefore, maybe it'll take a little bit longer for them to kind of move over to that second part. So I guess what I would do in a case like that is make sure that the most important pages of your site are actually being indexed properly. And if not, then use the Fetchers Google tool to submit those for indexing. And that's something where what you can also do with the Fetchers Google Submit to Indexing tool is to say, I don't just want this page index, but rather all linked pages as well. So for example, if you have a category page, you could submit that page for Fetchers Google for Indexing and say, all linked pages should be indexed as well. And we'll take that category page, find all of the links to the individual detail pages, and try to index all of those pages as well. So that kind of spreads the load a little bit and makes it easier to manage. OK, that makes sense. Yeah, we've tried some of those index type pages where we've got a page that has all the links to all the doctors. And I think we have about 1,600 in our site map, which isn't a whole lot. And it looks like we're only indexing about half of those at this point. We've been kind of watching this over a month or so. Does that seem like that's within normal realm? Probably. It feels a bit slow. So that's something where I probably try to dig in a little bit more to see what we're actually crawling and indexing with regards to the website. Maybe we're crawling URLs that actually don't need to be indexed. That's one aspect I might be looking into there. But I don't know if you have a thread in the help form as well, because maybe I can follow up to this one. OK, if you can post a link to the thread, maybe in the comments here, I can follow up on there. And kind of double check to make sure that the rest of things are aligned, and it's just a matter of time until that settles down. OK, I'll do so. Thanks, Sean. Sure. John, can I ask a question regarding what happens after submitting a page for indexing due to an update at the Rosonet content? What I wonder is, usually we get to see a bump in the traffic that is sent by Google to that page in the next few hours. But I wonder if you can explain why that bump happens and then it slows down. Is that Google could be giving a sort of a chance for the page to rank for queries that deserve freshness for a while? Or could it be because Google found out some new relevant keywords and also is trying to give some more exposure? Could be both, could be none. What can you tell us? Yeah, it's hard to say. I mean, there are always fluctuations there. The tricky part is in some of these cases is if it's a URL that we haven't seen before, then we don't have a lot of signals to kind of build on to say, this is how we should be showing it in the search results. So that's something where what might be happening is our algorithm's just saying, I don't know where to show this page in the search results, let me just try out a few things. And that could result in something either being placed a little bit too low, where you're not getting a lot of traffic. And over time, we recognize, oh, this is actually a pretty good page. We're seeing links going to these pages now. We're picking up signals and saying, this is actually good stuff. We should be showing it higher. It might also happen that we say, well, this website is usually pretty good. We'll show it fairly visible in the search results. And over time, we realize, actually, maybe we showed it a bit too high. We're not kind of getting confirmation that this is actually the right page to show in the search results. So both of these things can happen where a site might start or a page might start fairly low and kind of shift up over time. Or a page might start off fairly high and kind of shift down over time until we've found a place where we think, this is actually pretty good and relevant position in the search results for specific queries. So do you mean for new pages or for updated pages? Usually, we see this more for new pages. So if something is really new and we don't have any information about it, then that's something where you would see this kind of difference. In particular, when it comes to completely new sites as well. So if the site is completely new, we don't have any idea of where does a site belong in the search results. On the other hand, if a site is already well known, then we kind of have a way to judge, well, this site is pretty good, or overall, this site is not so good, so maybe we need to be a bit more careful with regards to new pages. With regards to updated pages, that's sometimes trickier, because there is kind of this mix of we know a little bit about this page, but you're telling us a change significantly, so maybe we need to figure that out first, and you'll see some fluctuations from that. OK. Thank you. All right, let's take a break here. It's been great having you all here as well, and lots of good new questions as well. So I'll definitely be setting up the next batch of Hangouts later today, probably, if there's anything on your mind that I didn't get around to answering. I know there are a bunch of questions. So on the page two, we'll be setting up the next batch. Whoops, a bit of echo here. So if there's more on your mind, feel free to add them to the next Hangout, or feel free to post them in the Webmaster Help Forum, where the top contributors do a fantastic job of trying to figure out what the right answers are there to help solve or get closer to a solution to some of the questions that you all have. So with that, thanks again for joining, and I wish you all a fantastic weekend, and maybe we'll see you again in one of the next Hangouts. Hi, Sean. Thank you, John. Hi, everyone. Hi, John. Bye.