So from a more general point of view,


English Google SEO office-hours from March 18, 2022

the alt text is meant as a kind of a replacement


or description of the image.


And that's something that is particularly useful for people


who can't look at individual images, who use things


like screen readers.


But it also helps search engines to understand


what this image is about.


And if you already have the same description for a product


around the image, then for search engines,


we kind of have what we need.


But for people with screen readers,


maybe it still makes sense to have some kind of alt text


for that specific image.


And in a case like this, I would avoid the situation


where you're just repeating the same thing over and over.


So avoid having a title of a product


be used as an alt text for the image,


but rather kind of describe the image


in a slightly different way.


So that's kind of the recommendation


I would have there.


I wouldn't just blindly copy and paste the same text


that you already have on a page as an alt text from the image,


because that doesn't really help search engines.


And it doesn't really help people


who rely on screen readers.


When adding content to a site, could we


expect to see results pretty quickly,


or would we need to wait for an update to see the full effects?


So there's no artificial timing on our side


with regards to making changes on a website.


So it's not that we artificially hold things back


for a specific period of time or a specific update.


It's really when we can recrawl and reprocess the page,


we'll try to reflect that in the search results


as quickly as possible.


So if you change a text on a page,


then usually as soon as we can recrawl that,


that text can be findable in search.


And if you search for that specifically,


it should come up.


And that can be after several seconds


after making that change if we can pick it up really quickly.


Sometimes we crawl pages a little bit slower in that


maybe it takes a few weeks or a few months for us


to recrawl that individual page.


And that's kind of the timeline that you


would have in a case like that.


And this kind of crawl rate depends on the website


and on the specific pages themselves.


So it can happen that the home page we crawl very quickly,


and maybe one of the articles or the product pages


is crawled a bit slower.


Yeah, let me see.


Mark has a question.


Would you use alt tags for images


that use only decoration within a longer text?


Or how would you treat those mostly stock images?


I think it's totally up to you.


So I can't speak for the accessibility point of view.


So that's kind of like the one angle that is there.


But from an SEO point of view, the alt text


really helps us to understand the image better


for image search.


And if you don't care about this image for image search,


then it's fine.


Do whatever you want with it.


And that's something for decorative images.


Sometimes you just don't care for things like stock photos


where you know that the same image is


on lots of other sites.


You don't care about image search for that.


Do whatever you want to do there.


And I would focus more on the accessibility aspect there


rather than the pure SEO aspect.


It's not the case that we would say a web, like a textual web


page has more value because it has images.


It's really just, well, we see the alt text


and we apply that to the image.


And if someone searches for the image,


we can use that to better understand the image.


It's not that the web page in kind of the text web search


would rank better because it has an image.


Cool.


Let's see.


Our CMS automatically updates the last modified date


for every change, even when adding a few words,


fixing a spelling mistake, or adding an internal link.


Is this a good SEO practice or should the last modified date


only be updated when there is substantial changes


to the content?


I think people do it in different ways.


I don't think from an SEO point of view it matters much.


So when we look at things like sitemap files


where there is also a last modified date,


the sitemap team ideally wants to see that date updated


whenever there are any changes on the page,


when it makes sense for us to recrawl that page.


And that includes things like a random link in the sidebar,


for example.


So from that point of view, people do it in different ways,


and it should just work out.


With regards to kind of the last modified date


in the structured data itself, usually I


think it makes sense to have something


aligned with when the primary content actually changes.


But if there are technical reasons


why you have to do that immediately


or why your CMS does it immediately,


I don't see a problem with that.


When it comes to dates on the page


that we sometimes show in a snippet, what happens there


is we try to find multiple mentions of that date


on the page kind of as a confirmation.


And then we use that as something where we say,


well, this date is probably associated with this page.


And it's fairly certain that it's a reasonable date.


And if we were to show a date in the snippet,


we would probably choose that one.


We don't show a date in the snippet for all pages.


And it's really something where you


can help to guide that as well by making sure


that maybe there is a visible date on the page as well.


So if you have a news article, for example,


and there is a visible date on the page


and the SIPA file has a slightly different date,


then probably we will give that visible date


a little bit more weight.


So that might be another way that you


can control that a little bit.


Let's see, maybe we'll switch to some more live questions


from you all.


Don't have a ton of people raising hands, but that's fine.


Let's see, Akash, go for it.


Hi, sir.


Hi.


So my question is related to the way the links are added.


So one of my technical members has


added the links in the form of like underscore self


or underscore target or underscore equal to blank.


I can add a few examples over here in the chat box.


How Google bots are able to crawl these things?


Do they understand that there are


links added to this particular tag, something


over here that mentioned?


Because this kind of structure has


been present for most of my particular client's websites.


And I don't know because when we use


a different type of crawler, like suppose


streaming fog or some other crawler,


those crawlers are able to detect the link.


But I have no idea how Google bots and all of them


are able to treat this.


And in the example, you have a trex, a tref, equals,


and then just empty quotes.


Is there usually a link there?


No, so what they mean is like underscore self,


like target is equal to underscore self,


will itself be a link?


And if you click on that, you will definitely


get to the particular link, which actually works.


Like if a user comes to my page and he


wants it to go up a particular page,


these structures might help them.


But I didn't find a particular link in the, you know,


a tref is equal to something.


So I don't know how these structures are working,


but they are working.


And the other crawler, like as I mentioned,


the streaming fog, they are able to detect


this kind of structure.


These are the correct links which are added over here.


But there is no link over here.


So I really wanted to know the overall pattern of the bot.


Will they also be able to detect that?


Because the streaming fog is, again,


I think the random way the bot crawl and render the biggest.


Yeah, so the target attribute there, I think we just ignore.


Because it makes more sense from a browser point of view


what happens.


Usually, the target attribute, as far as I recall,


refers to how that link should be open.


So if you have a frame on a page,


then it will open that link in a frame, for example,


or in a new tab, those kind of things.


And from our point of view, we don't care.


So we ignore the target attribute.


So that target equals and then underscore self,


it's basically we ignore that.


The href attribute in the link is essentially


what we focus on.


If there is no href value given there,


then essentially that link goes to the same page,


and we ignore that.


So from our point of view, if we were to see something


like you posted in chat where it's like a target equals self


and then href equals nothing, we would


think that this is something that we can drop.


Because there's no kind of source and destination


for that individual link.


Because it just points to itself again.


If you had a URL after the href equals,


then we would treat that as a normal link to that page.


Two more questions, sir.


John is related to the breadcrumbs.


There's a usual pattern that I have seen


on most of the websites.


If there is a page at level three,


so let's say a specific blog pages.


So our subsets are usually at the home page,


we link something at the blog page,


and then the blog specific pages.


However, for an e-commerce page, like a product page,


where a user can reach to that particular page


through multiple ways, through filters, through brand pages,


through city level pages, or directly through the pages.


So I've seen an example of multiple breadcrumbs


within that particular page.


Like these are the different ways


that you can reach to this particular product pages.


But when I see the pattern in the sub,


so like this was for a particular product,


and just about your title, your breadcrumb has been listed.


So that structure is something which I have not


mentioned in my breadcrumb schema.


Neither that particular thing has been added on it


as an on-page breadcrumb on my pages.


So how these things correlate to each other.


Yeah, I suspect what is happening


there is that you have multiple breadcrumb


schemas on the same page.


And we don't know what to do with them.


So we ignore them completely.


And we try to figure it out ourselves.


So from that point of view, if you're


kind of giving us conflicting markup,


then it can happen that we don't use any of that.


And we treat it as if there's no breadcrumb markup


at all on this page.


So I could imagine that's what's happening there.


And when we don't have any breadcrumb markup at all,


sometimes we will try to figure out what the path is


leading to that page.


Sometimes we will rely on the URL structure,


like the folders that you have there.


And we will show that.


So usually what I would recommend in a case like this


is for you to make sure that you have just one


set of that markup on the pages so that we can pick that markup


up and say, oh, well, here's reasonable markup.


We will just use it.


If you have visible breadcrumbs on the page that


show kind of different paths, that's fine,


as long as the structured data is really


for one specific version.


OK.


And one last one.


Sure.


Recently, for one of my clients, I


see there were a couple of pages who were ranking


for some specific queries.


But I think it's been to which I see for any of the queries,


my home page is getting ranked.


So a kind of minor update from the search side,


and it happens all the time that I know.


But how is that possible?


Like for each and all, for every query,


there is only my home page is getting ranked,


and all of the pages are suddenly disappeared


from the search.


How is Google creating it?


So that the home page is ranking instead


of the more specific page?


Or how do you mean?


Yes.


Yes, yes.


I don't know.


But the pattern is such that earlier, we


used to rank for some specific queries, specific pages.


We have the dedicated page up here.


But could be a bug, I guess.


But this is the usual pattern that I'm


like for all my queries, let's say only the home page is


seen on the search.


For the specific position as well,


it could be like for position 3, for position 10, 15,


or maybe somewhere else.


But basically, the home page is getting set.


It's hard to say.


Usually, that means that we think


the home page is a better match for that specific query.


And it could be that some of the information


is on the home page itself.


