Temporarily Remove URL will block the URL from Google Search results


Removing content from Google | WMConf Lightning Talks

for about six months.


This will also clear the cached copy of the page.


You can also use this option as a quick first step


when permanently blocking a page from Google Search results.


Clear Cached URL clears the cached page


and wipes out the page description snippet in search results


until the page is scrolled again


when the snippet is generated from the new content.


Until the next scroll,


the page description will be empty in search results.


Use this option when you remove sensitive information from a page


and want to update your results snippet in Google Search


without removing the page itself from search.


Be sure that you've removed the sensitive information from your page


before clicking this,


or else Google will just recrawl the page and find the same content.


For each of these two options,


you can submit a request for a single, specific URL


or for an entire URL prefix.


Make sure you think twice before submitting a request


for an entire prefix


so that you don't unintentionally block pages that are important to you.


In the temporary removal section,


you'll find a summary of the page removals requested through this report


in the past six months.


You'll see the URL, the request type, the date requested, and the status.


You can also use this report to cancel a request


if it's no longer necessary.


Now, what if you don't control the content?


Let's go through your options.


If the content you want to remove lives on a Google-owned service,


we might be able to help.


You'll find a link in the description to a troubleshooter


to help you report content that you would like removed from Google services.


Provide as much information as you can to help us investigate,


and if applicable, the information will be removed.


You'll need to submit separate notices for each Google service


where the content appears.


To remove content from the web which you don't control


and is not hosted on a Google service,


your best option is to contact the owner of the website


to request for the content to be removed.


Try sending a message via the contact link that is usually available in websites.


You can also try to find the website owner's email


through a Google search including whois...


For more information on that,


check out the removal troubleshooter for third-party pages


linked in the description.


With that said, there are ways to remove the content from Google search.


You'll find more info about them in the troubleshooter.


Here are some examples of information Google might take off search results.


Copyright and other legal removals.


Child sexual abuse content.


Non-consensual explicit or intimate personal images.


Involuntary fake pornography.


Financial, medical, and national ID information.


And more.


Again, check the links in the description to learn more.


That's it.


To recap, if you'd like to remove content from Google or from the web in general,


you need to ask yourself two important questions.


Who controls the content?


And do I need to remove the content permanently or just for a period?


With these questions, you can find the best approach


to remove content from Google or the web.


If you like this video, check out the Search Console Training Series


in the Google Webmaster YouTube channel.


You'll love it.


Stay tuned.


English Google SEO office-hours from January 29, 2021

All right.


Welcome, everyone, to today's Google Search Central SEO


Office Hours Hangout.


My name is John Mueller.


I'm a search advocate at Google here in Switzerland.


And part of what we do are these Office Hour Hangouts,


where people can join in and ask their questions around search.


And we can try to find some answers.


A bunch of things were already submitted on YouTube.


So we can go through some of those.


But if any of you want to get started


with the first question, you're welcome to jump on in.


Hi, John.


I hope it's OK if I start.


I have a quick question regarding Core Web Vitals.


Does it make a difference if a Core Web Vital is


below the lower threshold, or is between the lower


and the upper threshold?


What I mean is if the Core Web Vital is yellow or green,


does it make a difference for the ranking beginning in May?


I don't know if we've announced anything specific around that.


My understanding is we see if it's in the green,


and then that kind of counts as it's OK or not.


So if it's in yellow, that wouldn't


be kind of in the green.


But I don't know what the final approach there will be.


Because there are a number of factors that come together.


And I think the general idea is if we


can recognize that a page matches all of these criteria,


then we would like to use that appropriately


in search for ranking.


I don't know what the approach would be where it's like,


there's some things that are OK and some things that are not


perfectly OK, like how that would balance out.


OK, will there be some kind of information


before May about this?


I suspect so, yeah.


I mean, the general guideline is that we


would like to use these criteria to also be


able to show a badge in the search results, which


I think there have been some experiments happening


around that.


And for that, we really need to know


that all of the factors are compliant.


So if it's not on HTTPS, then essentially,


even if the rest is OK, then that wouldn't be enough.


OK, thanks.


Sure.


Good morning, John.


I had a question in regards to knowledge panels.


I'm working on a client site.


And I wanted to see what steps I can take to get a knowledge


panel generated.


Is there a certain schema?


Certain things I have to do to make that happen?


We don't have any guidelines for how


to enable a knowledge panel.


Essentially, that's something that our algorithms


try to pick up algorithmically, automatically.


And that's something where we take into account


a number of different sources of information


to try to figure out what are the entities that


are associated with this page and how relevant are they,


and how should we be showing that in search.


So it's not that there's a specific meta tag that you need


to do or a specific type of structured data


that you need to add.


It's more that everything kind of needs


to align so that we can really recognize


this page or this site is about a specific kind of entity.


OK.


No fantastic answer there or no straightforward answer there.


I know there are some people outside of Google


who have been working all around the knowledge panel things.


Andy just linked to Jason Bernard.


He's definitely totally on top of this.


And he can probably give you a lot of tips on things


that you can work to make a line.


OK, thank you.


I think someone raised his hand.


Hello.


Hi, John.


I have two questions if it's not a problem.


And the first one regards the duplicate content.


Say we have a page that describes a bunch of cars,


right?


So certain parts of the description and content


is the same.


It is unique.


We wrote it.


And it's an information that users will find helpful.


But how will Google look at that?


Will it be some sort of negative score or something?


Well, it can sound like a negative.


OK.


So with that kind of duplicate content,


it's not so much that there is a negative score associated


with it.


It's more that if we find exactly the same information


on multiple pages on the web and someone searches specifically


for that piece of information, then we'll


try to find the best matching page.


So if you have the same content on multiple of your pages,


then we won't show all of these pages.


We'll try to pick one of them and show that.


So it's not that there is any kind of negative signal


associated with that.


In a lot of cases, that's kind of normal,


that you have some amount of shared content


across some of the pages.


Yeah.


That's a really bad case, for example, is with e-commerce.


If you have a product and someone else is selling


the product, or within a website,


maybe you have a footer that you share across all of your pages.


And sometimes that's a pretty big footer.


And technically, that's duplicate content.


But we can kind of deal with that.


So that shouldn't be a problem.


Yeah, great.


So the second question would be about different languages.


So we have, say, English and Spanish.


And we have the same article, but it's translated.


And we have great rankings in, say, Spanish-speaking area.


And will that good ranking work for us


so we get a better ranking in the US or English-speaking


area?


Not automatically.


We treat these as different pages.


And we will try to rank them individually.


However, what usually is done when you have a localized copy


of your content is that you link between the localized versions.


So you would link from the English version


to the Spanish version, from the Spanish version


to the English version.


And based on these links, we would


be able to distribute some of the signals associated


with that good page with that new language version


that you also have.


So it's not like there's an automatic kind of your page


in English will rank just as well as your page in Spanish.


But some of that effort that you put


in, if you link between those versions, that


will be associated there.


It's also the case that sometimes


the competition in different languages


is just very different.


So you might have a very strong page in Spanish.


And the English version is a much more competitive market.


Then even if we forward some of the signals


to your English version, it might


be very different with regards to the competition in the search


results.


OK, thank you very much.


Hi, John.


I have two question about video.


So when we add an image to a website, we usually use all tag.


We use title tag and caption so that Google can understand


what is this image about.


What can we do for video if I upload or embed


a video in my content?


What can I do?


I don't know the names offhand.


But for video, we do have a type of structured data


that you can use.


And it also has fields for things like descriptions


and title, I think, for videos as well.


So that's something you can definitely use.


But the more practical thing is kind of like with images


as well, if you have a caption right next to the video,


if you have a heading on that part of the page, all of that


kind of applies to the embedded content as well.


So that's something that doesn't always


require a special markup or special attributes to use.


Second question is, is there any difference uploading a video


or embedding a video from a field point of view?


If I embed a video, it means I am pulling the video


from other websites.


But when I upload it, it means it is on my website.


It means it is my content.


So does Google differentiate in this way?


Or it's always same from a field point of view?


It's essentially the same.


It's very common that you have a separate CDN for videos,


for example.


And technically, that's kind of a separate website.


And from our point of view, if that works for your users,


if your content is accessible properly for Google


for indexing, then that's perfectly fine.


Thank you.


Cool.


Bunch of people also have their hands raised.


SPEAKER 2 John, just wanted to follow up a bit on that


duplicate content question.


Obviously, what you said is perfectly accurate.


But I think there are some cases where


Google doesn't automatically merge two pages together


for various reasons, doesn't have enough signals,


or signals are conflicting.


So in that case, both pages might actually


compete one against each other.


And in that case, while there's no specific penalty


or any algorithmic factor to kind of pull the site down,


you're still at a disadvantage because you're


trying to compete for the same thing with two pages.


So I guess that it's still worth to try


to make sure to set up signals so they do actually


canonicalize properly without hoping that Google kind of picks


that up automatically.


Yeah, definitely.


Yeah.


SPEAKER 3 John, can I just clarify that video question?


Sure.


I thought, unless my knowledge is a couple of years


out of date, that if you used YouTube as your host


for the videos, and you did a Google video search of things,


then YouTube would be the source and not your page.


Whereas if you used Vimeo or something else,


then actually your page shows as the source.


Is that not still the case?


It depends.


Ah, excellent.


The standard answer.


Sorry.


But I mean, with YouTube, you essentially