It could be that the more detailed page


is seen as not such a good page from our point of view.


Usually, it's one of those versions.


And it's something where you can experiment


with kind of like removing some of that information


from the home page.


But you kind of have to also think


about what you can do to improve the detail page in that regard.


Because what you kind of want to avoid happening


is that you remove the home page from the search results.


And then nothing ranks from your website for that query anymore.


Yeah, it's sometimes tricky to find that balance.


So because this is happening from last two weeks,


I've seen the internal search here, the breadcrumbs.


Everything looks good to me trying


to add some more other relevant information.


But can we tell with the help of breadcrumbs


or internal links, which are the anchor types or the things


that we are trying to match for the particular target page


and rank in the sample?


Is this still the best way?


Or we are still lacking from two pointers


that we definitely need to focus upon?


I think that always helps.


So internal linking is one of those ways


that you can give us more information


about the relative context of your individual pages.


And for internal linking, we take into account


things like the anchor text, which gives us


a lot of information about what you think


is relevant on the other page.


So sometimes with internal linking, you can help there.


But especially when we're talking about the home page


versus a detail page, if you link from the home page


with an anchor text to a detail page,


then you also include that text on the home page


because it's kind of a part of the anchor text.


So it's kind of like sometimes a bit tricky


to find that balance.


OK.


We'll walk up on that point.


I have got the hint.


But thank you so much.


Sure.


Cool.


Let's see.


Laslo.


Let me first unmute.


Good morning, John from Zurich.


Good morning, everyone.


I have two questions.


I also raised one of the questions


earlier ahead of the event.


So we have typical on home pages a hero image.


And the hero image is embedded not with the image tag,


but rather as a background image.


With that, we're lacking the possibility


to add an alt attribute to describe the image.


There are maybe some technical aspects


why the agency has done that approach for us.


But I was wondering, what is the recommendation


if we want to have the image indexed,


so be available on the image search on Google,


but also to understand how is Google judging


if the image is embedded as a background image,


the relevance for the page, and also the text that we


can't put behind the image?


Yeah.


So I think for the most part, if you're


using something like a CSS background


attribute to display an image, then we would not


pick that up for image search.


It might be that that has changed in the meantime.


But at least in the past, it was such


that we only focused on the image tag, the source attribute


for the image tag.


And if you had a picture element,


then that's still within the same thing.


And the other option was if you link to an image file directly,


then we would also be able to pick that up for image search.


But if it's purely a CSS background image,


then we, at least in the past, did not pick that up.


And it sounds like that's still the case.


So it's tricky for me to say how you can best embed that.


One thing you could potentially do


is make sure that it's at least linked on the page


itself if you care about it for image search.


It is also something where sometimes it's


not critical for that image to be findable in image search.


So if you have something like a decorative image of your,


I don't know, your company's headquarters or something,


then in image search, it's going to be rare that someone


actually searches for that.


So that's something where you also


have to almost make a judgment call of, well, technically,


if we want traffic from image search,


this is the way to do it.


But in practice, that particular traffic from image search


is not critical for our website.


So we don't necessarily care about that.


And OK, I understood that one and about not


be able to describe, I know, I mean,


the alt attribute and the title attribute


could potentially be used to describe the image.


Would the title be enough?


We're probably using a diff tag.


And then, yeah, with CSS, we style it.


Would the title be enough to describe the image


so that Google understands, OK, this is the image that we have


or we have something here, and the title


would give more context.


OK, what's here?


OK, good.


Yeah, so for image search, we use


a number of different things.


The alt attribute is kind of the most straightforward one.


But we also look at the text around the image itself.


We look at things like the title tag,


if you have a link to an image file.


So things like the headings on the page,


the captions below the image, even that


will be taken into account for image search.


So title attribute is usually the easiest way


to kind of give that information.


It's not the only thing that we use.


So then my second question is, and let me a little bit more


broadly explain what our challenge is.


We are a B2B2C company, and we have showrooms.


But the showrooms are not under our brand,


but rather they are our B2B partners.


Now, how can we make those locations be more


accessible on Google Maps?


So if someone searches on Google for either a product


or even for a company name, a part of the company name,


that we can kind of push the information that we have


on our own website, kind of a dealer locator or showroom


locator, to make all those hundreds of locations


better accessible on Google Maps?


I don't know.


So I think the closest help I can give you there


is that if you have individual pages


for the individual locations, then we


can kind of associate that and recognize


the address on those pages and the opening hours


and things like that.


We don't need to know which products are in which locations,


but at least you'd have one landing page per location.


And then the part with regards to Google Maps


is more about the Google Business Profiles,


I think they're called, the Google My Business entries.


And I don't really have much insight into that side.


I believe there is a way to kind of bulk upload locations


as well, but I don't have any insight there.


That's something where I believe there


is a help forum for Google local businesses,


or I don't know what they're called nowadays.


The business profile pages where you can go and kind of ask


specifically about that.


And those would then be visible in Google Maps,


and they would be visible then in the map


that we sometimes show in the search results


when someone is looking for a business


name or a kind of a product.


OK.


Maybe a follow up question to that.


I mean, that was years ago, and maybe that has changed.


On Google Earth, you had once this KLM kind of an XML format.


Would that also be an alternative


to provide all the details of location


via a certain interface that?


I don't think we use that anymore.


So we used to have Geo sitemap files, which were connected


to, I think, the KLM files.


But I don't think that's used at all anymore.


OK, good.


Thanks a lot, John.


Sure.


Cool.


All right.


Let me pause the recording here.


Thank you all for sticking around.


I see there's still some more hands up,


so I still have more time afterwards to go through those.


If you're watching this on YouTube,


thanks for sticking around to the end.


If you'd like to submit questions,


we set up the community or set up


an entry in the community page usually a couple of days


before the event takes place.


And if you'd like to join these live,


I post the link there as well.


So again, thank you for submitting all of the questions


6 Tips for optimizing your website with JavaScript

JavaScript is commonly used to build modern websites to create richer, more engaging experiences


for users.


JavaScript is also a common source of performance problems on websites.


My name is Alan Kent and I'm a Developer Advocate at Google specializing in e-commerce.


In this episode, I run through six tips related to JavaScript libraries and frameworks that


can help improve your e-commerce site.


First, what is JavaScript?


JavaScript is a programming language that has become popular as it is supported by web


browsers.


JavaScript allows web developers to write code that reacts to user interactions, manipulating


the HTML markup on a page to change what the user sees.


What JavaScript has made possible is richer and more sophisticated user interactions than


is supported by native HTML markup alone.


For example, a mini-cart on an e-commerce site is typically implemented using JavaScript.


The cart icon often shows the dynamically updated number of items in the cart and when


clicked on, displays the current cart contents, allowing users to view and adjust the cart


contents.


Advanced site navigation menus are also frequently implemented using JavaScript.


JavaScript can also be used to collect site analytics to give you greater insights into


how your site is performing.


These days, there are many JavaScript frameworks and libraries and components available that


you can use on your own site.


One reason for the development of JavaScript libraries is that not all browsers are compatible


in their JavaScript and CSS support.


Sophisticated components can require substantial development to be reliable across a range


of browsers, so it is natural to want to reuse them across multiple projects.


While improving user experience and saving development time, watch out for the following


problems.


Tip number one is to avoid proliferation in the number of JavaScript files on your site.


The number of JavaScript files may rise if care is not taken, especially if each UI component


is kept in a separate file.


There are overheads per downloaded file, especially for websites that only support HTTP one.


There are a number of free tools available to work out if your site has too many JavaScript


files.


Another tool that combines both data from real users and lab testing is PageSpeed Insights.


To use PageSpeed Insights, simply enter the URL of a page on your public site.


The opportunities section of the PageSpeed Insights report lists recommendations specific


to your site.


For example, the recommendation keep request counts low and transfer sizes small when expanded


summarizes the number and sizes of resource types requested, including JavaScript files.


There are a number of techniques that can be used to reduce the number of files to download,


but solving the problem depends also on the flexibility of the platform or tools you are


using.


For example, many content management systems restrict access to JavaScript to simplify


the job for content creators and reduce the risk of mistakes.


This however can also make it harder to address issues that the platform does not solve.


If you have a large number of small JavaScript files, it may be more efficient to join those


files together to have a single larger file to download.


In practice, it is common to bundle files into a few larger files that can be downloaded


in parallel for greater efficiency.


If you have control over the JavaScript files on your site, you may find JavaScript bundling


tools such as Webpack useful to simplify this process.


Note that supporting HTTP2 on your site can improve performance without joining files


as HTTP2 improves the efficiency of downloading multiple small files.


The second tip is to avoid an excessive number of DNS lookups for the referenced JavaScript


files.


If JavaScript files are loaded from different domain names, there may be a DNS lookup overhead


per domain name referenced.


If excessive, this can slow down the first visit of a user to your site.


Files such as PageSpeed Insights may show you a list of domain names used in URLs in


sections such as reduced JavaScript execution time, but you may find using the Network tab


inside Chrome Developer Tools a more reliable way to see all the domain names referenced.


Note that unlike cookies, you cannot easily request the DNS cache to be cleared, making


DNS issues harder to detect.


To reduce the number of DNS lookups, consider whether to host a copy of externally referenced


JavaScript files on your own site.


This is not always a clear-cut decision whether to self-host JavaScript files, as if you download


a popular JavaScript library from a central site, it may already be in the browser cache


due to the user visiting some other site that also uses the same library.


Putting a copy on your own site may save you the DNS lookup, but add a larger cost of downloading


the file a second time.


The third tip is to eliminate inefficient JavaScript from your site.


Poor quality JavaScript can slow down web pages, leading to bad user experiences.


There are multiple opportunities reported by PageSpeed Insights that can be hints of


inefficient JavaScript on your site.


Reduced JavaScript execution time reports scripts where a relatively large amount of


CPU time was spent parsing or executing JavaScript code.


Eliminate render-blocking resources includes JavaScript which may be executed before the


page can be rendered, making the user wait longer to see any content.


The JavaScript function document.write, if misused, can cause significant performance


issues on a page, as it blocks other operations from occurring.


For example, performance testing has shown that adding a script inclusion via document.write


can double the length of time it takes to load a web page, especially on slow networks.


Not using passive listeners can also slow down a site.


A passive listener is a hint to the browser that JavaScript code will not call a function


that prevents scrolling, allowing the browser to scroll the page even while the JavaScript


is still executing.


These were a few common examples, but there are many other causes of performance issues.


Making JavaScript more efficient is a large topic and beyond the scope of this video.


The solutions generally involve writing the JavaScript code differently.


There are many good resources available on the web describing various techniques, from


profiling existing code to writing your own cut-down versions of more powerful components.


Unused JavaScript is another form of inefficiency, but it is common enough to be called that


as its own tip.


Reuse of code across sites can lead to sites including JavaScript that is not needed.


For example, most websites do not use all of the functionality provided by a library


or framework, or a component may be used that has more features than are needed.


JavaScript code that is never called still needs to be downloaded and parsed by the web


browser, wasting resources.


To see if your site has potentially unused JavaScript, the PageSpeed Insights report


has a Reduce Unused JavaScript section.


This includes JavaScript that was not executed as part of loading a page.


The PageSpeed Insights Avoid Enormous Network Payloads can also be the result of downloading


large JavaScript libraries, which may also identify potential areas for improvement.


In addition, Minimize Main Threadwork includes time spent parsing, compiling, and executing


JavaScript.


Eliminating unused JavaScript can reduce these overheads.


There are a range of tools to identify JavaScript that is not used.


Techniques such as tree shaking can be used to identify JavaScript that is never called


on a site and so can be deleted from downloads.


Care must be taken, as execution of JavaScript may be dependent upon environmental factors.


For example, with A-B testing, a section of JavaScript may only be run for some users.


The code must stay on the site, even if the profiler reports it is not executed.


Tip number five is to make sure your JavaScript files are compressed when downloaded, especially


for larger files.


JavaScript file generally compresses well, reducing the number of bytes to be downloaded


by the web browser.


While the web browser does have to spend more CPU time to decompress the file contents,


compression is normally an overall win.


Again, the PageSpeed Insight report has a section describing JavaScript files that may


benefit from being compressed.


Expand the Enable Text Compression opportunity to see which files are recommended to be compressed.


Uncompressed JavaScript downloads are usually relatively straightforward to fix when identified.


Most web browsers or content management systems have built-in support to compress downloads,


if appropriately configured.


Another worthwhile tip is to check that your JavaScript files are returned with appropriate


cache expiry time headers.


This helps browsers avoid the overhead of checking if JavaScript files in its cache


are out of date, improving performance.


To check if your site is set up appropriately, the Networking tab of Chrome Developer Tools


can be used to check the HTTP response headers for JavaScript files that are downloaded.


Look for headers such as Cache Control.


Also, the Serve Static Assets with an Efficient Cache Policy opportunity in the PageSpeed


Insights report lists resources, including JavaScript files, that may benefit from appropriately


set cache headers.


The first step to fixing any issues on your site is to make sure the website is returning


appropriate cached lifetime headers to help browsers cache JavaScript files correctly.


However, care must be taken to make sure that JavaScript files can be updated when required


to correct site defects or introduce new functionality.


One strategy is to include a version number or hash of the file contents as part of the


URL on the downloaded file.


That way, a new URL is used for each variation of the file.


Another approach to enhance the caching of commonly used JavaScript files is to reference


files from a shared public location.


If a user visits sites that reuse the same JavaScript file, the browser can use the previously


downloaded copy of the file, improving performance.


To wrap up, JavaScript has made it possible to significantly improve the experience of


users on your website.


Care must, however, be taken to avoid common performance problems that can arise when using


JavaScript.


There are many great resources on the web to help with these different issues.


My colleague Martin Split also has some great content focusing on JavaScript on websites.


Thanks for watching.


If you enjoyed this video, make sure to click subscribe to keep up with the latest videos


English Google SEO office-hours from August 6, 2021

All right, welcome, everyone, to today's Google Search Central


SEO Office Hours Hangouts.


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'll try to find answers.


A bunch of questions were submitted on YouTube already.


So we can go through some of those.


But maybe, like always, if any of you


want to get started with a question,


we can go and look at those first.


It looks like some of you already


have your hands raised.


So we can go through that.


Let's see, Praveen.


PRAVEEN KUMAR KUMAR, JR. Hi, John.


So my question is about expired domains.


So from past few weeks or so months, what I'm seeing


is there are some sites that are ranking prominently


in search.


So when I look at their website, they


don't look like a quality websites.


And when I look their history, like through a web archive,


so it came to my notice that those domains usually,


like they belong to Indian government agencies,


some institutions, government institutions.


So what the government institution did


is they created new websites.


And since they are government, they


don't care about migrations of 301 redirections


and all that stuff.


So they created their new websites.


And I went in these old ones.


They got expired.


Someone bought those domains and now created


a block kind of thing.


So initially, they started writing about government jobs.


And then they started writing about education.


Now they are writing about health topics,


like on vaccines.


And they are ranking prominently on best vaccine.


The best vaccine to take and all that stuff.


So what can we do about such domains?


Well, I think they are just ranking based on their history,


like the domain history and links,


because they got links from sites like Wikipedia


or some government official website.


I can share a few links if you want to have a look,


like the kind of content they produce.


Sure.


I mean, it's hard to say without looking at the specifics.


But we do have systems in place that


try to catch these expired domains


and to figure out how to handle them better.


But if you have some examples, I'm


happy to pass them on to your team.


It also sounds like something where you're not


sure if it's spam or not.


And for those kind of things, I would just also


use a spam report form and kind of let us know from there


what you've been seeing.


And if it's not spam, then the website team


will recognize that as well.


But that's, I think, always a useful approach too.


Yeah.


Yeah, I think what good it would do


depends for health topics is that they should be written


by someone who's a specialist or someone who's


health specialist or doctor.


But if you just go through, I just shared the links.


If you just go through these links,


there's no way you can figure out


how this information based on what conclusion they are saying


that this is the best or this is what


you should do for vaccinations.


It makes these sites, I think it's mainly


because they have a domain history.


So that's what boosting their rankings feels like.


I don't know.


It's hard to say because there are always


so many factors that are involved with regards


to kind of showing up in search.


But I don't know.


It's hard to say off day.


I just shared the examples, if you get time, please go.


Sure.


Thank you.


All right.


Evan.


Hi, thank you for doing this.


We have a thing we noticed back in June.


We have a website that's been around for nine years


with a huge copyrighted database of 200,000 profiles


that we've manually written over nine years


with a team of 40 writers.


And there's always been websites that


have copied our entire database and just literally sometimes


they copy our terms of use page and our team page


that are blatant about it.


But they copy our website.


And we've noticed that they're showing up in search,


sometimes above us.


And sometimes they might copy like maybe


if we have 700 words on the page, 250 words,


and then they'll add additional machine text


that are pages longer.


Or other times they'll just copy it directly.


And again, it's never been an issue


because we've ranked ahead of them.


But lately they've been ranking ahead of us


with our copyrighted content.


And I think the most concerning thing we noticed


is that when we kind of do a quote search


and search for two of our sentences in Google,


the five or six copycat sites show up.


And then our site doesn't show up.


And it says, in order to show you


the most relevant results, we've omitted some entries.


So it's almost as if it reversed.


And now it thinks we're the copycat, even


we're the original source.


So we've went down the DMCA path,


but it's hard to do that at a full domain level.


And we accidentally de-indexed our site two months ago


when we launched a different language.


So we're wondering if maybe that one day we de-indexed,


once we re-indexed it, Google thought


that these copycat sites were the original source.


So we're running in service.


We got two of the sites removed via DMCA web host,


but then they just moved to another host.


So we are the source.


It's a copyrighted database, but other sites


are ranking ahead of us with our direct content.


So we're kind of running in circles.


Yeah.


I think, in general, the DMCA approach is probably


the correct approach to take there,


because that's kind of the most direct process that


involves that.


And it is something that is on a per URL basis primarily.


So if you have a lot of, I don't know,


or if a site has a lot of copies of your content,