have two video landing pages.


You have the landing page on YouTube,


and you have the landing page on your site.


And we kind of have to figure out which


one of these pages to show.


And it can happen that we show your site as the video result


landing page just because we have more information there,


perhaps.


It can also be that we show the YouTube landing page because


maybe we have more signals or more information there.


So that's something where it's not automatically the case


that we would show the YouTube landing page.


And some other video platforms also


have their own landing pages that they create automatically.


Some video hosting platforms don't do that at all.


Essentially, that's kind of up to you there.


So essentially, if you do it on something like Vimeo, which


doesn't have a public facing, all the difference


is you're not creating a competing video when


you upload it.


Whereas with YouTube, if it's public,


you're creating your own and the competing YouTube version.


And therefore, you're competing with YouTube.


Yeah.


I guess that's one thing that could play into that.


It's also, I mean, people sometimes


search for videos on YouTube.


So if you want to be visible there,


that might be kind of something you'd want to do anyway.


But yeah, it is something where you kind of


need to think about that a little bit as well.


And it's not 100% the same if you have the same video file


that you're hosting yourself or that someone else is hosting


for you without a landing page or you essentially


have two video landing pages.


Sometimes you also want to have two video landing pages


because it's like a slightly different content


or it attracts slightly different audience.


OK.


Hi, John.


Can I ask something?


Sure.


So for example, there's a website


that is getting a good amount of search traffic.


Now, I just wanted to know if the same website is getting


traffic from some other channels like direct traffic,


social traffic, or some traffic from other blogs.


So that known search-related traffic that a website is


getting is some kind of positive signal for Google.


Like Google finds that this website


is getting a lot of traffic from direct or social channels.


So we should push this website in search


also so that searches can find it easily.


We don't use that for SEO.


So I think it's great to, from a website point of view


to diversify the different sources of traffic


so that you have different places where people can find


your site, different places how people can get to your site.


But we don't use that for search.


So if you're active, I don't know,


on Facebook or on other social media channels


and you get a lot of traffic there,


then that's kind of a way to balance out


some of the uncertainty maybe around search,


or around Discover, or around some of the other channels


that you also use.


Sorry.


So I think that diversification makes sense.


It's something to work on.


And it helps to make it a little bit safer with regards


to your presence online.


But it's not something that we take into account for search.


AUDIENCE 1. Not directly or indirect.


For example, a brand suddenly starts


getting a lot of direct traffic.


So there's no impact on search performance.


No, no, I mean, indirectly, you might see something.


If people go to your site and they think it's fantastic


and they share it with other people


and we pick that up as a link, then


maybe we could take that into account, but not directly.


AUDIENCE 1. Sure, thank you.


OK, I see a bunch of people raised their hands.


And I just found a place where I can see the names.


So I'll just go through from the top of my list here, Benjamin.


Hi, John, how are you?


Really long time listener, first time caller.


It's an honor to be here.


I remember the Matt Cutts days, but thank you


for letting me in.


I'm writing it or I'm calling it because I purchased


a website that has been around since 1998.


It was owned by the same person till 2018.


And can I paste it in the, am I allowed to paste it in the chat?


Sure, OK.


It got purchased.


And then from what I can tell from all my SEO research,


it got possibly turned into a PBN potentially,


or just a really bad website.


I purchased it and I've done everything


I can to turn it around.


I got in touch with the original owner, stalked the internet,


found him, been emailing him back and forth,


asked him why he sold it, he just said he got too old for it.


Updating all the content, added new UI,


added social profiles which didn't exist.


I'm seeing slight movements in traffic, which


leads me to my question.


I'm investing a lot of time into this.


Money too, but it's just really my time.


And I'm putting my heart and soul into it


because I do think that this site needs to exist.


I haven't found much on this topic.


Am I wasting my time?


Does Google say, oh, this was maybe potentially a PBN


or they did spam me back?


Oh, I did disavow as well.


Can you talk to the point of are sites


able to be turned around, especially


under new ownership, new Whois information, new domain,


new host as well?


Yeah.


I think the short answer is yes, you can turn it around.


In general, the most common issue that we find


is that maybe there is a manual action involved.


And that's something you would see in Search Console.


And I assume you checked.


And if there's no manual action, then essentially it's


kind of a normal website.


It's not that we would take into account


any previous manual actions.


Like if some owner in between had a manual action,


that's not something that we would take into account.


So essentially, the way the site is now


is the way that our algorithms are looking at it


at the moment.


And if you work to improve the site,


and if there are other issues associated with the site


that you work to improve, then that should improve over time.


There's no black stamp on it forever type of thing?


Yeah.


Cool.


All right, thanks, John.


All right, John.


Andrew, let me just run through the names


as I have them in the list.


And then after that, I'll try to get through some


of the submitted ones as well.


But just to kind of make sure that we follow


who all is in the list.


Yes, John.


Hello, thank you.


Well, my question is about the situation


when a site has an app connected to the site.


And for mobile users, browsers offer


them to download the application,


so showing some kind of banners from Google Play or App Store.


This offer, as you may know, appear at the top of the site.


And inevitably, it creates layout shifting.


And it's also hard to fix this shifting.


And I wanted to ask, what is your opinion on this matter?


Is Google OK with these situations?


I assume you're specifically asking


about the cumulative layout shift from the core providers.


Sure, sure.


So for that, I would focus on the metrics


that you can pick up from the testing tools


and from the real user data that you can pick up for the site.


So it's something where we don't explicitly


say this specific kind of pop up or banner is OK,


or this specific banner is not OK.


It's really just you can test it and see what number comes out.


And maybe there are things that you


can do to improve that so that the number looks better,


and where you can also look at the number


and say this is OK for me, or this


is something I need to improve.


Well, but they do create this shifting.


And well, I don't know.


You can't control them because it's not on your site.


I mean, as I understand, it's not, well,


it's browsers.


They just offer those banners.


I can't, like, I don't know, just


close them, I mean, forever.


But well, it's not an option as well, a good option.


Yeah, I don't know how exactly that looks on a browser.


So it's hard to say.


But it's something where if you see


that this is a problem for some of your pages,


maybe there are ways that you can


do to make it less visible on the important pages


and maybe limit it to other pages,


or do something such as allow the user to click on a button


and then trigger this in the browser,


something along those lines.


OK, OK, thank you.


Sure.


Lee, I don't know if you asked before or already,


or still waiting.


Hey, John.


Real quick, just two quick questions here.


Piggybacking on the question about page speed


earlier in Core Web Titles, I work with a company,


and they have a very authoritative page.


We're more authoritative than our competitors


that are outranking us for a number of keywords.


And that has to do with some other factors


that I'm dealing with right now.


But we do have a slower page significantly.


However, I would say objectively, we


have a more valuable experience.


We offer a better product, that sort of thing.


And we get more traffic than these other pages


that we're ranking against.


So my question is, is page speed used now


as a significant ranking factor that


would outweigh the content that we're providing


and the user experience and that sort of thing?


And will that get to be more of a factor come May


and that sort of thing when Core Web Titles rolls out?


We use speed on mobile at the moment.


So that's something that kind of plays in a little bit there.


And in May, I think the idea is to kind of revamp


how we look at that and maybe, I don't know,


my guess is that we will use that a little bit stronger


as a signal.


However, it's still the case that when


we can recognize that someone is looking for something specific


or a page is particularly relevant to users,


then that's what we plan to show.


So for example, if someone is looking for your company,


we wouldn't show some other page just because it's


a little bit faster.


And that kind of means that if you have a really strong page


in your topic area, then probably that


will be OK even if it's a little bit slower.


But no, it's really hard to kind of say,


this is where the line will be drawn,


and this much is not strong enough or anything like that.


Cool.


That makes sense.


We're working on a number of things.


So I'm not super worried about it,


but it is one of those things where our engineering team is


sort of backed up and working on getting these.


We have a very large website.


So that's obviously one of the things that we're working on.


My second question is about just subdomains.


So my company is a blog that operates


on a secondary subdomain as opposed to a subfolder.


And I'm just wondering, as far as ranking signals and stuff


from Google, is that viewed as another domain entirely,


or do we have authority that's going back and forth


between the two?


Obviously, we're linking between the two effectively and stuff.


It depends.


So in some cases, we will see this as part of the main site.


In some cases, we'll see it as something kind of separate.


So for the most part, I wouldn't recommend just changing this


just blindly and hoping that you'll get a big advantage out


of it.


But rather, if you're thinking about consolidating things


on one domain, if it makes more sense from an infrastructure


or tracking point of view, then I think all of those things


kind of point more in the direction


of using subdirectories.


But sometimes it's also the same that kind of applies


to subdomains, where you say infrastructure-wise,


it's easier like this.


Maybe you're using some CMS that needs


to be on a separate subdomain, all of those things.


So hard to say.


All right, thanks so much, John.


Antonio.


It's an honor to ask you directly.


Thank you so much.


Question.


I have a page that's ranked for dozens


of words in the top positions.


And for a search or a group of search,


I'm looking for the second page of the results.


The best thing to do is to include these terms


and talk about it on the same page


or create a specific page for those terms and link to do it.


I have a good advantage experience with both options.


And that makes I'm really doubtful.


What's your recommendation?


If you want, I can do an example to explain better my question.


Yeah, I totally understand the question.


And I don't think I can give you an absolute answer.


Because like you said, sometimes it


makes sense to separate things out on multiple pages.