then it's kind of a lot of work to get that done.


But that's kind of the ideal approach,


because that's, I don't know, the official path for you


to say, well, this is my content,


and it's not their content, and I can prove it


to you kind of thing.


With regards to kind of being de-indexed for a brief time,


I don't think that should play a role there.


That's something that's like, these kind of things


happen on a technical level from now, every now and then.


And sometimes legitimate sites do something wrong,


and they go offline for a day or so,


and that fixes itself automatically again.


It's not something that would be held against the site.


And how do you DMC if they keep once their new domains pop up?


So once you get it blocked, they move it to another domain.


It's kind of like a never-ending game.


So how do you kind of let Google ultimately know


that you're the initial source?


Some of these other sites might have a zero authority,


like random domains, and we have an eight authority or 10


authority been around for nine years.


So how do we kind of, I don't know,


fix the error, if you will, of Google not recognizing


that we're the original source?


Because it keeps happening on new domains once we snap them.


Yeah.


I don't think there is this one trick that you can do to say,


well, this is always our content.


So that's one thing to keep in mind.


The other thing I usually try to recommend


is to focus on sites that are actually


a problem for your site in terms of,


are they actually ranking above your site or not?


Because it's very easy to go and search for an exact copy,


and you'll find tons of copies on the web.


But just because those copies exist


doesn't mean they're a problem for your website.


The last question on that, how about the omitted results


when we search two sentences in quotes,


and they show eight copycats, but then ours


is actually one omitted?


That was the most glaring concern,


because Google's almost saying, this is a supplemental site.


We're not going to show.


But it's showing.


So again, it's at the bottom being omitted,


but the copycats that are just blatantly copying


are being shown.


So how do you know?


Now, I think that's more of a technical thing with regards


to how you search.


So that's something that, depending on the type of query


that you do, it's possible to trigger that.


But it doesn't mean that Google thinks your site is a copy.


OK.


So I don't know.


There are a few of those things around search


where if you search in a very specific way,


then it comes out as like, well, Google is showing this,


and it probably means that.


But it's just, well, Google systems showing you something.


It doesn't mean that it has any additional meaning past that.


OK, and then for the DMCA, since it's so hard to do a URL


by URL, if you're talking about 200,000 unique pieces


of content, I know there's an email you can submit to Google,


like a more formal request on the entire URL database.


Because it's hard to do it one by one, obviously.


So how would you suggest scaling that?


If there's five sites that are a problem,


200,000 URLs per site, that's a lot of clerical work.


I don't know.


I don't have any experience with that side.


So I mean, that's something where I don't know if we have


a contact address for that.


It might be that it's primarily through the form.


My understanding was that if we recognize that sites submit


a lot of DMCA complaints, then we'll reach out and see


if there are more scalable ways to do that.


But I don't know what the actual process is there.


OK, thank you very much.


I appreciate it.


Thank you.


All right, Elster.


Hi, John.


How are you?


Hi.


Thanks again for doing this.


I've got one question, which is in the comments.


And apologies if this has already


been asked in a previous Hangout.


But I own a website called Healthy Principles.


And it's dotco.uk cctld.


Should we be writing in British English or American English?


And we've sort of switched from British English


to American English because about 60% to 70%


of the traffic is from the US.


So what's your advice?


I don't think it matters.


It's totally up to you and something


where I would focus more on what your users want to read


and less on kind of the SEO aspect there.


I don't think, for example, that we have any classifier that


tries to figure out, is this written in British English


or not?


But rather, we try to understand the English content the way


that we find it and kind of figure out how


we should show that relevantly.


And the kind of exact phrasing and spelling


that you use on your site is more a matter


of you presenting your content in a way


that your users want to accept that and kind of want


to be able to work with that.


So from that point of view, totally up to you.


Thank you.


Cool.


Andres.


Hi, John.


I just wanted to ask about how you feel offline branding


impacts SEO organic rankings.


To put a bit of context, we're working


on a highly competitive transactional market.


And we are, let's say, getting close to being in the H1


and stuff like this.


But we are clearly at a disadvantage


in terms of brand awareness.


There are some very large brands in our market.


And I wanted to know a little bit


into how you feel that especially offline brand advertising


can affect that.


I don't think it affects SEO directly.


But it is something where if people search for your brand


because they recognize your brand, then essentially you


have no competition, right?


Because your site is by far going


to be the most relevant one.


If people are searching for your company


and you are that company, then it's


almost like a navigational query, what we call it,


where people want to go to a specific page.


And they're just entering something into Google


to get to that page.


So that's something where I kind of think building up


some kind of brand awareness amongst your users


and having a brand that is easily findable, that


can help in the long run.


And that all of this kind of branded traffic


that you get, that's traffic that's not


going to fluctuate as our algorithms change.


Because if people are searching for your site,


they will always want to find your site.


And if our algorithm shows something else,


then it's almost like a problem in our algorithms.


Whereas if people are searching for the generic kind of product


that you have, whether we show your site or another one,


the search quality engineers on our side,


they can argue about that.


And there is no correct answer for that.


But if you kind of build up that brand awareness


and have a certain level of branded traffic to your site,


then at least that traffic is something


that will be fairly stable.


And I wouldn't see this as something


where if you have branded traffic, then suddenly you're


ranked better for non-branded traffic, but more like, well,


the different sources of traffic.


OK, and how do you think that Google deals with non-branded


traffic, where there are brands that are basically expected


by the user to be on top?


I mean, from our position, if I understand it from a pure


theoretical perspective, if the top five positions are kind


of expected there to be some brands,


how can we get into those places?


Because I guess we will always be at least


in a disadvantage in the propensity


to click on our search results.


Do you think that plays any role at all?


I don't think so.


I don't think it's the case that for most kind of queries


that we would have any system in place that would say,


for this non-branded query, we should always


show these other brands.


I can think of one situation where I've


seen something similar happen.


But that's something where essentially we or our systems


recognize the brand as almost being


a synonym for the non-branded term, which is something that,


from our point of view, I would call that a bug on our side.


But it is sometimes something where people just


purely associated a specific brand


with a specific kind of item.


And that's something where it's less a matter of, well, you


have to do some SEO tricks to get around that.


But you really have to build up the awareness that, actually,


there are multiple brands that are active in this space.


And people should be searching for other stuff as well.


OK.


I don't know if that made a lot of sense.


But no.


I think for the most part, I wouldn't see it as a given


that we always show brands for non-branded queries.


And it's definitely not the case that these


would be kind of like a fixed set of brands


that we would always show.


OK, no, but I think just in general,


the algorithms are kind of trying


to give the best result for user query.


And it happens to be that the users want


to see those brands that, in the long term,


it self-teaches that some of those brands


need to be on the top positions.


Yeah, I don't think our algorithms would learn it


in the sense that we always need to show


those brands for those queries.


I think that would be an extreme exception that we would maybe


pick one or something like that to see as a synonym.


But it is something where, over time,


if it's a very competitive area, then these sites


have built up kind of a really strong and stable foundation.


And kind of breaking into that, that is hard.


And that is something for smaller or newer sites


where you almost have to think about, well,


is it worthwhile to take on these brands for these queries,


or should we find something smaller


where we can be kind of the king of our niche first


and kind of grow from there?


And kind of picking that is almost more of a business


decision than a CEO decision, I think.


OK, cool.


Thanks a lot.


Sure.


Rupesh.


Hi.


Hi, John.


My question is regarding the updated ago date


in the sub snippets.


We showed that seven days ago or two days ago.


So how does Google assume that it is updated two days ago?


We submitted through the meta tag article modified


and through the schema also.


But still, if you have updated the page yesterday,


it is still showing it is updated two days ago.


Whereas in the case of competitors,


it is showing that updated yesterday only.


So my question is, how does Google determine


when the page is updated?


We use multiple factors to try to figure out which


dates are relevant for a page.


So it's not just the metadata on the page.


But we try to figure out, has there actually


been a significant change on the page?


And we have a Help Center article, I think,


on this topic.


So I would check that out.


One thing that you should also keep in mind


is that it should also be something visible on the page.


So if you just change the date on a page,


then that's something where we need to really recognize


that you've made significant changes there so that we


can show that to users and say, well, actually,


something significant happened on this page two days ago


or one day ago or whatever.


And all of that needs to come together.


And it's very possible that for some pages,


we don't pick that up.


So that's something where I would not


say that it's a given that even if you do everything right,


we will use the date that you give us.


Sometimes there are situations where our algorithms just


pick something else regardless.


Regarding the visible dates, if there


are multiple dates in the page, like our main article,


we have updated it.


But there are a listing of other news articles below the article,


like we show related news.


In that also, we have the date.


So by any chance, Google can pick that date also.


It can happen.


But usually, because we try to take so many factors


into account, we try to find a date that has support


across multiple factors.


So if it's just a random date on a page,


then probably we will ignore that,


unless the actual date is also positioned


as a random date on the page.


If you can't present it in a way that is clear to us


that this is really the date that you want to use,


then we might have to guess.


And that's something where the metadata comes


into play a little bit.


Also, where things like time zones sometimes


play a role, where if you say, well, it changed today