Sometimes it makes sense to concentrate on a single page.


I think it depends a lot on the user expectations, maybe also


the competition with regards to would users be confused


if they went to one general page and they expect


a kind of a specific page?


Or would users also be OK with a general page that is ranking?


For the most part, I think fewer pages make sense because you


can make stronger pages.


They're a little bit stronger with regards


to kind of the competition.


But at the same time, if you're specific about a certain topic,


then that's a very well-targeted page.


So finding that balance, I think, is really hard.


My usual recommendation is for you to try it out and test it


out and see what works well for you in your specific situation.


Well, thank you so much.


No.


I mean, it's not like a perfect answer,


but I hopefully give you some ideas.


At least there's no absolute answer.


And I know I have this problem many years.


And I will not know exactly to do because it's Google.


Thank you so much.


You are incredible.


Thank you.


Stefan.


Good, Nabin.


So let me set the stage real quick.


I work for a fairly large company,


and I have similar subdomain duplicate content challenges,


as Lee does.


It's not exact duplicate content because the context


is slightly different.


There's a purchase aspect on one subdomain and a stream aspect


on a different one.


So we've been trying to tackle some indexation issues where


one subdomain actually has a lower traffic potential.


We rank typically less well and so forth.


So as I'm looking through GSC, one of my sitemaps,


looking through the excluded selection.


And so for one of the details, the duplicate submitted URL


not selected as canonical, there's


a huge number of URLs with that flag.


And so as I started to look into some of the examples


and then use the inspect URL, I noticed that almost invariably


there was no URL included in the Google selected canonical.


So I submitted a help article on the community,


and I got kind of a boilerplate answer.


And I was looking as I was listening


as we started the call, and it looks like that issue is fixed.


So invariably, it seems like the URLs are now populated.


But most of the examples that I've found


are completely off base.


So they have nothing to do with the actual query


that the page should rank for.


So my question is, I guess the first question is,


how should one interpret the Google selected canonical NA


as a value?


Yeah.


I don't know.


I think I saw something similar on Twitter recently,


and I think that was a bug on our side.


So in particular, if we index a page,


then we always have a canonical.


And if the tool says there is no canonical available


but it's indexed, then that would


be kind of something conflicting on our side,


not necessarily something actionable on your side.


On the other hand, if it's not indexed,


then it would be kind of normal that we say, well,


we don't have a canonical associated with this URL


because it's not indexed, essentially.


Yeah, well, the report I'm looking at


would be index pages only, right?


Or at least I've confirmed that they're indexed.


OK.


Since we configured GSC for separate subdomains,


my hypothesis was that the alternative subdomain was


actually ranking, and you would just simply not include


that URL because it's not on the same subdomain


that's configured for GSC.


No, I think, I mean, I don't know what the specific bug


there is.


But it should be the case that even


if it's on a different domain, if we say


like a different URL on another domain


is canonical for this one that you have,


that we should show that.


So it shouldn't be the case that we would just


say, oh, we don't know.


But actually, we do know, but we just


don't want to tell you about it.


So that seems more like a bug on our side


rather than a sign that we use a different subdomain for that.


OK.


Well, it looks as though the bug may have been fixed,


but you may have introduced a new bug.


Oh, no.


The canonicals seem completely off base


from the topic that should be canonicalized.


If you can drop some examples maybe in the chat here,


I can pick that up afterwards and pass that on to the team.


Can do.


Thank you much.


Sure.


Thanks.


Angie, I think you also have your hand raised.


Hi, John.


As always, thank you for doing this.


So I'm doing a site move for a client.


I had a few questions about that.


So we're changing the domain name.


So they want to present the brand as more modern,


so just changing it to the acronym of the full name.


And we're not removing any pages,


changing any content on pages, or anything like that.


So it's going to just be doing the redirects


and then using the change of address tool


in Search Console, and et cetera.


So pretty straightforward.


But I was wondering if everything


should be redirected, so like the site map and robots.txt


for specifically.


Is it recommended to leave both the old site map up


and the new site map up so that Google


is able to find all the redirects to the new site?


Yes?


OK.


And then for the robots, I saw that there was,


in the crawl stats support document, I believe,


there was it said that like 200s and 400s


were successful robot responses and 429s and 500s


were unsuccessful.


Did not mention anything about redirects.


So is it recommended to leave that not redirected


so that Google is still able to crawl from the old site?


I don't think it matters with regards to the redirect.


I think in our site move documentation, at some point,


we had a recommendation that you have an empty robots.txt file


on the old domain just so that we can crawl all URLs


and then find the redirect to a new one


and recognize, oh, it's now blocked


or it's a 404 or whatever.


My guess is that's more of kind of like super small


optimization with regards to crawling and not really


necessary.


So in particular, site map file and robots.txt files,


they're files that are more like control files


and not indexed anyway.


So if they do or do not redirect,


it doesn't really matter.


With regards to all of the indexable content,


that is something that is kind of important for us


in the sense that if we can recognize that a site is only


partially moving, then we'll kind of


have to shift into a mode of like, oh,


we have to figure out what actually changed here.


Whereas if we can recognize a site has completely moved,


all of the indexable content has moved,


then we can shift into the mode of like,


oh, we'll just transfer all of the signals


in bulk to the new domain.


AUDIENCE 1. OK, yeah, so we are doing like a one-time switch.


So we're not moving in sections.


So it'll just literally be like flipping the switch.


And I guess the signals will be start processing,


will be processed right away?


Yeah.


OK.


Yeah, ideally, yeah.


And then actually on the note of site signals,


because I know that these days, we


talk about how pages are being ranked rather than domains


as a whole.


But how much of a factor are the site signals?


What I'm trying to ask is basically,


say we do everything perfectly.


We're not changing anything on the site either.


So everything should be pretty much the same.


Once Google's finished reprocessing everything,


can we expect to have essentially


the same sort of performance and everything as we had before?


It's going to be on the same server as well.


So the only thing that's changing


is essentially just the domain name.


Or what about new pages that go up on the site after the change?


Because it's a new domain that has had no previous history,


could new pages be a little bit at a disadvantage


because Google has less site signals?


Or I guess basically, how much of the site signals


have to do with that?


I think in an ideal situation, all of that


will just transfer.


And it'll just continue working just like before.


So we've been doing a number of analysis internally


on site moves in particular just to make sure


that we're not missing anything, that nothing kind of goes wrong


with most of the site moves.


And for the most part, we can see


that it clearly just completely transfers to a new domain.


So if there's nothing kind of weird associated


with a new domain and the website really


does a clean move, then that should be completely fine.


I think it's always something where you don't completely


know what to expect because it's a different domain.


You can't really try it out ahead of time.


So it's always a little bit of uncertainty involved.


So my recommendation there is just


to make sure that you're really tracking all of the details,


that you have a big spreadsheet with all of the checklist


items to double check.


So that should anything weird happen,


you can kind of be certain that we have


all of these basics covered.


And it's really something kind of obscure


that you couldn't have known ahead of time.


Or otherwise, you can go through the list


and see, oh, I forgot to set the hreflang,


or I forgot this specific thing.


And then you can explicitly go in and fix that.


OK, perfect.


And then my last question was, so in the site move


documentation, it does mention that we should


expect rankings to fluctuate.


And I was just kind of thinking about the process of how


Google would reprocess those pages


and how that would actually affect the ranking.


So for example, is it more if I have


a page on the old site that's currently


ranking for position one on a certain keyword,


when we do the redirect, when Google discovers it,


is there a period before, I guess,


the crawling and sort of reindexing


happens where it would actually drop out of the search results


before being replaced by the new page if everything is good?


Or if it crawls it and reprocesses it immediately?


Or sorry, or does the old page just


stay there until the new page is kind of reprocessed?


Yeah.


So essentially what happens there


is we switch to canonical.


So we would have the old page indexed.


We would start seeing the redirect.


We would follow the redirect, see


that the same content is there.


And then our systems would say, oh, it


looks like it moved to this new URL.


And we would just switch that over.


It's not the case that it would fall out first and then


be reindexed again.


It's really kind of like, oh, we see this connection.


We see both of these pages.


We can just switch it over to the new one.


So it shouldn't be the case that there is a hole with regards


to traffic.


But usually with all site moves, you


have this period of there's some things associated


with the old site, some things associated with a new site.


And it takes a little bit of time


to shift the majority of things over.


In a lot of the site moves that I looked at for double checking,


this is a period of a couple of days, maybe a week or so,


where it just fluctuates a little bit


until it settles down again in a similar state


with a new domain.


OK, thank you very much.


All right, I think, Kadu, if I get your name right.


KADU GONZALES-DAYSATIYA MARTINETTI Yeah, that's right.


Thank you, John, for this opportunity.


My question is more about Web Vitals.


We have an education platform and manual.


Our requests are made from logged in users.


And basically, we treat logged users


different from our logged users.


The same page will load a bit more stuffs on a little more


stuffs for logged users.


And this makes the page much more deficient on Web Vitals.


And my question is, how concerned


I have to be about my logged users in this page


that we serve for them?


If you have the same URL that is publicly accessible as well,


then it is very likely that we can include that


in the aggregate data for a Core Web Vitals,


kind of in the real user metrics side of things.


And then we might be counting that in as well.


So if the logged in page exists in a public form,


then we might think some users are


seeing this longer page, perhaps,


or kind of more complicated page.


And we would count those metrics.


Whereas if you had separate URLs and we


wouldn't be able to actually index those separate URLs,


then that seems like something that we


would be able to separate out.


I don't know what the exact guidance here


is from the Core Web Vitals side, though.


So I would double check specifically


with regards to Chrome in the Crux help pages


to see how that would play a role in your specific case.


Thank you, John.


Darcy.


John, how's it going?


Wonderful.


Good.


Pretty good.


OK, so I have a question kind of along the lines


of some of the subdomain questions


that people have been asking.


So if you kind of said, like, I think


if I heard your answer correctly,


there is some times when that can make sense.


So I'm wondering if this situation makes sense


and what are the potential risks involved here,


where the site is going to exist in two parts.


One is like the content focused part of the site,


and then the other is the e-commerce focused


part of the site.


And so you would have a lot of people


who are focused part of the site, and so you would have


shop.mysite.com and then your e-commerce side


on the subdomain.


Would you recommend a couple of questions?


Would you recommend that strategy?


What are the risks involved?


And then how much GameStop stock do you own?


Oh, man.


I don't know about the last one.


That's so weird.


Such a weird situation.


Throws me off completely.


Yeah.


So I think to kind of back up a bit,


we regularly talk with the search leads


about subdomains versus subdirectories


and tell them, oh, SEOs are so obsessed about subdirectories


and such.


And they always tell us they should just


use whatever makes sense.


Our system should be able to deal


with subdomains and subdirectories


essentially in the same way.


So I think there's some more second order effects


that some people are seeing there,


but I don't think it's something where I'd say you will


automatically have a bonus if you go to subdirectories


or if you go to subdomains kind of thing.


So if you have your shop on a separate subdomain


and that's what works well for you with regards to tracking


and all of that, then I would try to keep that.


I don't see a problem with moving that over


or trying to find a way to do a reverse proxy


and move that to a subdirectory.


So you think they can?


Because I mean, I guess always the concern


is the two separate site situation and trying to rank.


Because you want both to rank, et cetera.


The problem that we have here is a technology problem.


And the customer wants to use Shopify


for the e-commerce side but not for the content side.


I think Shopify can't install on a subfolder.


So you feel that it still could work just fine.


Would Google decide to link those and consider them


one site, or are they always going to be considered two


sites no matter what?


It depends a little bit.


I think in a situation where you just have two subdomains,


then probably we would treat those as separate sites.


If you have a lot of different subdomains,


then we might see like, oh, they're


using wildcard subdomains as categories, for example.


Then that would be a clear sign that actually this is one site.


We should treat that as one thing.


I think in a case where you have content on one side, one


subdomain, and a shop on the other,


I really don't see a problem also


with competing against each other.


Because usually people come with one intent.


And if they want the product, they'll find the product pages.


If they want information, they'll


find the informational pages.


It's not that these are competing


against each other or otherwise kind of like annoying


each other in search.


AUDIENCE 2 OK.


Cool.


Thank you.


What was the other question?


AUDIENCE 2 That was the game stops.


It was a joke.


Oh, OK.


OK.


All right.


Thanks.


Eric, thanks.


Can you hear me?


Yes.


Hello.


Hey, thanks for having me.


And thanks for doing these sessions.


It's great.


It's really good.


I have a few questions regarding search.


OK, so first of all, we had a review of iPhone that came out.


And for some reason, it ranked lower


than our first impressions article


that we did that covered reviews from other magazines


all over the world.


So we are really strong locally in our country.


And we had a review, like really, really good review.


And it was below our article that


covered the first impressions.


After like one or two months, we noticed


that we were missing the review schema with the rating


and stuff on the price.


So we added this to the article.


And then after a couple hours, it


ranked above the first impressions article


that we did before.


Is that possible?


I don't think that would be directly related.


So in particular, the rich results or the structured data


is something that we use for the rich results in the search


results.


It's not something we would use as a ranking factor itself.


What might have happened is that you changed the page enough


that our system said, oh, we need


to reconsider how we kind of index this page.


And then based on that, we kind of reconsidered the ranking.


But that shouldn't be related to adding structured data


to a page, essentially.


So it's not the case that every review


needs to have review structured data on it.


That's what I thought.


OK, so and also with this, do the missing fields


in schema org in the review type,


do the missing fields like brand, queue, description,


aggregate rating, and ISBN, do these matter if they're missing?


Because I see that Google only requires the three,


the price, the name of the product, and the, I forgot,


rating.


Yeah.


So if you have the requirements covered,


then we would show that in the rich results.


And the rest are really more optional.


So it's not, at least as far as I know,


it's not the case that we would rank things more


if you have more of the fields filled out.


OK, OK.


And do, that's Google, I know that you, in search results,


that Google only uses algorithms that find content on the site.


But do the meta tags, description, and keywords


matter at all for results?


We don't use the keywords meta tag at all.


So that, like you can do whatever you want with it.


I don't think any search engine uses that anymore.


The description we use as a guide


for the description or the snippet that we show in search.


It's not always purely from the description meta tag.


But for a lot of cases, it is something that we use there.


So if you have a specific snippet that you want


to have shown, then definitely make


sure that's in the description.


But we wouldn't use that as a ranking factor.


It's more that you're showing users what this page is about.


And maybe they will click through more


if they understand it a little bit better.


But it's not that it would rank higher because of that.


Yeah, I see.


All right.


And a recent email, actually yesterday and today


for our web page, for Search Console,


that you launched a new service or something that


grouped all the subdomains and subdirectories and HTTP


and HTTPS into one domain.


And so we verified the domain and everything.


And we still don't see the data that we


see for our HTTPS www site.


Will this show up, eventually?


Yes.


The data sometimes takes up to a week


to be completely visible in Search Console.


So some features are a little bit faster.


Some features take a little bit more time.


But that's kind of normal that it takes a little bit of time


to be visible.


And I think with this message in particular,


we sent it out when we noticed that sites are not completely


verified in Search Console, that maybe you


have traffic to the HTTPS version


and you have HTTP verified.


That's something we just wanted to make sure


that people are aware that they're not


looking at the full picture.


So with the domain verification, that's


all kind of covered automatically.


I see.


Perfect.


And we also noticed that our site maps were not


indexed properly or loading properly in Search Console.


And it was fine for a few years.


I mean, no problems.


But last week, we noticed that for some reason,


the Search Console couldn't load our site maps


from the site map index.


We have an index file with all the site maps, the parts.


And it loaded most of them.


But the ones that matter the most, the posts,


they just couldn't load it.


So is it something we can do something about?


I would probably post about that in the Help Forum


with a specific site map URL so that someone


can take a look there.


And if it is something that's more on Google's side,


then usually the folks in the Help Forum


can help to escalate that to us.


I think it's a bug because we added some parameters


into the URL.


And it loaded fine.


So it shouldn't be better.


Obviously.


And then, last question.


Sorry for that.


Then we had a review for AirPods Max.


We were the first in the country to have both the product


and the review.


And I just don't know why.


We still don't show up in the results.


And it's really annoying because we spend a lot of time and effort


into the review, and we don't show up in the results.


So can we do it?


Can we sort it out?


Yeah, I don't know, I can't make you rank automatically higher.


So the one thing I would watch out for


is if the page is indexed or not.


If it's not indexed, then usually that's


more of a technical thing that you can work to improve.


But if it is indexed and it's just not


ranking the way that you want, it's


really hard for us to kind of say, this is a big problem


or not a big problem.


So what I would also do there is maybe post in the Help Forum.


And kind of the specifics of the URL that you're using,


the queries that you're looking at,


especially if you're looking at a specific country, maybe


those details as well.


And they can take a look at that there and escalate that to us,


if appropriate.


But a lot of these ranking questions


are really tricky because it's often,


which page should we show?


It's like, everyone wants to be first.


Of course.


OK, thank you very much.


Thank you, and have a good day, all of you.


Thanks.


All right, Mark.


Yeah, thanks, John.


This is more like a European-focused question.


We have a cookie content layer.


Obviously, it's a decon form, sending out the correct strings


and everything.


So my first question was, I think,


if I'm not mistaken, Google mentioned that loading layers


like these will be recognized, and they will not be added


to the page speed index.


However, when I do check the domain and the page speed


index inside tool, it is recognized,


and it's found to be improvable.


However, we use probably the fastest CMP on the market.


So there's really nothing to improve here.


Just a question, will Google go back and take that out


of consideration, also with reference to May,


or what do you think?


Essentially, we'd be able to take that out with regards


to indexing the content.


But from a speed point of view, we


would not differentiate between this kind of banner


or any other kind of banner.


So essentially, from a speed point of view,


it is something we would see as something


that users would see when they go to the page,


and that would be taken into account there.


So I don't think, at least as far as I know,


that we would have any logic to say,


oh, this is a proper cookie banner,


therefore we will ignore that it's slow


or that it causes layout shifts.


Well, there's that list available on officially


registered CMPs, right?


So we're doing something that's legally obliged.


And we're just wondering, because in theory,


a competitor who is not using any of those layers


might have a page speed advantage.


And when page speed is becoming more and more important,


this just more like out of curiosity


how you deal with that.


Yeah.


My understanding is we would see that as a part of a page.


So that would be something, if it's slowing down


the loading of your page, then that


would be something we would take into account


and say this page is slower than maybe the same page


without that specific setup.


But I think another aspect that kind of plays into that


as well is that you're competing with sites