on this date, but you're in a time zone that


is very far off from where Google is crawling, perhaps,


then Google might say, well, you said this date,


but we think it's a date later.


And that's more because of the different time zones involved.


So for the metadata on the page, also


make sure that the time zones are correct.


If you have dates and times on a page as well,


mentioning a time zone there in the text is also a good idea.


Thank you.


Sure.


Faisal.


Hi, John.


Hi.


Thanks in advance.


This is going to be a multi-parter.


We have a domain verified through DNS verification,


and it contains several subdomains.


We also have the individual subdomains


verified through URL prefixes.


And when we are comparing the data that we first


input between those two different property setups


for one specific domain, we're getting quite a big delta


in the impressions input, somewhere between 40% to 80%.


So we're wondering if maybe there


are any suggestions or theories on why that might be the case.


This isn't true of all setups like that.


We have some domains that don't show that discrepancy.


It's what particular one does.


Yeah, sometimes that's pretty tricky.


It's hard to say offhand exactly what is happening there.


What usually plays a role is, on the one hand,


we have queries that we filter out,


which might be more visible in some domains


or less visible in others.


And on the other hand, we have a limited amount of data


that we keep per day, essentially,


for each of these properties.


So if you have a domain-level property


and it has a lot of different kinds of data for every day,


then it's very possible that we will trim that and keep


the top set.


And usually what you would see is that the overall sum is


still correct.


But if you look at the tables, then you


might see differences there.


So my guess is one of those things is happening there.


What I would do in a case like this, where


you see these kind of differences,


is use the more specific property


and use those metrics instead.


SPEAKER 2 OK.


Yeah, we sort of went through the documentation


for the performance reports.


And it mentions that some long-tail data loss


might occur if you are looking at the grouping


by query or page.


You mentioned some of the queries might filter out.


I understand some of them are anonymized for privacy


and for several reasons.


Could you sort of give a definition


of what long-tail data means, though?


Is that the same as the anonymized queries?


Or are we just reaching a hard limit


on how much data we can store?


It's hard to say offhand without looking at the site.


But usually, with regards to long-tail data,


if you're looking at a really large site or a site that


has a lot of different kinds of data for every day,


then it's more a limit of the number of specific data points


that we have per day.


So if you have a lot of different search impression


types or if you have a lot of different queries that


lead to a lot of unique pages, then kind of all of that


multiplied essentially means that we have a lot of data


entries per day.


And we have to cap those kind of for performance and stability


reasons.


So that's probably what you're seeing there.


And we call that more long-tail data


because it tends to be data that has either low impressions


or low clicks.


And hence, we try to focus on the more important data


for the site.


OK.


When you say data entries, is the best way


to consider the large site just the total volume


of impressions, total URLs that you have, clicks?


Is there a specific metric that correlates really well


with large or is it just a large?


Not really.


Because of the way that the data is collected,


if there are a lot of unique URLs


or a lot of unique queries that lead to the site, then


all of that kind of multiplies out.


Or if you have a lot of unique kind of search features


that are being triggered, then all of that


also plays a role in that.


So in the documentation, it says that the long-tail data


loss affects the table.


It mentions that whole focus is in the pages.


Can we get around that through filtering


for specific directories or queries?


Will that pull more data in?


Or could we use something like the API to pull that data?


Would that be better?


I would definitely try it with the API.


I mean, especially with the larger site, then with the API,


it's easier to get the full set of data


and then to kind of just put together


either some dashboard on your side


to pull out the details that you want.


But I would also, especially when


you're looking at multiple properties


within a really large domain, I would


try to kind of focus on the data for the individual properties.


So instead of going to the highest level view,


kind of the domain level, then actually go down


to the subdomain or whatever you have there and look


at the data there.


Because for each individual properties,


we tend to track the data a little bit more accurately.


OK.


And I guess last question here.


A subdomain, if it had some canonicalization issues,


would that affect how the data is aggregated between the two?


Or would that not affect that?


Yeah, it could as well.


So we try to use the canonicals for individual URLs.


And we map that to the properties then.


So if you have something like www and non-www,


and it's kind of fluctuating between those different


versions, then on a domain level,


that would also be in the same domain.


But on a kind of a lower level subdomain level,


that would be different subdomains.


So that would be tracked individually.


Sorry, could you elaborate on that last point?


What do you mean by tracked individually?


So if a page on your site is essentially


fluctuating between www and non-www,


then if you have those two verified separately


in Search Console, then you will see the data sometimes


in one property and sometimes in the other property.


Because of the way the canonical changes.


Usually, on a larger site, the canonicals


don't change that much.


So it's less something that you would see.


But it can happen, especially if it's


an older site that was maybe not created in the cleanest way


possible in that the internal links are sometimes


with HTTP, sometimes with HTTPS, and sometimes with www or not.


Then sometimes it happens that we kind of move URLs around.


But it's fairly rare for modern sites, I'd say.


OK.


And just last question here.


We've talked about large sites quite a bit.


Is there some sort of a threshold or some point


where we can say 100 million impressions or something


like that?


Not really.


So like I mentioned, it's more a matter of the unique entries


that you'd have.


And it can be the case that a site gets


a lot of impressions, a lot of clicks,


but it's all focused on a smaller set of URLs.


Or it's focused on something like, I don't know,


the top 10,000 or top 100,000 URLs.


And in cases like that, then despite it


having a ton of impressions, it doesn't


mean that it has a ton of unique data entries per day.


So that makes it a bit tricky to kind of find a threshold where


we'd say, well, this is from where


you'd need to start looking.


And that's kind of why we frame it


as the long tail data in the Help Center


because there is no kind of absolute number where


we can kind of apply that.


Thank you.


Sure.


It looks like a bunch of you still have your hands raised,


but I need to go through some of the submitted questions as


well.


We'll definitely have more time for live questions


as well along the way.


But just to make sure that people who submitted questions


don't get their questions lost completely.


Let's see.


I read online that people said that they've seen an uplift


after the June core update.


They've also seen one for July as well.


For us, it wasn't the same.


What could have reverted in July?


Could it be related to speed?


As far as I know, these were essentially


separate and unique updates that we did.


So we call them both core updates


because they affect the core of our ranking systems.


But that doesn't mean that they affect the same core


parts of the ranking system.


So from that point of view, it's not the case


that if you see a change during one of these core updates,


you will always see a change during the other one as well.


So from there, I wouldn't assume that they have to be related.


With regards, could it be related to speed?


Things can definitely be related to speed


because the whole page experience


update is something that I think started rolling out in June.


So in July, you might still see some changes there.


But the core update itself isn't something


that I think is related to the page experience update.


That's kind of a separate thing.


Does Google look at the amount of customers,


and or reviews a website has to rank it higher in the search


results?


Why are some pages getting indexed


after more than two weeks?


Is it because the crawlers don't deem


these pages strong enough to index them faster


than two weeks?


So as far as I know, we don't use the number of customers


or reviews when it comes to web search with regards to ranking.


Sometimes we do pull that information out,


and we might show it as kind of a rich result on the search


results.


It might be that for the Google My Business side of things,


maybe that's taken into account more.


I don't have much insight there.


But with regards to normal web search,


we don't take that into account.


With regards to getting indexed after more than two weeks,


it is really hard to say.


Usually, that's a mix of either technical issues


that we can't crawl all of the content that quickly


and quality issues that our systems are not.


That interested in crawling the content so quickly.


And kind of figuring out where in between there your site sits


is sometimes a bit tricky, but sometimes it's


also easier to figure out, especially


if you can determine that from a technical point of view,


your site is actually pretty fast.


So that's something where sometimes it


makes sense to take a step back and think about the quality


more than just the technical aspects.


What are some things that a webmaster


can do to trigger site-wide re-evaluation from a quality


point of view, like when you change domains


or when does Google say, OK, let's try to collect new signals


and see whether the site is better from a quality


point of view?


I don't think there is anything technical that you can do


to trigger a re-evaluation.


And usually, that's also not necessary,


because essentially, our systems re-evaluate all the time.


And they look at the content that we found for a site.


And over time, as we see that change,


we will take that into account.


So that's not something where you kind of


have to do something manually to trigger that.


The one time where we do have to kind of reconsider


how the site works is if a site does a serious restructuring


of its website, where it changes a lot of the URLs


and all of the internal links change,


where maybe you move from one CMS to another CMS


and everything changes and looks different,


then from a quality point of view


or from a technical point of view,


we can't just keep the old understanding of the site


and of the pages, because everything is different now.


So we kind of have to rethink all of that.


But that's also not something that is triggered


by anything specific.


But rather, it's just, well, lots of things


have changed on this site.


And even to kind of incrementally keep up,


we have to do a lot of incremental changes


to re-evaluate that.


Our website's posts are being indexed after one week.


The site is old and mobile-friendly.


When I submit URLs and inspection tools,


it shows it's crawled by Google smartphone.


But in the About section, the indexing crawler


is shown as Googlebot desktop.


Does this mean the smartphone bot


is crawling the URL and the desktop bot is indexing this URL?


Is this the reason behind the indexing delay?


This would not be a reason for any kind of indexing issues.