that have similar setups.


So it's less a matter of we will not show your site at all


in search.


But essentially, other people have the same kind of struggles


and need to figure out the same kind of thing.


So it's kind of like you're competing with other sites that


have the same problem.


So it makes it a little bit more even.


But obviously, in the situation that you mentioned


where if someone is, let's say, I don't know,


let's call it rogue and doesn't do any kind of banner at all,


then that would be something that we would say, well,


maybe this is a faster page.


But maybe the other page is a little bit slower.


But it's a better page or better fitting page for the user.


And then we would still rank that there.


So it's something where we do take speed and usability


into account for rankings.


But it's not the only thing.


It's like the content is still, by far, I think,


the biggest aspect there.


OK, thank you very much.


Sure.


Raymond, let's see.


Hi, John.


So I also posted this question to the comments for the video.


We have a site with a mega menu that has over 1,000 links.


It used to be that this mega menu back in 2018


would only load upon user action.


So when the user hovered above the nav bar,


J-JAX called it loads those links.


At some point in 2018, we added those static links.


And I know correlation isn't causation.


But around that same time, we saw a big drop


in our search graph.


Now we are now contemplating removing these links


from our nav bar as static links and going back


to links that only load upon user action with J-JAX call.


We are, nevertheless, retaining a clear path


to all of these links on relevant pages.


So we'll still have a clear crawl path to those links,


but only on relevant pages rather than


having these links on every page,


on this thousands and mega menu links on every page.


So we're wondering, what could possibly


be the impact or ramifications of removing these 1,000 mega


menu links as static links, even though we are still


retaining a crawl path to all of these links on relevant pages?


Yeah.


I think, on the one hand, it's kind of hard to say,


because I don't know how the rest of your site


is structured.


So if, for example, these 1,000 pages are all of your pages,


then it would be very different compared to, say,


these 1,000 pages are your categories,


and you have a million kind of subcategories or something


like that.


But in general, what you're looking


at from a change point of view is


going from a more of a flat site structure to a more,


I don't know, deeper site structure.


I don't know what the official name is.


SPEAKER 2


It's a different style of reality.


Yeah, and that's something where sometimes I


can definitely make sense.


So it's something we sometimes see folks kind of obsessing


about limiting the crawl depth, for example,


and trying to make it so that Googlebot can crawl to all pages


in a very quick time.


And to some extent, I think that makes sense.


On the other hand, kind of more the top-down approach


or pyramid structure helps us a lot more


to understand the context of individual pages


within the site.


So in particular, if we know this category is associated


with these other subcategories, then that's a clear connection


that we have between those parts.


And that definitely helps us to understand


how these things are connected, how they work together


a little bit better.


Whereas if it's very flat, then we think, oh, all of these


are equally important.


And we don't really know which of these


are connected to each other.


So from my point of view, I think for a lot of sites,


it makes sense to have more of a pyramid structure.


But at the same time, you don't want it to be such that you


have to click through a million times to actually get


to the actual content.


You need to have some reasonable number of clicks,


essentially, to get to the content.


And we are trying to kind of be our e-commerce site.


So there is a case that we made for having mega menus.


However, we just wanted that not to show up


as static links that would get crawled,


but still make it available to a user action,


for a user-used action, rather than just having them


there as static links.


But we still are all looking to have a siloed site with more


kind of a pyramidal structure, rather than something


that has where we have indiscriminately have


1,000 links on every page.


So yeah, we've talked to a number of SEO firms,


and they've told us, well, if you do this,


then it can greatly negatively impact your site.


But all of a sudden, these 1,000 links that you have,


all these pages are gone.


And it's not really true, because we


are trying to retain those links,


but only on relevant pages.


But then, again, we're being told,


don't do it, because if you lose all these 1,000 links


to all the pages, it's bound to have a negative effect.


And I'm wondering if an empirical statement


like that could be made.


I don't think it would always have a negative effect.


I do think if you make it too deep,


then that makes it harder for us to crawl and harder for us


to pass the signals around.


But it's not the case that a super flat structure is


going to be better than a reasonable pyramid structure.


So personally, I would try to aim


for more of a pyramid structure just


to make it so that it's easier for us


to understand the context of the individual pages


and to forward the signals into related areas easier.


But it's also something which is a very significant change


on a site like that.


So it's something where I understand that it makes sense


to get more input on the options,


maybe even to test things out.


You take one category and say, I'll try it here and see


what happens with regards to crawling,


with regards to indexing, with regards to ranking,


all of these things.


Because it is quite a big step when


you change your site from a super flat layout


to more of a pyramid layout.


Cool.


Thank you.


Let me pause the recording here maybe for a moment.


I'll be here for a little bit longer


so we can still answer some of the questions that


are remaining.


But if you're watching this recording,


thanks for watching along.


I hope you found this useful.


And I'll be setting up the next batch of Hangouts


probably on Monday or so, so for next week and the week


after that.


All right.


Thanks a lot.


JavaScript SEO: Welcome to a new series!


Search Console, JavaScript, serving, and more!

Welcome, everyone, to another special episode of Search


Off the Record podcast.


Our plan with this series is to talk a bit about what's


happening at Google Search, how things work behind the scenes,


and who knows, maybe have some fun along the way.


This episode is a bit special, so you'll


soon find out more.


My name is John Mueller.


I'm a search advocate on the Search Relations team


here at Google in Switzerland.


I'm joined for this episode by Martin and Gary, who are also


on the Search Relations team.


And we have a special guest today, Daniel.


Yay, Daniel.


Woo.


Oh, yeah.


Yay.


Ah, so good to have you on the podcast.


Daniel, for those who don't know you yet,


would you be so kind and tell us what


you are doing on the Search Central team


and who you're working with?


Of course.


But first of all, I want to say that every time that there


is a new episode of the podcast, I'll wait all the day


until after work.


I'll pour myself a glass of wine,


and I'll listen to it very carefully


to learn a lot from you guys.


So thank you very much for the podcast.


It's really a pleasure to be here.


Thanks, so cool to hear.


Aw, thank you.


Yeah.


So I joined Google about eight years ago.


I was part of the Google Analytics team for six years


as an analytics advocate.


And so doing stuff related to data analysis, best practices,


and data visualization, and how to use data in a way that


can make your business succeed.


So this kind of stuff and doing presentations


as we do in our team, and writing stuff, and working


with the engineering team to make our products better.


So I joined the Search Relations team about two years ago.


And it's actually a funny story that I found this position


playing ping pong.


What?


So I was looking for a new challenge.


And I was playing with someone from the developer relations


team, so I actually like playing ping pong.


And I was telling him the story.


And he was like, you should talk to John.


Do you know John?


And I'm like, well, I've heard about John.


So I reached out to John.


And we had a really nice chat.


And he put me in contact with the Search Console team.


And because the Search Console team is based in Israel,


it also made a lot of sense to have


someone that speaks Hebrew and could relocate back to Israel.


And I've been in the team since then.


I'm kind of embedded in the Search Console team in a way.


So I work a lot with the engineers,


but also with the Search Relations teams.


And it's a great place to be.


I'm really enjoying the ride.


MARTIN SPLITT


Regex futures to the Performs report.


Regex.


And Regex.


Regex, OK, got it.


Regex, OK.


So yeah, Regex.


So Performs report.


So basically, this feature, just to explain


to those that didn't see it, is the new capability


to perform more advanced futures using regular expressions.


And it landed really well.


So people are really happy because, well, it


was a top user request.


And they've been asking.


And I think that really shows how


we are kind of trying to developing new features


and listening to what people have to say


and developing new capabilities that


help people perform their jobs.


That's interesting.


So you said that this feature is what


you would consider a small feature, but it has big impact,


and that it was picked because it was the most requested


by users.


So how would I, as a Search Console user,


request a feature then?


So there are a few ways that we try to kick off new features.


And of course, users.


So when we know that users need a feature to do their jobs,


we try to make it happen.


So it could be either through Twitter.


We are over there, and we're hearing


what our users have to say.


It could be the user feedback button on Search Console.


And it could also be, for example, the search community,


the forums, where we're always also monitoring and trying


to see what people are asking and what kind of problems


they're seeing as well.


So that's one way that's how users can influence the tool.


And apart from that, we also, of course,


get requests from up above, from our leadership.


And sometimes they have ideas.


They want to cross-functional features, things like that.


And we try to do our best to incorporate those features


into Search Console.


But also, I see a lot, and usually I'm


very excited about those features.


Our engineers find ways to make it either more accurate or more


interesting or more user-friendly.


And they kind of bring new ideas and make them happen.


One example, also a very small addition,


which I think was really cool, is


that on the tables on Search Console,


you have all kinds of icons besides the pages.


And there is one to copy the URL.


And this is a feature that one of our engineers,


he, every time that he was checking something,


he had to copy the URL.


And it really annoyed him.


So he just built a feature.


And it's super cool, because it's really, really helpful.


And so I think it shows one of those examples.


So basically, again, three ways to start a new feature.


One of them is through user feedback,


through leadership requests, and also our engineers initiative.


MARTIN SPLITTENBERG


Some of the things that I'm really excited about,


and I think that we'll have more stuff coming up.


So my background is in data analytics.


And obviously, I'm biased towards data.


And how can we make more data available in a better way?


And so that's one of the things that I'm very excited about,


how we can make more data available to users


so that they can build their own solution so that they


can innovate with our data.


And I think that would be super cool.


MARTIN SPLITTENBERG That is super cool indeed, yeah.


So you're kind of saying analytics


is helping Search Console.


So we use analytics in Search.


No, we don't.


We don't use analytics in Search.


That's the first thing that I learned in the team, John,


from you.


You said we don't use analytics in Search.


That's true.


Cool.


I love seeing all of the new stuff


that the Search Console team is bringing out.


And I really like also that mix of some things coming


from users, some things coming from the team,


and some things coming from leadership, where you can really


tell that the people who are involved


are passionate about the project.


And I think it would be kind of awkward


if we didn't have people from leadership saying,


oh, you should do this, because this is fantastic.


Because if they come with these kind of requests,


that means they're aware of the product.


They know where it fits in.


And they can connect the other products around Google


to kind of make sure that Search Console plays a good role


in the whole ecosystem.


So I think that's all pretty cool.


One of the things that I've been working on on the side


in my own time is trying to figure out


a solution for my blog, where when I look at it,


I think I last published something almost 10 years ago.


So it's almost like a static site.


And I keep having to update the CMS all the time.


So that's one of those things where


I'm like, I need to find a better way


to deal with all of this.


I don't know, Martin.


How do you deal with your CMS?


Or do you still use your own?


So I have long stopped using my own CMS.


And I have also, I have to admit that I have kind of long


stopped using CMSs at all, because most of the things


that I build on the site are actually just static websites


where I control the content and there isn't that much


interactivity on it.


So I usually use a static site generator.


For the sake of simplicity, I usually use YouGo.


But I know there's so many other sites, like Eleventy


and I don't know, like there's so many different static site


generators that are fantastic.


And then you don't have all of these weird issues


with having to update things and installing security patches,


because you basically just search static HTML files.


Wow.


What a coincidence.


I don't know.


I also just started using YouGo.


Oh.


Oh, look at that.


OK.


I didn't even realize.


I didn't even check.


But it's one of those things where I thought,


well, my blog is mostly static anyway.


It might as well make it completely static.


So I looked around for different static site generators


to move to something like a more, I don't know,


static HTML setup.


And I ended up with YouGo, which uses Markdown pretty


much for the content.


So you just create text files.


And then you run some script.


And it generates a website for you.


So I thought that was pretty cool.


Kind of surprising to see.


Like independently, we came to a similar solution.


So cool.


Yeah.


I don't know.


It's one of those things where in the beginning, I thought,


well, I'll just use a static site generator


because it'll be easier.


And it'll be completely hassle-free


because what is easier than creating an HTML page?


But there's just so much involved.


I ended up spending so much time digging


into all of the different settings


and, I don't know, tweaking the themes


and setting things up so that they actually work.


I'm like, at this time, I could have, I don't know,


written something like WordPress on my own pretty much.


There's just so much involved.


But I really enjoy making pages again,


which is kind of weird.


And I ended up writing a whole bunch of blog posts


that are not published because, of course, my site is not


actually live yet, which is kind of awkward because I kind of


switched to the static site generator


because my site is static.


And then because of that, I ended up


making my site a little bit more dynamic.


So everything is kind of weird in that regard.


MARTIN SPLITT, MANDEL CARTLAND, MARTIN SPLITT, MANDEL CARTLAND,


MANDEL CARTLAND, MANDEL CARTLAND, MANDEL CARTLAND,


Does static site generator work together?


So one simple example is I wanted


to have nofollow links or have it so that I can


put nofollow links somewhere.


And in Markdown, there is no notion of nofollow links.


So essentially, I could just say, well,


I don't care about nofollow links.


It's like, what is Google going to do, penalize my blog?


We will see.


But I figured out some options, and I


can make nofollow links now.


So if you want to sell links on your site,


Martin, with nofollow, of course,


then I can help you out there.


MARTIN SPLITTENBERG


Nah, no, thanks.


I'm good.


I think I'm OK.


Oh, well.


OK.


And the other thing that took a while to figure out


is everything around redirects, where


once you have everything in static HTML,


you essentially have to use JavaScript redirects


to make all of that work.


And I don't know.


That was a little bit of a hurdle, because I was like,


oh, static site generator makes clean HTML,


and then everything for search will just work.


And then it's like, well, actually, redirects


you have to do with JavaScript.


And then I was like, oh, it's like, oh my gosh.


I've created this weird mix of JavaScript and static HTML


site, which is probably like every website out there,


I guess.


But I don't know.


You end up running into these things.


How do you see JavaScript working out nowadays, Martin?


Should I be worried?


MARTIN SPLITT


If I had been using redirects for the blog,


for the webmasters blog to the Search Central blog,


then my preference would have been the meta redirect,


because that we can understand without executing


any JavaScript.


But failing that, JavaScript should work TM.


MARTIN SPLITT Love it.


A question that I often also get with JavaScript


is if we treat JavaScript content differently.


And I mean, we do have annotations for content,


like what we think is the centerpiece of an article


or what we think is content on the side and stuff.


But as far as I know and as far as I can see,


we crawl a page and then put the content


into the document in our index.


And then we render the page, and then we


complete the content from the DOM, and then that's it.


There's nothing that is fundamentally


different between JavaScript-generated content


and static content, except for when there's edge cases


and we can't see content that is generated by JavaScript.


And I think links, right?


Links are also immediately extracted


from the crawled HTML, and then we do that again


when we have the rendered HTML.


I think there's a logic that gets us link discovery as early


as possible in the process, too.


But besides that, I think the content is pretty much treated


the same way.


So you should not be too worried about JavaScript, John.


OK, sounds good.


I mean, first I have to get my site finished anyway,


so we will see.


And maybe it'll be penalized by Google anyway because


of my bad nofollow links.


So we'll see.


Oh, you just reminded me I need to actually verify.


So I kind of, with a friend, I founded a foundation


to foster first aid training in Switzerland,


and I made a website for that.


And I don't have a Google Search Console account for it yet.


I should probably get that.


No.


Martin.


I just set up analytics, Daniel.


Calm down.


Come on.


I put my static site on Google Cloud,


and in order to do that, you verify the domain.


And because of that, it's automatically in Search Console.


It's so fantastic.


Oh, that's actually nice.


Yeah, number one ranking guaranteed.


I still don't know which keywords,


but I'm sure it'll be somewhere.


How to hack FTP.


Oh my gosh.


All of those old blog posts, I went through all of those,


and it was like, should I just delete everything


that's older than 10 years?


And I ended up going the other way,


and I found some other old sites of mine that I had,


and I put all of that content in there as well.


So it'll be like a time warp.


Wow.


It's like your own version of the Internet Archive.


I was surprised that I found all of this stuff.


And there were weird CMSs, but I don't know,


the MySQL dumps I still had there,


I was able to pull it out of there directly.


So it's super crazy.


Oh, I thought you were googling for it


and finding it, which would hint at how well optimized


your stuff was for Google Search.


I mean, the domains that I had back then,


they're mostly expired.


So it's gone.


I mean, it's probably in the Internet Archive somewhere,


but oh well.


And I thought all of this stuff is super embarrassing,


like old test sites where I realized


that actually having a link to a page helps to get it indexed.


And I was like, at the time, that was pretty mind blowing.


But nowadays, I'm like, well.


I mean, people have to learn somehow, right?


So I figured I might as well put all of this old stuff online


as well and show people that you can do weird stuff


and have, I don't know, strange questions


and try to figure it out on your own


and still, I don't know, make it somewhere.


So at least I made it to a podcast.


MARTIN SPLITTENBERG Yeah.


No, I also think an iterative process is a good idea.


I literally was like, OK, so I know


that there's people who want to book the courses,


and I need to have the booking system and stuff online.


So I basically just built a first version of it.


If you look at the copy, it is definitely not great.


I'll get someone to write proper copy for it


to actually optimize it properly.


But the first version, I'm not sharing that anywhere


because I know that people will be like, oh, look at this.


How badly done this is.


I'm like, it doesn't matter.


It currently serves our goal, and that's what it needs to do.


And if you had a question and you found out the answer


and then you publish something about it,


that serves its own goal.


So that's fine.


I think that's perfectly legitimate.


I think we're kind of probably the exceptions when


you look online because we're like, oh, we


don't care if we get a lot of traffic or not.


And the other people that we talk to, of course,


because they come to us with SEO questions,


are like, how do I get as much traffic as possible?


And I think interesting for us to try things out


and to get some hands-on experience


with these kind of sites, but the background is kind of still


different.


We kind of have to, I think, keep that in mind too.


Do you know, John, that the first fondue


that I made that was based on a recipe


that you put up on Google Frugal?


Oh my gosh.


Or whatever its name was.


Google Base, right?


Or Google Base, yes.


And I actually found that recipe without looking.


Actually, I didn't even know who you are.


I didn't know that there's a John Mueller who


works at Google.


Maybe he wasn't even working at Google at that point.


I don't know.


And I found this recipe on, apparently, Google Base.


And I made it.


And it was great.


And when I actually moved to Switzerland,


then I was looking for that recipe.


And you couldn't find it anymore.


And it was very sad.


Yeah.


I think Google Base moved on to something else.


What did it end up being?


Is that like shopping, I think?


Probably shopping.


I'll have to dig up that recipe and put it on my site


too, just for old time's sake.


Sounded like you were saying it moved on to greener pastures.


Well, it kind of did.


Very indirectly.


Oh my god.