I don't know offhand why you might


see this kind of mix of desktop and mobile crawlers there.


It might just be that Search Console is essentially saying,


well, by default, with the inspection tool,


we'll just use the mobile Googlebot.


In practice, we always crawl with both of these crawlers.


It's just a matter of how much we crawl and index


with any of these crawlers.


So usually, you'll see something like 80%


is coming from mobile Googlebot and 20% maybe


from desktop Googlebot.


And that kind of ratio is essentially normal


and doesn't mean that things are slower than anything else.


Is there any consistent reports on AMP tanking a website's


performance?


How consistent is the page experience report


in regards to its interpretation of AMP pages?


I'm not aware of anything where using AMP


would cause problems with a website's performance.


But it sounds like you're looking


at something very specific.


So my recommendation there would be to go to the Help Forum


and try to post the details of what exactly you're


seeing there and try to get some input on that.


But for the most part, using AMP on a website


is a great way to get kind of that speed boost


without doing a significant amount of work.


So I wouldn't see that as something


that would be causing problems with a website


unless the AMP integration is somehow broken in a weird way.


Then I think the verification one, we talked about that.


I've been using Search Console for my employer's website


and was wondering what's the best way to track


the value of a blog's value on an e-commerce site.


It's drawing majority of the web traffic,


with most of those being first-time visitors.


However, blog visitors notoriously


don't always buy on initial visit to a website


but do return later and are truly the first step


in the conversion path.


Employers want to see concrete data.


I don't know.


So to me, this sounds like something


that would be best looked at with regards to analytics.


And there are different approaches


that you can take with analytics.


I think the overall topic area is attribution modeling,


where you try to attribute individual steps that


are being taken on your website to maybe figure out


where is this coming from or what parts of a website


are contributing to a conversion, to a sale,


those kind of things.


But that's something where I think Search Console can't


really help that much.


And from a search point of view, we


don't have that much insight into what


happens within your website and who comes and goes


within your website in search.


So you'd almost need to look at that maybe with an analytics


expert, maybe with the Analytics Help Forum,


and try to get some input there.


But that usually is something that people can figure out.


So how many affiliate-sponsored links are safe or good to have


on a single page?


Is there a perfect ratio of links to article length


to maintain here?


There is no limit.


So that's something from our side.


It's not that we're saying that affiliate links are


bad or problematic.


It's more a matter of, well, you actually


need to have some useful content on your page as well.


So that's kind of the angle that we take there.


The amount of affiliate links that you have on a site


is totally irrelevant.


The ratio of links to article length


is also totally irrelevant.


But essentially, what we need to find


is a reason to show your site in search for users


who are looking for something.


And that reason is usually not the affiliate link,


but the actual content that you provide on those pages.


So from that point of view, trying


to optimize the affiliate links or trying


to hide the affiliate links or whatever you're


trying to do there, I think is almost like wasted effort,


because that's not what we care about.


We care about the content and kind


of why we would show your pages in the first place.


And if the content of your page is essentially


just a copy of a description from a bigger retailer site,


then there's no reason for us to show your site,


even if you had no affiliate links.


So you really need to kind of first have that reason


to be visible in the search results


and then how you monetize your site


or what links you place there.


That's essentially irrelevant.


The ccTLD, I think we talked about there's


a site that ranks in top positions


for multiple high search volumes, city plus service,


without providing unique content.


They just duplicate their pages and score high,


even when there are other websites that seem


to provide better content.


They don't have any high quality backlinks or internal links


on these city pages.


Is there any reason they score high on Google?


I don't know.


It's hard to say just based off of your description there.


It's also something where we take


into account a lot of different signals


when it comes to search.


And it can be the case that a site does some things really


terribly and does other things really well.


And in the search results, we might still


show that site fairly visibly.


So that's something where just because one site does


one thing bad doesn't mean we will never show it in search.


And usually, this is something where a lot of sites profit


from because nobody really knows exactly what they


should be doing perfectly.


And it's something where everyone


gets input on what they should be doing from various people.


And sometimes you listen to the wrong people


and you do something stupid along the way.


And just because you do some things incorrectly


or suboptimally shouldn't mean from our side


that we shouldn't show your site at all.


So this is something that we see all the time, especially


with smaller businesses, in that they listen to something


or some blog online that says, oh, you


need to put your keywords in hidden text on your pages,


and search engines will fall for that.


And they go off and do that.


And essentially, that's against our webmaster guidelines.


So theoretically, we could go in there


and say, oh, you did this one thing wrong.


We're going to remove your site from search.


But it's a lot better for us to go in and say,


well, we recognize you did this thing, and we can ignore it.


And we'll focus on the rest of your site instead.


And if the rest of your site is OK,


then there's no reason for us not to show it.


So it's not the case that you have


to get everything perfect in order to be visible in search.


But rather, it's like lots of things can add up.


And you can do some things really well,


and we'll still show you in search.


Even if you do other things, kind of suboptimal.


So I think that's always tricky when


you look at other people's sites and kind of say,


well, they're using hidden text.


They're using this other technique that


is against our guidelines.


Therefore, they shouldn't be visible ranking above me,


because that's almost like way too simplistic.


We had a speculative question regarding


the recent confirmation of deleting redirects after a year


where you quote, this time frame allows Google


to transfer all signals to new URLs,


including recrawling and reassigning


of links on other sites that point to your old URLs.


We understood this to mean that all offsite authority is passed


after a year, even once deleted.


What would happen if the old page that was redirected


previously 200s again?


Like essentially, would a term come back?


Would both pages benefit from an offsite link?


No.


So essentially, what happens with regards to redirects


is we will forward those signals as best that we can.


And what happens with regards to external links going


to those pages, we'll forward those external links as well.


And if that redirect is gone at some point,


then essentially, we will have two pages,


and they will rank individually.


So it's not the case that you can just redirect,


and suddenly you have two times as much value on your website.


But rather, it's like, well, we take whatever


value goes into the website.


We follow the redirect, and we point it at the final URLs


there.


And if you remove redirects, then that kind of chain


is broken there, and it remains somewhere else.


So just kind of like taking a site, adding a redirect,


and then after a year dropping those redirects


and hoping that suddenly you have two times as


much value on your site, that's not how it works.


So from that point of view, I don't


think you would see any value in doing that.


The main reason for this is less to kind of prevent abuse


around this, but rather, people change their minds all


the time.


And it can happen that you move a URL from one location


to another, and then some point later on you say, well,


actually, I want to have the other URL indexed as well,


or I want to kind of revert that chain


and go back to the previous URL.


And we need to be able to kind of go back and understand


a site again, even after it had redirects for a while.


OK, looks like we're coming kind of close to time,


so maybe I'll switch back to live questions from you all.


I also have a bit more time afterwards if any of you


want to ask even more questions so we can


go through some of that too.


Let me just one quick question here that I also see all here,


a site that I looked into briefly with regards


to a coupon site that is mentioned there,


with regards to kind of indexing and being shown in search.


One of the things I noticed there


was that this is like a really low quality site.


So I don't know, the person who asked this question,


I would recommend definitely not focusing on technical things,


but really focusing on the quality overall first


and making sure that the quality of the site itself


is actually a lot better before you worry about things


like how quickly Google is crawling and indexing pages.


OK, let's see.


I think Mano, I think you're next up.


Hi, John.


I got a couple of questions.


Let's take this time with the first one.


So basically, search control actually


reported some static files as affecting the performance,


and actually we minified those files


and also added the setup rule on the robots.txt.


I'm not sure if that's the correct thing to do.


So once we've done that, actually what happened


was the mobile usability was affected,


and then it was flagged saying that it affects mobile


usability.


So I just wanted to know what is the best practice


and how we should go about doing that.


What kind of files were they?


So like CSS?


JavaScript files, yes.


OK.


Yeah, so I think with the robots.txt,


this allow essentially you're preventing us


from looking at those files.


And if those files are necessary for the rendering


of a mobile page, then we won't be


able to render those mobile pages to recognize


that it's mobile friendly.


So that's probably why you're seeing


that shift with regards to kind of mobile friendliness


in the report there.


Right.


And so should we actually even add the disallow rule for those,


or should we just keep them open?


No, I think for the most part, we


recommend making JavaScript CSS files crawlable so


that we can render the pages.


We won't index them individually.


So it's not that we'll say, oh, this JavaScript file is suddenly


a text file.


We should show it in search because that


doesn't make sense.


But we need to be able to access them


so that we can render the pages and see what they look like.


The next question is about using disallow on robots.txt


versus using noindex.


What's the difference, and what are the different use cases?


We don't support noindex in robots.txt.


So that's kind of like the main difference there.


So essentially, if you're talking about the noindex


robots meta tag on a page versus robots.txt,


the robots.txt file prevents us from crawling a URL.


But it doesn't prevent us from indexing the URL alone, which


is kind of a weird situation.


But essentially, there are pages that are blocked by robots.txt,


but they're still useful for users.


And we don't know what is on the page,


but we might be able to recognize they're actually


still useful for users.


So it can happen that we index a page just purely by the URL.


And based on the anchor text of links pointing to that URL,