So Gary, tell us a bit more about what's


happening in Search.


We've been kind of following along


with all of these cool stories around indexing and serving.


Like, what's the next step?


What are we missing?


So in one of the last episodes, we


talked about serving a little bit.


And we had a very high-level overview


of what's happening there.


And maybe we should start taking it apart and focus


on the different components that we have in serving


that make the magic happen.


And one of the first things that are interesting enough


that I think we should talk about


is query parsing and query understanding.


Of course, before that, there's other systems


like the load balancer and whatnot.


But I don't think that they are all that interesting


from our perspective, because they are just network


components that routed the traffic


and try their best to prevent DDoS attacks.


So let's talk about query parsing.


And I know for certain that there


is a video from Paul Harr from a webmaster conference in Mountain


View, where he talks a little bit about query parsing


and understanding.


But he covers two of the bigger elements of query parsing


But there are other elements or other aspects


to it that are also very interesting and externally very


visible.


So when we query our index, then before we can actually


send the query to the index, we have


to transform it into something that our index will actually


understand.


And that would be the parsed query.


And the parsed query, compared to the user's query,


at least in most cases, is an absolute monstrosity.


Basically, if you search for something like purchase auto


or purchase car, for example, that


becomes a massive protocol buffer.


That protocol buffer, look it up on your favorite search engine.


It's open source.


But it becomes this massive protocol buffer


with many, many, many, many words.


And that's essentially what query understanding and parsing


does, expanding the query into something that will not only


return the results that are relevant for that query,


that exact query that the user searched for,


but also very closely related queries.


And sometimes it also makes mistakes that you can see


in the video that we probably will link to in our description.


So query parsing.


First, you have to decide what to do with a query.


If you have purchase car, for example,


then there's not all that much to parse about that.


There's two words, and you probably


want to synonymize them.


But otherwise, it's fairly straightforward


what to do with it.


But if you have stuff like the Lord of the Rings,


for example, then that's a more complex query.


And you have to decide what to do with that string.


Do you treat each word separately?


Or you treat the whole thing as basically a compound


and as essentially an entity on itself?


Then there are other languages besides English.


I know.


This is a shocker.


And some languages don't have spaces in them, for example,


or traditionally don't have spaces in them.


And then you have to decide where to insert spaces.


This is especially important for languages like Thai,


where a sentence, well, a string can go on and on and on


and on and on.


And if you translate it, then there


would be multiple sentences in that one string


because they seldom use punctuation for reasons.


I don't know why.


Chinese, for example, that's also


a good example for lack of space and punctuation.


And that's just how the language is.


There's nothing wrong with it.


Users of those languages can understand them.


But for machines, it's more complicated.


So we have a system called a segmenter that


will try to split up the strings that the users supply to us


and basically create words that we can look up in our index.


Now that we have our parsed, I guess, user query,


we move on to understanding.


And in this space, we do a lot of magic.


One would be synonyms, for example, and also


anti-synonyms, I guess.


If you search for purchase car, then you would also expand it,


or we would also expand that query to, let's say,


purchase auto or buy car.


Or I forgot what the last one is, but you get the point.


Then we would also inject in the parsed query


the plural forms of the noun, I guess, in this case.


So it would be purchase cars.


And then we do other things.


I forgot to mention.


Anti-synonyms, this is Paul Haar's example where we,


this was back in 2005, I think, 2004, 2005,


where we learned for some reason automatically,


our synonym system learned that United, the airlines,


is a synonym of Continental Airlines, which was pretty bad.


And of course, I mean, if you know about the airlines


history, then you know that later they merged.


We knew it, which was great, but it was several years later.


And Paul said that he hopes that it wasn't our fault that they


merged.


We don't know.


What else do we do?


So yeah, in that case, we want to break that.


Basically, we don't want to associate United, for example,


with Continental Airlines.


Stop words.


We have to remove stop words.


If you think about it, the internet


is full of words like off, the, a, and.


In most cases, you don't need those words in the query.


You don't have to search for them because, well, they


are just not relevant.


So you can safely drop them most of the time


because there are cases where you can't actually drop them.


Like the Lord of the Rings, there you actually


need all of them to understand the query


and to detect the entity.


What else would you add if you designed a query parsing


system?


Do we do the same thing with understanding the content


on the page as well?


Or are these kind of different systems


that evolve in parallel?


They are different systems.


So when we parse a page, then we just tokenize it.


Basically, we do the splitting if the language needs it.


But otherwise, we just, well, put everything in the index


that we find on the page.


OK.


So like synonyms, it's not that we would store the synonyms


with the index.


We would pick them up when someone searches for them.


That's right.


So for example, when I search for purchase car, for example,


then if marketing split.day has a page for that


or a page for purchase auto, then we


would pick potentially that page if it doesn't suck


and would return it because we expanded the query


to purchase auto as well.


So basically, the query would become purchase car or auto.


Cool.


Would we also try to understand the language of the query?


Or is that something where we basically


say if the words are on the page,


then the language is probably OK?


So the language that becomes more interesting in a lower


level, but usually we pick up the language from the browser.


Usually.


It's not always.


Basically, if the browser sends accept language header,


for example, then we would pick that up and use that.


Or if you set your Google search language to, I don't know,


Thai, for example, then we would detect that and use that


unless it's obvious that you are not searching in that language.


Like for example, if your browser is set to Japanese


and you are using Latin characters searching


for banana, then it's more likely


that you want English results.


So cool.


So many things are happening in search and essentially all


hidden behind that tiny text box.


It's so pretty cool.


Wait, wait, wait.


You are not off the hook yet.


Oh, no.


There are way more things that happen in query parsing


and understanding.


Oh my gosh.


There is stemming, for example.


I knew it.


OK.


Tell us more.


Where you search for auto trading,


what do you do with trading?


You have to do something with trading,


because you want to expand that word to other words.


What do you do with it?


You need to find the base form, the infinitive, kind of.


Yeah.


That's stemming.


Basically, it becomes auto trading or trade.


So is that something where we have


a team of linguists that put together


a big spreadsheet with all of the different versions


of the words?


Or how does that happen?


Great question, but no.


No linguists.


This is learned automatically from the web core portal.


So basically, we have all the words on the internet.


Well, not all the words, but a large portion


of the words of the internet.


And we learn from there.


We learn how to spell things and how to do a spelling correction,


for example.


And sometimes that also does funny things


to our spell correction system, where we say that, no, you


spelled this wrong.


And you are like, dude, I learned this


when I was two years old.


I know that this is how it's spelled.


And Google insists that you spelled it wrong.


Anyway, what else do we do?


Also, you said we remove stop words, like a and the and stuff.


But what if a stop word is important?


For instance, if I search for the rock,


I probably mean the rock.


Well, then we don't remove it.


Yeah, OK.


So we put them in when we, or we leave them


in when we think it's important.


How do we know when it's important?


So there's a concept detection going on.


And we try to match the query against concepts


that we learned from, well, the internet.


And then if it matches a concept,


then it's likely that it could be that.


But of course, context also matters.


And the rock might mean something different


in different cultures or countries.


Like if you go to the US or Hawaii,


then the rock that is a completely different thing,


as in entity, than searching for the same thing in Malta.


But essentially, yes.


We match it against concepts.


And if there is a concept, then we will keep the stop word.


The stop word there.


So we would take into account the user's location


when it comes to understanding which words?


We add it as a context, yes.


So cool.


So that's important when people search for,


I don't know what a good example is,


do groceries, that's a predominantly American thing


to say.


And in the UK, they would say differently.


In Australia, they would say differently.


So that's why you need a context.


I guess we also use that for understanding


when things are more local.


Like if you're searching for pizza,


probably web search will try to say, oh, well, John


does not want a random blog with a pizza recipe.


That gets way more complicated, because there we


will have the whatever we call it.


I don't remember what we call it.


The external is called the map pack.


That will pop up.


And to that thing, we will just pass on the parse query


plus the location that was detected in a separate thread.


And we will try to give something


for the user that is very close to their location.


But that is unrelated to what we have in the parse query.


Mm-hmm.


What about numbers?


I think we also might want to have a thing that,


if I type the numeric words, like 200 or 574 or 543


and 20, which is particularly tricky,


because Germans would flip the digits so that we understand


that it's a numeric quantity.


And would the parser also rewrite


that to an actual numeric?


I actually don't know.


Try it.


I would expect that, at least in English,


it would just match up against synonyms.


But I don't know how it would work in weird languages


like Hungarian and German.


Interesting.


Is this also where we pick up things like the umlauts,


where in German you have those dots on the U, for example,


and you can also write them as U-E, like my last name,


like Mueller.


Theoretically, I have this umlaut thing on my U.


And to keep it simple, I just use the English version,


which is U-E. Would we just see those as synonyms


and learn that over time?


That is a great question.


And you will get a COVID cookie for that,


because now I have lots of cookie recipes.


That is something called critical expansion.


And we will try to expand the query with the different ways


people might write those funny characters.


So for example, the O with two dots,


that appears in many languages, Hungarian, German,


Swedish, Finnish, Dansk, I think.


What else?


That might be it, actually.


That also becomes O, just simple O,


like what you do with your name, or O-E,


which is the more traditional way to express those umlaut


characters.


Basically, we call umlaut character


any character that has two dots on it.


But they would essentially become


synonyms in the parse query.


So cool.


Yeah.


Most of the time that works.


The results are slightly different,