we can still show that in search.


And we essentially don't know what is on the page.


But we see that lots of people are recommending it


for this one particular topic.


So we might go along with that.


With regards to the robots meta tag noindex,


if we can crawl the page and we see that noindex meta tag,


then we won't index that page.


Then it won't be shown in search.


So in practice, for most normal pages on a website,


if it's blocked by robots.txt, then we


won't show it for normal searches


because we usually have more relevant content


from your website to show.


If you search specifically for that page,


then we will still show it.


If you do a site query, then we might still say,


well, actually, for this particular URL


you're looking for, we have this page.


So those are the differences there.


SPEAKER 2


Yeah, exactly.


That's where we essentially index the page without knowing


what the content is.


And it's not necessarily a bad thing.


It's just kind of like for your information,


if you wanted to have the page indexed and ranked


based on its content, then with that set up there,


that wouldn't be possible.


SPEAKER 3


And if you want to change a link on the website that


is basically to rename the URL, how can you


do that without affecting the search console ratings


celebrated with cluster?


Essentially, you would just set up the redirects there.


So you would redirect from the old URL to the new one.


And that's something that our systems follow.


And that should, for the most part, just be fine.


Sure.


Thanks, John.


SPEAKER 2


All right, Michael.


SPEAKER 4


Good.


OK, sorry.


I have a quick question about images,


which seemed to have been a little bit of a hot topic


this week.


OK.


So if a site uploaded a number of images over the years


without being aware of the importance of file sizes,


and it slowed up the site, and then someone like myself


pointed out to them this issue, could they


go back and optimize the same image uploaded again


as a smaller file and use the same original alt attribute,


or do they have to change the alt title?


They can just change it.


So it's something where, essentially, when we, I mean,


what happens in practice is with images,


we tend not to recrawl them that often.


So it might be a while for us to actually recognize


that the image file has changed, even if it's just


a matter of like recompressing or kind of tweaking


the settings.


That might take a while.


And we would tend to pick that up


based on the crawling of the web page.


So kind of the landing page, if we recrawl that often,


then we'll see, oh, this image is still embedded here.


And every now and then, we'll double


check the image file to see how that is set up.


And if the image file changes, then image file changes.


And we can kind of reprocess that.


If the alt text changes on the page,


we can also include that a little bit faster


because the HTML pages tend to be recrawled more often.


If you need to have an image changed quicker in search,


maybe there's something in the image that you don't want


to have shown in the search results,


then I would recommend using a different URL for that image


so that when we crawl the HTML page,


we clearly see, oh, this old image is no longer on this page


but there's a new image here.


We should check out this new image URL.


And this is basically to just make it faster, sites faster.


And with regards to speed, it's not


something where we need to have the optimized image indexed.


But that's something where, essentially, for the Core Web


Vitals, we use the real user metrics.


So we see what people are actually seeing on the page.


And that's independent of what we have indexed for that page.


SPEAKER 1, Great.


Thank you.


Sure, Carmen.


SPEAKER 2, Hello.


Hello, everyone.


Hello, John.


Good morning.


Hi.


So practically, I'm working on the website structure.


It is a company in the finance sector, specifically mortgage.


And two questions.


So building the new structure, I have two options.


One is build the hierarchy using pages.


It says CMS in WordPress.


So I can do that.


I have different levels for my main products


and have a kind of categorization by using pages.


Then I have option B, which could


be rebuild our CMS in WordPress and have


a built-in categorization.


That is my choice.


And however, yes, I have these two options at the moment.


So the two questions are, what will be the main impact


by using pages over categorization


and build a new category on the CMS?


And the second question is, if I rebuild the CMS,


what will be the main benefit following


the EHE best practice of Google?


OK.


So I think, first of all, I would not


worry about the pages versus posts and categories.


Question from our point of view, we see all of these


as HTML pages.


And how they're classified within your server


and within your CMS is essentially totally up to you.


It's not something that our algorithms would care about.


So from that point of view, I would


choose whichever setup is easier for you to maintain,


is easier for you to make sure it's fast and usable,


all of the almost like the non-SEO factors,


and focus it based on that.


And that's something where sometimes using WordPress


makes sense.


Sometimes using another CMS makes sense.


Sometimes a mix makes sense.


But that's essentially purely on your side


with regards to how you can maintain the content, how


you can make sure it's fast, it's secure,


all of those things.


The one place where I think I would keep an eye out on


is if you're migrating from one setup to a different setup,


then that's something where you essentially


have to think about all of the usual site migration things.


So making sure that you know which the old URLs are


and the new ones, making sure you have all the redirects


in place, fixing the internal linking, all of that


plays into that as well, as well as everything


that is on the page as well, especially


if you're moving from one CMS to another,


you will have things like headings are suddenly different,


or the images are embedded in different ways,


and suddenly you have, I don't know,


maybe captions below the image instead of just an alt text


for the image.


And all of those are essentially on-page SEO things


that you can do well or that you might do kind of badly.


And then it's less a matter of which CMS is better,


but rather which setup is the optimal one for you


and how are you migrating between those setups.


Thank you.


YouTube comments, and yeah, we couldn't really


find a reason why this specific page isn't indexed anymore.


I also checked troubleshooting reports on supportgoogle.com,


and I just couldn't find a reason


why this one page isn't in the index anymore.


So maybe afterwards you and your team


could have a look into, take a look into this


and maybe you can just post the URL in the chat here.


Then I can pick that up.


I can't guarantee that we'll be able to look into it


or that we'll be able to do something there,


but I'm happy to try to see what we can find there.


OK, I also posted this in the Unity form,


so I'll just post the link of that in the chat.


OK, cool.


Thank you very much.


Sure.


OK, let me take a break here with regards to the recording.


It has been great having all of your questions


here, and I hope if you're watching this on YouTube,


you find this recording useful, and maybe we'll


see you in one of the future Hangouts as well.


The early days of Google Search Central

Hello, and welcome to another episode of Search Off the Record, a podcast coming to you from


The early days of Google Search Central

the Google Search team, discussing all things search and, who knows, maybe having some fun


The early days of Google Search Central

along the way.


The early days of Google Search Central

My name is John Mueller, a part of the Google Search Relations team.


The early days of Google Search Central

I'm joined today by Lizzie Sossman, also from the Search Relations team.


The early days of Google Search Central

Hi Lizzie, what's new?


The early days of Google Search Central

Hey John.


The early days of Google Search Central

Well, there are so many things new.


The early days of Google Search Central

I feel like this week's current obsession is probably the fact that I have now gotten


The early days of Google Search Central

myself three carnivorous plants.


The early days of Google Search Central

I had one and now I have two more.


The early days of Google Search Central

So I don't know if that qualifies as like an obsession, but probably if you have more


The early days of Google Search Central

than one and you're wanting to speak about it, it's an obsession.


The early days of Google Search Central

Yeah, I think I'm trying to figure out how to keep them alive and then also motivated


The early days of Google Search Central

to kill.


The early days of Google Search Central

So if you're a vegetarian, can you eat a carnivorous plant?


The early days of Google Search Central

I don't know if that would taste it.


The early days of Google Search Central

Are they poisonous?


The early days of Google Search Central

I think that they have some poison in there, but maybe it's just for the bugs.


The early days of Google Search Central

I don't know.


The early days of Google Search Central

This is a good question that I feel I should know the answer of as like an owner of killer


The early days of Google Search Central

plants.


The early days of Google Search Central

So some of them, I have like the basic one, the Venus fly trap one.


The early days of Google Search Central

Vanessa, do you have carnivorous plants?


The early days of Google Search Central

I have tried several different carnivorous plants and I have not been able to keep any


The early days of Google Search Central

of them alive even though I like tried to give them little buggies.


The early days of Google Search Central

My plan was I had like a little arrow garden that attracted bugs.


The early days of Google Search Central

So I put the carnivorous plants all around the arrow garden to try to like be pest control


The early days of Google Search Central

for my garden and I could not keep them alive.


The early days of Google Search Central

So I'm the worst person to ask.


The early days of Google Search Central

I do find the question interesting.


The early days of Google Search Central

I'm a vegan and so it's interesting that I had carnivorous plants.


The early days of Google Search Central

So it was like encouraging these eating of other species on our planet.


The early days of Google Search Central

So I'm going to have to really think about that one now.


The early days of Google Search Central

I've never had that ethical.


The early days of Google Search Central

What am I doing here?


The early days of Google Search Central

Am I helping or hurting nature?


The early days of Google Search Central

This is not a plant podcast.


The early days of Google Search Central

I don't think.


The early days of Google Search Central

I think it has it could be.


The early days of Google Search Central

I mean, we've talked about it being a cooking podcast and this is sort of related because


The early days of Google Search Central

I got I got the carnivorous plants to be pest control in the kitchen for the fruit fly situation


The early days of Google Search Central

that sometimes happens in your bananas.


The early days of Google Search Central

But it seems brilliant.


The early days of Google Search Central

It seems brilliant.


The early days of Google Search Central

But I think the fruit flies are too small for the Venus fly trap, which I think they


The early days of Google Search Central

need like a larger bug to trigger the, you know, closing of the mouth.


The early days of Google Search Central

You got to go hunt him outside and bring him back.


The early days of Google Search Central

Yeah.


The early days of Google Search Central

And the plant guy at the plant store, he said that they should actually live outside and


The early days of Google Search Central

not inside in Zurich.


The early days of Google Search Central

Like they can live in the winter too, apparently, and that they would be happy out there and


The early days of Google Search Central

that they prefer rainwater because the water here is too nutritious for them and they won't


The early days of Google Search Central

be motivated to kill because then they are getting fed from like the water that you're


The early days of Google Search Central

watering them with.


The early days of Google Search Central

So you also have to go start capturing rainwater outside.


The early days of Google Search Central

This is going to become a full time job for you.


The early days of Google Search Central

Yeah, I know where I am now like servicing these plants that are supposed to be working


The early days of Google Search Central

for me.


The early days of Google Search Central

Like who's in charge here?


The early days of Google Search Central

Speaking of who is in charge, I thought maybe I would jump back a little bit.


The early days of Google Search Central

So as you notice, Vanessa is here.


The early days of Google Search Central

This is Vanessa Fox.


The early days of Google Search Central

Hello.


The early days of Google Search Central

And this is in the spotlight series from the podcast where we kind of invite folks from


The early days of Google Search Central

the larger search marketing community kind of to come over and join us here.


The early days of Google Search Central

I was mostly curious, like right about when I joined Google, you were also at Google,


The early days of Google Search Central

but then you left.


The early days of Google Search Central

Was it because of me?


The early days of Google Search Central

You know, John, I haven't wanted to tell you this.


The early days of Google Search Central

I've been keeping this myself all this time, but I just had to get out of there.


The early days of Google Search Central

That's not true at all.


The early days of Google Search Central

So yeah, it is interesting.


The early days of Google Search Central

You and I crossed paths briefly.


The early days of Google Search Central

And at that point, I had been building up Webmaster Central, I guess you want to call


The early days of Google Search Central

it kind of all the different components of that.


The early days of Google Search Central

And the things had really evolved.


The early days of Google Search Central

And then you came in as part of that wonderful evolution.


The early days of Google Search Central

And yeah, that just happened to be, you know, I kind of like, okay, everything's set.


The early days of Google Search Central

You know, I can move on to other stuff.


The early days of Google Search Central

And actually, my thought at that time was to kind of get out of SEO and go do something


The early days of Google Search Central

else because my thought was, okay, I've done this now.


The early days of Google Search Central

Let me do something else.


The early days of Google Search Central

And obviously, that did not work out all that because here I am still quite loving every


The early days of Google Search Central

minute of it.


The early days of Google Search Central

So.


The early days of Google Search Central

Cool.


The early days of Google Search Central

So how did you get started in all of this?


The early days of Google Search Central

Was it like Larry and Sergey came up to you and was like, you should make a tool for webmasters


The early days of Google Search Central

and call it Webmaster Tools?


The early days of Google Search Central

Oh, my goodness.


The early days of Google Search Central

Yeah, it's so interesting because it was really sort of the opposite of that.


The early days of Google Search Central

In fact, Larry and Sergey did not know about it.


The early days of Google Search Central

And I don't know that they...


The early days of Google Search Central

Do they still not know about it?


The early days of Google Search Central

They were quite surprised, I think, when they...


The early days of Google Search Central

You know, it's an interesting time.


The early days of Google Search Central

So when I joined Google, which was way back in early 2005, it was really a different time,


The early days of Google Search Central

right?


The early days of Google Search Central

And I joined the Kirkland office, which was the Seattle office basically at the time.


The early days of Google Search Central

And there were 25 people there.


The early days of Google Search Central

So very small office.


The early days of Google Search Central

And my background before joining Google was pretty eclectic.


The early days of Google Search Central

I was technical writing, that was how my career started.


The early days of Google Search Central

And then from there, got really involved in product management, UX.


The early days of Google Search Central

And I spent a lot of that time with an engineering audience.


The early days of Google Search Central

So really a developer audience doing APIs and that type of thing.


The early days of Google Search Central

But also did a bit of marketing.


The early days of Google Search Central

And so I built a website for the company I worked for in 95.


The early days of Google Search Central

It was cutting edge.


The early days of Google Search Central

I was like, we need to have a website.


The early days of Google Search Central

I was like the marketing person at the company.


The early days of Google Search Central

So I kind of had this eclectic background that ended up coincidentally working out really


The early days of Google Search Central

well for what happened when I went to Google.


The early days of Google Search Central

So yeah, so when I got there, like I say, 25 people, I think there were 2,200 people


The early days of Google Search Central

or something at the company in total.


The early days of Google Search Central

So dynamic at the time was just really free for all, right?


The early days of Google Search Central

And so the director of engineering at that Kirkland office was really looking to start


The early days of Google Search Central

a project that was just from that office.


The early days of Google Search Central

And the way it worked, I got hired and I didn't have a manager.


The early days of Google Search Central

It was just like, find a project.


The early days of Google Search Central

And I was like, okay.


The early days of Google Search Central

So I would go down to Mountain View and I would work on these projects.


The early days of Google Search Central

And it was very hard because I'm not in the Mountain View office and then only a month


The early days of Google Search Central

or two in, this head of the Kirkland office decided to do something called site maps.


The early days of Google Search Central

And it was this idea of like, okay, we'll do this XML file.


The early days of Google Search Central

That's all it was at the beginning.


The early days of Google Search Central

Let's do this XML file and site owners can give us a list of URLs to crawl and index


The early days of Google Search Central

on their site.


The early days of Google Search Central

And then that'll be, at that time you could imagine 2005, discovery was, I mean, it still


The early days of Google Search Central

can be hard, right?


The early days of Google Search Central

But a lot of sites didn't have any links to them or it was hard sometimes to find all


The early days of Google Search Central

the pages of the site.


The early days of Google Search Central

So I was like, oh, I could work on this project because it's local and it's within my area


The early days of Google Search Central

of expertise, right?


The early days of Google Search Central

Because it's a technical, I can write the docs for it.


The early days of Google Search Central

And so it really started with that, right?


The early days of Google Search Central

And then once I got involved in that, again, since my personality is very much just like


The early days of Google Search Central

what needs to happen and just sort of tackling that.


The early days of Google Search Central

And the culture of the company at that time was, hey, what do you think is interesting


The early days of Google Search Central

to work on?


The early days of Google Search Central

I really started to say like, well, who is this audience that we're building this for?


The early days of Google Search Central

And like, what's the audience inside of Google that we're building this for?


The early days of Google Search Central

And like, what do both sides need, right?


The early days of Google Search Central

And at that time, of course I knew nothing.


The early days of Google Search Central

And so I just started to investigate on my own, research the audiences and from there


The early days of Google Search Central

heard about this person named Matt Cutts.


The early days of Google Search Central

And I was like, oh, let me talk to this guy.


The early days of Google Search Central

He seems to like be involved in this audience and know what's going on.


The early days of Google Search Central

And interestingly, Matt in a way had the same experience where he was head of the spam team,


The early days of Google Search Central

right, on the engineering side.


The early days of Google Search Central

But he also has that kind of personality, like who is the audience?


The early days of Google Search Central

What do they need?


The early days of Google Search Central

And so from there, he already had like established, of course, this very robust relationship with


The early days of Google Search Central

site owners, SEOs, and then was like helping them really on his own time, right?


The early days of Google Search Central

He had a blog, he would post in forums.


The early days of Google Search Central

And so I started talking to him and like, that's really where it started is like, we


The early days of Google Search Central

just had this idea of like, who is the audience and what do they need?


The early days of Google Search Central

And so we just made it up.


The early days of Google Search Central

That sounds like the best way to kind of move forward for something like that.


The early days of Google Search Central

So John, you may recall, right, these early days when XML sitemaps first launched, like


The early days of Google Search Central

what was your recollection of that?


The early days of Google Search Central

Yeah, I think it was kind of like interesting timing from my side because that was right


The early days of Google Search Central

about the time.


The early days of Google Search Central

Like I was working at my own company and right about that time I started getting interested


The early days of Google Search Central

more in websites and kind of wondering why my website wasn't really showing up in search.


The early days of Google Search Central

And then the whole sitemap stuff was launched.


The early days of Google Search Central

And I thought like, I could just write a Windows tool to do this.


The early days of Google Search Central

And it basically just went downhill or uphill from there, I guess.


The early days of Google Search Central

I don't know, like one of the directions.


The early days of Google Search Central

So was it sitemaps.org first and then the tool or what was the series of launches?


The early days of Google Search Central

Like there's a lot of things called sitemaps, like everything, like the branding was like


The early days of Google Search Central

sitemaps.


The early days of Google Search Central

We are sitemaps.


The early days of Google Search Central

Oh gosh.


The early days of Google Search Central

Oh no.


The early days of Google Search Central

Yes, sitemaps.org.


The early days of Google Search Central

So let me tell you about that.


The early days of Google Search Central

So first of all, yes, sitemaps was how it launched.


The early days of Google Search Central

And originally it was just the XML sitemap.