but I imagine that just because the parse query is


like slightly different in the end?


That is another excellent point for another COVID cookie.


So all the synonyms that we add will have a weight.


So basically, your original query, I don't know,


milling John, will have a weight of 1.


Basically, as you wrote those words,


they will count in full weight.


Any synonym that we add will have a lower weight.


And the less confident we are in the synonym,


the less weight it will have.


So basically, if you searched for milling John,


then that would be the 100% weight.


But if we add to that a synonym, let's say grinding John,


then that will have much less weight.


Of course.


Yeah.


It will just grind off the weight.


I see.


It makes very much sense.


I mean, in German, it kind of does.


Oh my gosh.


Thanks a lot.


Super insightful stuff.


I always find it fascinating with these things where I'm


like, oh, I know how this works, more or less.


And then I say something, and you're like, well, actually,


it's very different.


So that's always cool.


Anyway, so slowly things are opening up around here.


How do you all feel about making it back


to the office at some point?


No.


No?


Why no?


Look around.


It's dark.


It's warm.


I'm alone.


It's great.


But what about the kale, Gary?


You're missing kale.


Yeah, exactly.


And that's a great thing.


But what about your tiny sofa?


Oh, I threw it out.


You did?


Actually, I didn't.


I just left it on that desk.


Good.


What about eating two meals a day?


Oh, that's cute.


Gary cooks so damn well.


By the way, I should probably pop by at some point again.


Well, you're always welcome.


You can just pop over.


Thank you.


Yes.


Yeah.


We are back to the office in Tel Aviv.


What?


Like a few days a week or what?


Well, in theory, we are 50% back.


But the 50% is not calculated per person.


It's calculated per office.


Oh.


Which means that some people, well, there are still people


that they don't want to come at all.


So in the end, you can come more or less every day.


And you just have to book before.


And well, the restaurants, they're back.


And the Tel Aviv Google office has a very nice food,


which I haven't eaten for a long time.


And I want to come.


I didn't get even one COVID cookie from Gary.


So I'm kind of still, maybe because I didn't


answer any right questions.


Well, or maybe because you are in Israel.


Maybe.


But that cafe that we have, well,


cafes that we have in the Tel Aviv office,


that is in my top three.


Yeah.


Very great.


Basically, it's like Tokyo office and Tel Aviv office,


they are competing for the first spot.


So you would go back to the office


if you could go back to Tel Aviv?


I would probably want to go to Tel Aviv just to eat.


The food is so amazing.


But I think even more than the food,


like being back to the office, I think over the last few weeks


since we started coming back more often,


it's been really nice.


I think what changes it is that there is a certain threshold


that it's becoming really interesting.


And it really helps also when it comes to work.


So what I'm trying to say is that people,


there are many people in the team


that I used to have a day-to-day interaction.


And we would sometimes eat together lunch


or go for a walk in the middle of the day


or just meet in the microkitchen.


And I would hear about new projects in the team


and what's going on.


And this kind of stuff, I think at least, or maybe it's me,


but I didn't keep this kind of social interaction with people


that are not really good friends.


Like I have some good friends in the team


that we kept in touch and meeting during the last year.


But I think now that we have more people back to the office,


I can see how having an office and a microkitchen


and how it encourages creativity and interaction between people.


And so I think that part is really nice.


And I'm really happy to be back partially for now.


But I think I'll also come back fully when


everything opens as normal.


Yeah, I really kind of miss those social interactions


where you just see different faces during the day.


I'm kind of curious to see how it'll end up where it's like,


you've been working at home for such a long time


and then kind of suddenly transitioning back


to having to interact with real people


and not just being in front of your own computer kind of thing.


John, usually we were standing at our desks with our headphones


on.


Because that's exactly what you expected me to get you.


OK, we will need to beep out the following five seconds.


And sometimes Anna, our video producer,


just came by with tons of equipment


because she had her desk near ours.


I don't think we have desks anymore.


It's like all is up for grabs when you book


to go into the office right now.


But we used to have our own desks.


And then Anna, our producer, was nearby.


And then she lugged around all this equipment.


I was like, all right, ladies and gents,


we are recording a podcast today.


We're like, yeah, we totally knew that.


And we totally prepped for it too.


So, you know, office days.


I'm sure we'll just have bouncy balls all over.


And then everyone gets a bouncy ball and no more desks.


Ball pits.


We'll see.


Anyway, maybe we should take a break here before we


get too far off tangent and figure out


what all we're missing.


Oh, man, so many things.


Anyway, thank you for joining us, Daniel.


It was great having you here.


Where can folks find you online if they have more questions


about Search Console?


They can.


Questions?


I'm not answering any questions.


Well, I'm usually only.


No, questions.


I'm usually on Twitter.


And I kind of read the questions.


I'm not as good as you guys answering them.


But I'm usually at least reading the questions.


And when there is something that, you know, well,


we find bugs or, well, not bugs because Search Console does not


have bugs, but things behaving in a different way, let's say.


So I'm mostly on Twitter.


And of course, Search Central YouTube channel.


So well, we all have videos there.


I have the Search Console training,


which is over for now.


We'll see how it goes.


But it's over there.


So cool.


Yeah.


So should we stay tuned?


Stay tuned, Martin.


Oh my gosh.


Well, I don't know.


Martin is about to fall from his chair.


It's been fun doing these podcasts.


And I hope you, the listener, have


been finding them both entertaining and insightful


as well.


At any rate, let us know how you're liking these


and if there are any topics that you


think we should be covering in one of the future episodes.


And of course, don't forget to like and subscribe.


Bye, everyone.


Bye.


Stay tuned.


Yum tov.


Performance reports in Search Console - Google Search Console Training

Hi, I'm Daniel Weisberg, Search Advocate at Google, and in this video I'll talk about


how to use Search Console to monitor your site's performance in Google Search.


By the end of this video, you should be able to find data to answer important questions


about your site.


For example, how often people see your website in search results and click to visit it.


What are the top search queries used to discover your site's content?


Which countries, devices, and search features work best for your site?


Those are just a few questions.


Let's dive deeper and find even more interesting insights you can learn about your site's performance


on Google Search.


The performance reports are divided into two


sections – Search and Discover.


All accounts have data on Search.


In addition, websites that have accumulated meaningful search traffic in Discover will


see a report for it.


In this video, I'll focus on search performance, as it is the most common use case.


Before we go into the details of the report, I want to say a few words about metrics and


dimensions, which are fundamental concepts to understand the data.


Metrics are quantitative measurements.


They are the numbers you see for each of the columns of a table or on a chart.


They usually describe how much and how often.


For example, in the performance report, you'll find four metrics.


Impressions, the number of times your site appeared in a search result.


Clicks, the total number of times users clicked from a search result to your website.


Average click-through rate, or CTR, the percentage of impressions that resulted in a click.


Average position, the average position of your site in search results, based on its


highest position whenever it appeared in a search result.


Dimensions are attributes of your data.


They usually describe who did something or where it happened.


For example, the dimension countries indicates the country where searches for your site originated,


like United States or Japan.


The dimension pages indicates the page that was viewed on a search or was clicked by a


user.


Note that pages refer to the canonical page, which means that if you have duplicate pages,


only one of them will be shown.


You can read more about it in our Help Center.


The performance report is built out of three main elements, the future bar, the chart,


and the table.


Let's start with the chart, as it's the most beautiful visual element.


An image is worth a thousand words.


The first thing you need to know about the chart is that you can choose the metrics that


you want to see, including impressions, clicks, average CTR, and average position.


In order to see the trends for different metrics, you simply need to click the metrics themselves


to add or remove them from the chart.


Note that if you add or remove a metric, it will update both the chart and the table.


The table element allows you to break down the metrics according to the possible dimensions


that you can see just above the table, queries, pages, countries, et cetera.


You can click each of those dimensions to see a table with the metrics for that dimension.


For example, if you click countries, you will see a list of all countries where your site


was shown in search results and how many clicks it generated.


Here are four ideas on what to look for when analyzing your performance data.


Low click-through rate.


If the number of impressions is significantly higher than clicks, or in other words, if


the click-through rate or CTR is very low for a query or a page, you might need to create


better titles and snippets in search results in order to make your site more attractive


to users.


Missing search queries.


If search queries that you expect to see don't appear, your site might not have enough useful


content relevant to those queries.


Missing pages.


If important pages on your site are not in the pages list, there might be an issue with


them.


In that case, you should use inspect URL to find out why.


We'll go over this tool in the next video.


Branded search queries.


Check how many queries show your site when the user does or doesn't include a specific


string, such as your site's name.


These might show interesting areas where people are searching for content directly related


to your brand.


I'll talk about how to use filters in a second.


Those are just a few examples of what information you can learn from the default reports.


But sometimes, checking the aggregate dimensions and metrics might not be enough.


Using data can help you find interesting insights about your performance on search by helping


you to explore a more specific scenario.


To do so, use report filters.


You'll find them just above the chart.


Alternatively, you can simply click a relevant role in the table, such as a specific country.


Doing that will filter the data in all the performance reports to include only the clicked


country.


Let's try a future.


Click New on the filter bar above the chart.


You'll be asked to choose a dimension for which you'd like to create the filter.


You can currently add filters for each of the dimensions available on the tables and


also search type and date.


Here are some filters that may help you understand your search traffic.


Check what queries or pages are bringing traffic through image search results by adding a search


type filter and choosing Image.