Structured data: What's it all about?

So if there's extra metadata like in JSON-LD


Structured data: What's it all about?

or in microdata in meta tags, I think you're alluding to,


Structured data: What's it all about?

then it will, we don't check


Structured data: What's it all about?

for that particular stuff usually.


Structured data: What's it all about?

But I mean, well, I just wanted to add the point


Structured data: What's it all about?

on this topic that JSON-LD,


Structured data: What's it all about?

one of the problems with JSON,


Structured data: What's it all about?

which is addressed in documentation as well,


Structured data: What's it all about?

is that we have to fetch a different resource.


Structured data: What's it all about?

So that can also provide a synchronicity problem.


Structured data: What's it all about?

And that's the reason why it's sometimes better


Structured data: What's it all about?

to go with approaches that are embedded on the website,


Structured data: What's it all about?

even the webpage itself,


Structured data: What's it all about?

even if that sort of makes it more difficult to separate,


Structured data: What's it all about?

just because there's a chance


Structured data: What's it all about?

that we're not downloading the JavaScript


Structured data: What's it all about?

at the same time that we're downloading the HTML.


Structured data: What's it all about?

So there's a chance for a synchronicity problem in that case.


Structured data: What's it all about?

How would I know that I had this kind of a problem?


Structured data: What's it all about?

Like if I was the website owner that like,


Structured data: What's it all about?

oh, Google is not fetching the JavaScript part


Structured data: What's it all about?

of the structured data on my page,


Structured data: What's it all about?

would I get a message from Search Console about this?


Structured data: What's it all about?

Or would this be like completely hidden from me?


Structured data: What's it all about?

Maybe this is a Martin question.


Structured data: What's it all about?

I think generally that would show up


Structured data: What's it all about?

in the Search Console, no, Ryan?


Structured data: What's it all about?

No, I think it would.


Structured data: What's it all about?

I think that our testing tools


Structured data: What's it all about?

will actually sort of show that.


Structured data: What's it all about?

Like the whole thing is missing,


Structured data: What's it all about?

not just like, oh, you didn't provide us this one property.


Structured data: What's it all about?

Like suddenly we are not able to find this entire block.


Structured data: What's it all about?

I mean, with the synchronicity,


Structured data: What's it all about?

the problem more likely is that you have


Structured data: What's it all about?

some sort of invalid and broken template


Structured data: What's it all about?

that hasn't been filled in yet.


Structured data: What's it all about?

And then we'd be like, hmm, this doesn't look right.


Structured data: What's it all about?

So it might be a little confusing actually.


Structured data: What's it all about?

To know that it means that it's a synchronicity problem.


Structured data: What's it all about?

We know that like, it's easy to see


Structured data: What's it all about?

that there is something wrong here,


Structured data: What's it all about?

but what is the culprit?


Structured data: What's it all about?

The next question that might be a little bit harder to debug.


Structured data: What's it all about?

Yeah, definitely.


Structured data: What's it all about?

Because you would have to look into the testing tools.


Structured data: What's it all about?

The testing tools might not, because this is a,


Structured data: What's it all about?

again, this is kind of like a race condition.


Structured data: What's it all about?

So multiple things happen at the same time.


Structured data: What's it all about?

And depending on what takes how long,


Structured data: What's it all about?

the order might change.


Structured data: What's it all about?

And then in the testing tools, it might look like this.


Structured data: What's it all about?

But then when we did it in the indexing pipeline,


Structured data: What's it all about?

it looked different.


Structured data: What's it all about?

And then catching that is non-trivial.


Structured data: What's it all about?

That is actually, it requires a bit of experience and digging,


Structured data: What's it all about?

I would say.


Structured data: What's it all about?

That's definitely gotten better over the last couple of years


Structured data: What's it all about?

though.


Structured data: What's it all about?

We've done a lot of work of reducing the cache


Structured data: What's it all about?

time for some of the data fetches, which has


Structured data: What's it all about?

helped structured data out a lot.


Structured data: What's it all about?

Yeah, speaking of the work that has been done,


Structured data: What's it all about?

what about the work that's to come?


Structured data: What's it all about?

The next couple of years for structured data,


Structured data: What's it all about?

if you were to give us a peek into the future,


Structured data: What's it all about?

what is next for structured data?


Structured data: What's it all about?

In the medium term, I think we're,


Structured data: What's it all about?

I mean, we continue to flesh out the structured data usage


Structured data: What's it all about?

in terms of adding more features and looking into more ways


Structured data: What's it all about?

we can use it in cooler things that are not just


Structured data: What's it all about?

visual treatments, but actually help with more understanding


Structured data: What's it all about?

on the page, I think, and figuring out


Structured data: What's it all about?

how to use structured data more universally


Structured data: What's it all about?

in a lot of our features rather than just sort of here


Structured data: What's it all about?

and there scattered around.


Structured data: What's it all about?

I think that's what we're looking


Structured data: What's it all about?

at in the medium term.


Structured data: What's it all about?

Long term, I think that it's going


Structured data: What's it all about?

to play a really interesting role at interacting


Structured data: What's it all about?

with the way that we interpret data in general


Structured data: What's it all about?

into our internal graph.


Structured data: What's it all about?

So I would like to see more machine learning,


Structured data: What's it all about?

figuring out sort of, like I would


Structured data: What's it all about?

like to move to where we are adjusting more and more data


Structured data: What's it all about?

through data, structured data specific channels


Structured data: What's it all about?

rather than necessarily conveying


Structured data: What's it all about?

all of our information on the web page itself.


Structured data: What's it all about?

So I think that's a much cleaner approach, particularly


Structured data: What's it all about?

for some of our structured data ingestion paths.


Structured data: What's it all about?

So figuring out a way to get around


Structured data: What's it all about?

the actual visual representation and figuring out


Structured data: What's it all about?

ways to link the structured data with the web page,


Structured data: What's it all about?

but not necessarily embedded on the web page.


Structured data: What's it all about?

So I think there's a cleaner way to do data transfer between


Structured data: What's it all about?

data providers and Google.


Structured data: What's it all about?

Would this also potentially make it easier for new website


Structured data: What's it all about?

owners to benefit from some of these,


Structured data: What's it all about?

I don't know, enhancements at Google


Structured data: What's it all about?

if we were to be able to pull the information


Structured data: What's it all about?

in a different way?


Structured data: What's it all about?

I think that it will make it easier for plugins and CMSs


Structured data: What's it all about?

to create that information particularly.


Structured data: What's it all about?

Because I feel like a lot of the ecosystem


Structured data: What's it all about?

has sort of moved in that direction where people aren't


Structured data: What's it all about?

implementing the structured data themselves,


Structured data: What's it all about?

but rather are using content creation tools,


Structured data: What's it all about?

I think it's becoming more important that we have


Structured data: What's it all about?

mechanisms to work directly with those content creation


Structured data: What's it all about?

tools to ingest the data in a programmatic way in order


Structured data: What's it all about?

to make it fresher and easier.


Structured data: What's it all about?

Excellent.


Structured data: What's it all about?

Well, I'm looking forward to working more with you


Structured data: What's it all about?

and hopefully more structured data


Structured data: What's it all about?

documentation for general usage.


Structured data: What's it all about?

We're so happy that you joined us here on this episode.


Structured data: What's it all about?

And that's it for this episode.


Structured data: What's it all about?

Thanks for joining us here, folks.


Structured data: What's it all about?

We've been having fun with this podcast,


Structured data: What's it all about?

and I hope you, the listener, have


Structured data: What's it all about?

found it both entertaining and insightful too.


Structured data: What's it all about?

Feel free to drop us a note on Twitter at Google Search C


Structured data: What's it all about?

or chat with us at one of the next virtual events we go to


Structured data: What's it all about?

if you have any thoughts.


Structured data: What's it all about?

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


Structured data: What's it all about?

Thank you and goodbye.


Structured data: What's it all about?


Copyright (a holistic view) | Sustainable Monetized Websites

Welcome back to Sustainable Monetized Websites,


a series for online content creators and content managers


who also handle monetization.


I'm Aurora, and I work in policy transparency at Google.


And these are my two co-hosts, Organica and Monetized.


In this episode, we will take a look at copyright


from a holistic point of view.


We'll see what happens in the future.


And we'll talk about how we can make money


We'll see what happens from the content creator angle,


as well as from the side of a publisher


who receives a copyright infringement notification.


Please bear in mind that this is not intended to be legal advice,


so you should consult an attorney if you have questions


about any of the copyright-related topics we're about to discuss.


Let me start by saying copyright is a form of intellectual property.


A copyright holder who creates an original work,


such as an image or a piece of music,


typically holds a copyright in that work.


Generally, the copyright holder can control


who can make and distribute copies of their work,


who can display or perform it publicly,


and who can make derivative works based on it.


Exceptions to this rule are uses that fall under fair dealing or fair use,


or using or parody.


Many types of works are eligible for copyright protection.


Examples of this include, but are not limited to,


audiovisual works, such as TV shows, movies, and online videos,


sound recordings and musical compositions,


written works, such as lectures, articles, and books,


visual works, such as paintings, posters, and advertisements,


video games and computer software,


and dramatic works, such as plays and musicals.


Google does not allow content that infringes copyright.


Under this policy, we will respond to copyright infringement notifications


to comply with copyright laws worldwide.


And what are those laws?


One example is the United States copyright law,


known as the Digital Millennium Copyright Act, or DMCA.


Under this law, Google may, when properly notified,


disable access to content that violates it.


Now that I've covered the basics of copyright,


let's test your knowledge.


It's...


THE BACONAL


I will read a statement and you will tell me if it's true or false.


Round one.


If I give credit to the copyright holder,


my use of their content is automatically not infringing.


True.


And that is wrong.


BEEP


Giving credit to a copyright holder


does not make a particular use of copyrighted content


authorized or fair.


Round two.


The copyright holder has the right to control all uses


of the work they produce.


And that is false.


In limited cases, other people can use content from a work


that's protected by copyright


without getting permission from the copyright holder.


That's because some unauthorized uses of copyrighted works


are considered as fair dealing exception or fair use.


But it's not always easy to tell which uses are fair.


Users can provide relevant information to Google


that will help assess their case.


Third and final round.


If you see an image that you know is being used in a way


that infringes on someone else's copyright,


you should submit a copyright infringement notification


on the copyright holder's behalf.


BEEP


True.


And that is...


False.


Only copyright holders or their authorized representatives


can submit copyright infringement notifications.


You may not know whether someone has a license


to use another person's copyrighted work or not,


and Google has to be careful not to remove legitimate content.


Users who send copyright infringement notifications


to Google must check a box swearing under penalty of perjury


that they are the real copyright holder


or authorized to act on behalf of them.


And that's it for the copyright quiz.


Let's look now at the copyright removal request process.


As a web publisher, you could find yourself


on both sides of a copyright removal request.


You might be the copyright holder who finds that another publisher


is using content you created in a way that you think is infringing.


Or you might have used another right holder's content


in a way that they believe is infringing.


If you're a content creator and you believe there's an unauthorized copy


of your content on a website that you would like to have removed,


the first step is to contact the site owner


to request the content removal at the source.


If that doesn't work out, you can initiate a process


to delist the specific web page containing that content from search results.


The easiest way to report copyright infringement to Google


is through our legal troubleshooter.


Once you've selected the product, make sure to file


a complete copyright infringement notification,


as we cannot take action on incomplete submissions.


Using the troubleshooter will ensure that your notification


contains all the legally required elements,


such as your description of your work that you believe has been infringed,


and the URLs where the allegedly infringing content can be found.


When we receive a valid copyright infringement notification,


our teams carefully review it for completeness.


If the notification is complete and we find no other issues,


we will delist the URL from search results.


Thanks for that, Organica.


Monetized, what happens if you are the site owner


and Google lets you know they've had to remove content from your site


due to a copyright infringement notification?


If Google receives a valid copyright infringement notification


against your site or page, meaning that someone has reported


your online content for copyright infringement,


your page-level URL will be delisted from Google search results.


If you're an AdSense publisher, your content monetization


will also be disabled on that page, as per our publisher program policies.


As we mentioned in episode three of our series,


make sure your site adds unique value.


When a URL is removed due to a claim of copyright infringement,


we notify both the complainant and the site owner through Search Console.


The URL is delisted from Google search results.


Sites with high number of removal notices may appear lower in search results.


Ads can no longer be placed on the page containing claimed infringing content.


If you believe your page was removed by mistake,


you can either contact the claimant directly


to request a retraction of the takedown notice,


or you can submit a counter notification.


When filling out your counter notification,


please be sure to identify the specific URLs


or other unique identifying information of material that Google has removed


or to which Google has disabled access.


Your counter notification request must meet all legal requirements


and clearly explain your right to use the copyrighted content in your own words.


If you think the content was wrongly identified,


explain why in a clear and concise way.


Luckily, Google's web form will guide you through the submission process.


Once you submit the counter notification through a web form


or on Search Console, if it meets all legal requirements


and clearly explains your right to use the content,


it is then forwarded to the claimant


with the full text including the contact information you've entered.


We won't forward the counter notification to any party


other than the original claimant.


The claimant will then have 10 business days


as required by the copyright law to reply to your counter notification.


They'll need to respond with evidence that they are taking legal action against you


to keep the content from being restored.


If they don't provide this evidence in the provided timeframe,


the content will automatically be reinstated.


And why can't Google determine copyright ownership?


Google can't resolve disputes over who holds the copyright


in a particular piece of content.


When we receive a complete and valid copyright infringement notification,


we remove the content as the law requires.


When we receive a valid counter notification,


we forward it to the person who requested the removal in the first place.


If there is still a dispute after that process plays out,


it's up to the parties involved to resolve the issue in court.


If you are not sure whether certain material infringes the copyrights of others,


we suggest that you contact an attorney before posting it.


In an effort to inform discussions about online content regulation,


Google regularly publishes transparency reports


that disclose data on content removal requests.


There is a specific report on content delistings due to copyrights,


where you can explore the data and find requests from copyright owners


and the reporting organizations that represent them.


Remember, Google is required by international copyright laws


to remove content in response to valid claims of copyright infringement.


So only publish and monetize content that is non-infringing.


A valid claim of copyright infringement


will remove your URL from Google search results,


and the claimed infringing content will no longer be accepted


for AdSense monetization.


We hope you enjoyed this episode.


Don't forget to like and share this video


and subscribe to this channel so that you're the first one to get new content.


Top 5 things to consider for your website | Search for Beginners Ep 7

Is your website ready to be listed on Google search?


Here are the 5 things you should make sure your website does.


Number 1. Does Google know about your website?


You can check if your website is known to Google search by performing a site colon search for your domain.


One of our previous episodes explains more about the site colon operator.


Check out the description below for a link.


If your website isn't showing up at all, it means that Google is not aware that it exists.


This usually occurs naturally when someone links to your website from another website,


but maybe you have a brand new site that Google hasn't discovered yet.


In that case, you can go to Google search console to verify ownership and submit your site map.


Google will then crawl your website and discover its pages.


If your business has a physical location, it's important to make sure your website clearly lists information such as the address and store hours.


Make sure to add this information in an easy to find page on your website,


and if you enhance it with structured data about your business, it will make it really easy for Google to discover and understand.


That said, this can sometimes take time, so one simple way to make these details available on Google is by using Google My Business.


Google My Business is a free and easy to use tool that helps you manage how your business information appears across Google,


including Google search and Google Maps.


You can add your business and its website by visiting google.com slash business.


Number two, now that your site appears on Google search,


how can you be confident you are providing high quality content that appears in relevant searches?


Are you providing users with the best possible experience?


Focus on what makes your website or product unique, valuable and engaging.


Check out the Google Webmaster Guidelines for website policies and best practices.


Following that advice will help Google determine the relevancy of your pages.


Number three, is your content fast and easy to access on all devices?


Most Google searches now occur on mobile, so make sure your content is optimized and loads quickly on all devices.


Visit g.co slash mobile friendly to test if your pages are mobile friendly.


Number four, modern users expect a safe online experience.


Secure your website with an HTTPS connection that keeps your browsing safe


by securely connecting your browser or app to the websites you visit.


This prevents bad actors from peeping into what is being sent.


Number five, are you looking for someone to work on this on your behalf?


Hiring a search engine optimizer or SEO might be an option.


SEOs are professionals who can help improve the visibility and ranking of your website.


We'll talk more about hiring an SEO in future episodes.


For now, don't forget to subscribe to the Google Webmasters YouTube channel


English Google Webmaster Central office-hours from October 1, 2019

Hi, everyone, and welcome to today's Webmaster Central Office


Hours Hangout.


My name is John Mueller.


I am a Webmaster Trends Analyst here at Google in Switzerland,


or at home at the moment.


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


where webmasters and publishers can jump in and ask us


any questions around their website and web search.


There are a handful of questions submitted on YouTube.


We can run through those.


But if any of you want to get started


with a question of your own, feel free to jump on in.


Or if not, that's fine too.


Let me just see.


OK.


So let's refresh the list and see what we have for today.


From an SEO point of view, is there


any difference between posting all external links


and citations in footnotes, like, for example,


in scientific papers, instead of putting them in text?


Is there any guideline suggested?


So practically, there is a difference there


in the sense that when we find links


within the content of a page, within extra context,


it's a lot easier for us to understand


what this link is about.


So you could imagine, like, we have one paragraph of text,


and there's a sentence in there with a couple of words


that are linked directly.


Then there's a lot of context for that link


that tells us a little bit more about what is being linked to.


And that helps us to better understand the page that's


being linked from there.


In comparison, if you had all of the links in the footnotes,


essentially a block of links that


are all together and no additional text


around that block, as a human reader,


you might be able to look at that and see, oh,


there's a small number, and that matches a small number


somewhere in the text.


But essentially, it's completely separate.


It's a block of links on its own.


It doesn't have a clear anchor text.


Then that's something that, from our point of view,


would make it a lot harder to understand


what those links are about.


So especially if you're doing things like internal linking


within your website, you want to make sure


that you give as much context as possible for the pages


that you're linking to.


So from that point of view, I would strongly


recommend just putting those links normally


within the context in the place where users would find them


as well and where users would be able to use them directly.


So instead of users having to scroll to the bottom


and try to search for a link and click on it,


they can access it directly.


Some sites, like I guess Wikipedia


is probably one of the more prominent ones,


tend to do it with footnotes.


And that's just the way that they do it.


From my point of view, if you're making a normal website,


then I would try to stick to the trusted model of having links


with clear anchor text on a page and those links


being placed normally within the page itself.


Does the meta robot's max snippet also


apply to the featured snippet?


Does the data no snippet attribute not


count toward the ranking of the page?


What about those kind of meta tags?


So the max snippet meta tag, robots meta tag,


essentially tells us how long in characters


a normal text snippet can be.


And that applies regardless of where it's shown.


So that's something if that result is shown


in the top in a featured snippet or somewhere in between


as a featured snippet or as a normal blue link result,


then the max snippet length is essentially


the number of characters that we would


show for that normal result.


There's one exception offhand that I can think of.


I'm sure there's something else I'm missing.


But if you're using structured data


to trigger a specific rich result type,


then that would not apply.


For example, if you have structured data


to create a recipe, and that recipe


is shown as a recipe result in the search results,


then it doesn't really make sense to count the characters


there, because these are different elements that


all kind of build up this search result together.


It's not one block of text that you can clearly kind of limit


by number of characters.


So if you have structured data and your page


is being shown with that appropriate rich result type,


then the max snippet length would not apply there.


But for the normal search results,


it would definitely apply.


One thing also there to keep in mind


is that with some types of search results,


we need to have a snippet that we can show.


For example, if you have a featured snippet


and you set the max snippet length, I don't know,


to one character or something else,


then it's probably likely that we wouldn't show that


as a featured snippet, because with one character,


there's not a lot of information that we can give.


So from that point of view, if there's a specific search


result type that you're aiming for


and you want to use these new meta tags,


then make sure that you're not kind of blocking that search


result type from appearing.


Similar with image results, if you


say I don't want to have any image preview shown,


then we won't be able to show any image preview.


So any search result that depends on an image preview


to function, that wouldn't be usable from that point of view.


With regards to the data no snippet attribute,


I think that's a pretty cool attribute that


lets you specify within a page which parts of the content


you don't want to have shown in a snippet.


And that also applies to all places


where we would show the normal text snippet.


It wouldn't apply to structured data.


So again, if you're doing a recipe


and you mark up a recipe, then we


assume the structured data that you specify for a recipe


is something that can be used as a recipe.


Otherwise, if you don't want to use as a recipe,


then don't use the markup.


But essentially, for any normal text preview


that we would show, that's something


where that would apply.


And it doesn't change ranking.


It really only changes what we would show in the preview.


So if there is something important that's in there,


we would still rank that page for that content.


We just wouldn't show that in the preview.


Let's see.


It seems that the title tags have again been reduced.


And now my title description appears truncated.


This is fine, since I could remove a few words.


And essentially, I think it goes to, well,


why do you keep changing the title tag length?


I keep working on my titles, and then you change the length


again.


I realize that can be frustrating, especially


if you're fine tuning your titles like that.


However, I don't know if it's always worthwhile to actually


fine tune the titles like that.


It's mostly because of two things.


On the one hand, the title tag, the title length


that we display can change over time, like you saw there.


And on the other hand, sometimes we automatically


generate titles for your pages, depending


on the query and page, to make it easier understandable


for users why this page is relevant for their interests.


So that's something that can change algorithmically anyway.


So you're not always guaranteed that you


will see exactly the title as you


have it specified on a page.


So from that point of view, I'd be


kind of cautious about always jumping in and saying,


oh, the title is a little bit shorter in the search results.


Therefore, I need to rewrite everything.


I would kind of let it settle down.


And if you see pages where you see the titles are significantly


off from what you would like to have shown,


then that's something where I would focus on.


And again, keep in mind, we optimize the title


based on the query.


So just doing a site query and seeing what titles are shown


is not necessarily representative


of what the user would see.


So I would double check the queries


that lead to your site.


You can get those in Search Console.


You can look at the impressions.


And based on those queries, try them out.


Then see if the title that's shown


for your pages for those queries is something


that you think makes sense or not.


And then based on that, kind of make a list of the things


that you'd like to have changed.


And work on those titles and try to make them


a little bit better.


And the same applies to descriptions as well.


Descriptions are also generated automatically


based on the page and based on the query


that the user is doing.


So doing a site query to see the descriptions that we would show


kind of that preview text doesn't necessarily


represent what a normal user would


see when they search for something very


specific for your website.


So that's two things to kind of watch out for.


The other thing just in general is


that I think we'll continue to make changes in the search


results as we see that it makes sense.


We test these changes quite extensively


to make sure that the things that we change


make sense for the users.


It's not that someone just goes in there and says, oh, let's


see what happens when I add five more characters


or when I change the font size by two or three pixels.


It's something that is really tested intensively.


It's something where we test it together


with the quality raters, kind of on a manual level


to see if it still works out.


And we test it algorithmically as well.


And that we do kind of A-B testing with the search results


all the time.


But we have, I don't know, hundreds


of tests running at the same time.


And most of those tests, we notice, well,


this is not really working out the way that we expected


or that we hoped it would happen.


So we tweak the test.


We try it again.


And we try it again until we come to a situation


where we see, well, actually, at the moment,


based on what we see users kind of responding with,


this algorithm, this UI change makes sense.


And maybe we should roll it out a little bit broader.


So these are things that are usually


in the pipeline for quite some time.


And the teams here are constantly


tweaking and trying to make things better.


I think that's something that every website should do.


If you're active online, the internet is constantly evolving.


The user needs are constantly changing.


The devices they're using kind of change over time as well.


So you really need to constantly kind of be on top of things


and A-B test and figure out where you can improve things,


sometimes incrementally.


Sometimes you can improve things quite extensively as well.


Let's see.


I seem to have missed that last pop-up.


OK.


We bought a domain from our competitor


and redirected it to ours.


Is there any way to find the old disavow file


or to disavow new backlinks to this domain?


Even though it's in Search Console,


it's not showing up in the Disavow tool.


So there are kind of two things here.


On the one hand, I believe the disavow file


will be visible when you have it verified normally.


However, to verify it so that you can use it


in the old tools from Search Console,


you need to make sure that you verify it


as kind of an old-style property,


so with either the meta tag or the HTML file or one


of the other methods there.


And based on that, you should be able to download the disavow


file once you have that verified.


I don't know if you would see a lot of value out


of redirecting a domain from someone else's website


to your website, but if you bought that domain,


and especially if you're in a situation where you're saying,


well, there is a lot of direct traffic to this old domain,


and it's something where I think my site would be a good match,


then that might be a chance to kind of look into that.


But again, you'll find a disavow file in the Disavow tool.


And for that, you need to create an old-style property.


And you need to create the old-style property that


was used to upload the disavow file.


So things like HTTPS or HTTP, www or non-www,


those are things that you need to keep in mind.


You can just add all four versions


and see where the file is.


That might be an easier approach than trying to figure it out.


Last month, I launched a new website


and have been releasing content weekly on the blog,


over 1,000 words weekly, which is getting good views


due to social sharing.


After one month, I'm not ranking in the top 100


for any of my keywords.


And they tried Search Console, and they used the feedback link


on the bottom of the search results pages


to let Google know about this.


But is there anything that can be done there?


So I think, in general, you can't always


expect to show up in the search results,


especially with a new website, just because you're creating


content that's out there.


So that's something where it can take a bit of time for things


to settle down, for our systems to understand.


But actually, this is a pretty good website.


And it can take a really long time,


especially if it's on a topic where


there's a lot of competition.


So just because you have a new website


and you're regularly creating content for it,


doesn't necessarily guarantee that you


will be shown for all search results


that you're creating content for.


The other thing to keep in mind is,


since you mentioned the over 1,000 words,


we don't have any limit or any kind of guideline


with regards to how many words per page


or how many words per month you should be generating.


Essentially, we try to make sure that we show relevant search


results to our users.


And sometimes those pages that we link to have a lot of text.


Sometimes those pages don't have a lot of text.


There is no magic number from our side


where we would say, this is the number of words


that you need to target, and then we will show you


in the search results.


So that's another thing to keep in mind there.


I would definitely check out the SEO starter guide.


We have that linked in the Help Center.


That has a lot of good information there.


I think, especially if you're targeting


this commercial niche of insurance


where it's probably pretty competitive,


then I would make sure to try to get some help from someone


who's a little bit more experienced with regards


to making websites do well in search.


Sometimes you just need a little bit of tips.


Sometimes you really need more long-term help


if it's something where you really


need to support a website for the long run


and make sure that it's kind of competitive enough


to match what others are doing in that space.


Is there any way to tell Google, please crawl me more


and ignore the duration time as the page gets slower?


No, not necessarily.


So what we have in Search Console


is the crawl rate setting, which you


can use to give us a little bit of information.


But it's not something that would override


our general systems where we would say,


try to protect your server from being overrun.


So that's something where if our systems feel


that your server is not able to cope with our crawling,


then we will slow down.


Because we really don't want to cause


any problems on our website.


We really want to make sure that we can crawl your pages,


we can index them kind of reasonably,


and that the majority of your traffic


is actually for your users.


It's not that you're making a website


and creating the content, providing it just for Google.


You're kind of creating it because you


have users out there who you hope would


be attracted to your content.


So we want to make sure that your website stays


available for them rather than kind of running it to the ground


to crawl every last bit.


Let's see.


Some.


Hi, John.


Can I ask you the last question, please?


Sure.


Thank you for the answer.


I definitely know about the crawl rate settings


in Google Search Console.


And I talked at Wednesday with Martin Split about this.


But we didn't find any good solution.


But the thing is that the page is very large.


And you can click Read More in my comment.


There is a lot of information.


It is not only about the crawl rate settings in Google Search


Console.


OK.


Yeah, OK.


Go ahead.


Sorry.


No, no.


Do you want to tell something?


Oh, no.


Thank you.


The thing is that the website is on Angular 1.


And we use Chrome Headless for dynamic rendering.


And we have about 500 million pages, URLs.


And we only cache about six millions.


And the others are rendered on the fly,


like on the Chrome Headless.


And it takes about 1.5 seconds per URL.


So it is very slow.


And the thing is that when you crawl,


the limit, the set of six millions URLs which are cached


and which are most important for us


is OK because they are pretty quick.


But in case Google is, I don't know how to express it,


when you have enough of these URLs


and try to find another ones, try


to crawl another ones which are not in the cache,


it takes about 1.5 seconds per URL.


And it means that the mean of duration time or render


time or crawl time is something like it goes really higher.


So I know that in this case, it looks like Google


both says to himself something like, yeah, oh, maybe I'm


the bad guy who is slowing the web server.


So maybe I have to slow.


But I don't want him to.


I want him to crawl as much as possible


because we have a lot of servers.


But our problem is that the mean time for rendering,


it's about 1.5 seconds per the URL, which


we can get better with this technology like Angular 1


and Chrome Headlines.


We know that we have to change the technology to, I don't


know, React or something like this, maybe PHP or something.


It doesn't matter.


But the thing is that in this technology setup,


I want to tell Google, crawl me as fast as you can.


Now, I don't think that that would be possible, no.


So let's see.


I think, so in general, that's something where


we would probably slow down.


I would also not use the crawl rate setting


in a case like that.


Especially for really large sites,


if you use the crawl rate setting,


the setting maximum value is probably


too small for what you need.


So instead of setting it to the maximum value,


I would disable that setting so that we


can crawl as much as possible.


I think you linked to the domain in the question.


I didn't see that.


It looked like the question was complete there.


And looking at that, it is the case


that we're kind of limited from crawling


because we were kind of worried for probably speed


reasons at the moment with regards to what we can crawl.


I don't know when you switched over to the new setup.


It looks like mid-September we were


crawling a little bit better.


But it fluctuates a little bit.


So it's really hard to say much there.


But it's really something where we see the content.


We recognize that sometimes it gets slow.


And so we limit the crawling that we


do there to make sure that we're not causing any more trouble


with regards to that.


So one thing you could potentially think about


is moving the kind of pre-rendered content


to a different host so that we can separate


these two configuration.


I don't know if that would make sense in your case


or if content would move between the kind of pre-rendered state


and the on-the-fly rendering state.


That might be something that would work.


I don't know if that makes it any easier on your side


compared to increasing the number of pre-rendered pieces


of content.


What I would also kind of double check


is the crawling that we do versus the pre-rendered content


that you provide if that kind of is in line.


Not that we're spending all the time crawling pages


that, from your point of view, you think are irrelevant.


That might be something to kind of look at.


You could see that in your server logs


where you pull out the URLs that we crawl


and compare that to your list of URLs


that you would have pre-rendered.


But I don't see any other big approach there.


Because if we see that things are slow,


then we try to adapt and say, well, usually the speed thing


is not something that we would kind of say, well,


your server appears to be really slow.


But it's something where we'd say


we want to limit the number of simultaneous connections


that we have to your server.


And if it takes, I don't know, two seconds


to load a page from your server, and we


want to limit the number of connections


that we have simultaneously to, I don't know,


10 or some other number, then obviously there's


only a maximum number of pages that we can crawl per second.


So that's kind of where that speed aspect flows in.


So if you need to serve these pages slow,


then I don't know if that's really kind of the easiest


approach there.


Maybe another thing that you could do,


depending on the pages and how you have them set up,


is to have some part of it kind of server-side rendered


and another part just dynamically included


so that the server-side rendering doesn't


need to do all of the work and can


be done a little bit faster.


I don't know how your pages are built up


or how your infrastructure is set up.


That might be an approach as well.


SPEAKER 2


Let's see.


What else we have?


That's anything that's been added.


It looks like most people added their questions


to the Friday Hangout, which is the top one in the YouTube


list, which is not really the one for now.


But that's fine.


We can look at that on Friday.


I want to move my best articles from the old domain


to a brand new domain.


Is there any correct way to do it?


Will cross-domain canonicals help in this situation,


or should I noindex the old ones?


I don't want to 301 them, as I don't


want to send any links or content quality relevant


signals to the new domain.


I think you probably have to make up your mind there


with regards to old domain and new domain.


So you can't forward signals to the new domain for these pages


and say you don't want to forward signals,


because either you're forwarding the signals


or you're not forwarding them.


It doesn't really matter if you're using redirects,


if you're using a rel canonical, if you're


using JavaScript redirect or meta refresh or anything


like that.


If you're telling us that one page has


moved from one URL to another URL,


then we will forward those signals to that new URL.


So in that case, if you want to move some of this content


from one URL to the other, then using redirect


is probably the best approach.


If for practical reasons you need


to keep it on two separate domains,


then using a rel canonical is a good approach.


But in both of these cases, we forward the signals from one


URL to the other URL.


So that's something just kind of worth keeping in mind,


in that you can't have both your old URL ranking with full power


and your new URL ranking with full power


if you're telling us that the old URL has


moved to the new one.


So pick one, whichever one you want.


Personally, I usually recommend trying


to keep things on as few domains as possible.


On the one hand, for practical reasons,


because you need to maintain all of this somehow.


On the other hand, it makes it much easier for a good domain


to be really strong if you have all of the content


that you care about on one domain.


But ultimately, that's up to you.


Sometimes there are also kind of marketing things involved


here as well, where maybe you're using


a URL in offline advertisements.


Then that's something where you might


want to have that old content available on that URL,


as well as having a rel canonical set up to the one


that you prefer to have indexed.


Let's see.


Hi.


AUDIENCE 1 So I have a question about translated content.


For me, it makes sense that if you translate not automatically,


but if a translator translates content, it should be unique.


But I see so many questions, and people are kind of confused


that they think that it can also be treated as punk content.


So yeah, I wanted to run it by you.


Is it unique content if you translate it


like a real person translates it?


Yes, absolutely.


I think the easiest way to look at it


is these are completely different words.


So if you translate the content from one language to another,


it's a completely new piece of content.


It's not something where we would say this is


a variation of the previous one.


It's essentially a completely new piece of content.


You can link the two with hreflang


if you wanted to do that, but you don't need to.


Sometimes people just have a translated version


of the content and have that completely separate.


But it's definitely not seen as duplicate content.


I think the one case where it kind of gets


into the duplicate content discussion


is when you have content that you're translating


from American to British, for example,


and you're just tweaking individual letters to match


what the other side is saying.


Then that's something where we might say,


well, this chunk of text is essentially


the same as that chunk of text.


But if these are different languages,


it's completely different content.


Yeah, OK, thank you, and one more question


about structured data.


So if you have, for example, one kind of structured data


which is invalid or has errors or spamming some kind,


so for example, you have product structured data


and structured data for organization and for posts,


but only one of these structured data sets is invalid.


Does this mean that Google will just disregard all of them


or only this type which is invalid or spamming?


So it depends on how we would recognize that and ignore it.


If it's something that the web spam team manually recognizes,


then that's something where we've


shifted to a more granular model where


we can try to isolate that specific type of structured


data.


So if your organization markup is bad,


but your product markup is good, then you


could get a manual action for just that organization markup.


And then just the organization markup


would not be shown in search.


It's similar if the markup is essentially just broken,


where we can't process it properly


and the organization markup is broken,


the product markup is OK, then we would just


have the product markup, and we can show the product markup.


So it's not the case that if one is bad,


that we would ignore it completely.


It's something where we try to do it on a piece by piece basis.


I think it would get tricky if you had multiple products


across your website, each with the product markup,


and some of those product pages have spammy product markup


and some of them don't, then the web spam team might still say,


well, for this domain or this website overall,


the product markup contains spammy elements,


so we won't show any of the product markup.


And then that would apply across all of these pages.


But if these are different types of markup,


then we would try to treat them separately.


SPEAKER 2


All right.


Oh, man.


I imagine all of the questions are lined up for Friday,


so it'll be really busy then.


But more time for you all to ask questions live in that case,


if there's anything.


Oh my gosh.


We run out of questions.


Let's see.


Yeah, I don't know.


SPEAKER 3 OK, one question for me then.


Go for it.


Not.com at the end, but.io.


And it's initially geographical identification.


But I see that many tech companies, startups,


they tend to use.io at the end.


Does this mean that Google just treats


this more like a general country-level domain


or real country-level domains, if it makes sense?


Yeah.


We have a list of country code top-level domains


that we treat as generic top-level domains.


I think that's in the Help Center somewhere.


I do not know offhand if.io is on there.


I imagine it is.


But things like CO instead of Columbia, lots of people


use it for company.


That's something that's on this list.


A really simple way to double check


if you have the website already is to use Search Console,


verify that domain, and go to the international targeting


tool and see if you can set an international target.


If you can set the country target,


then we treat it as a generic domain.


You can target any country that you want.


Or you can just say, I don't want to target any country.


I prefer to keep it generic.


OK.


Thank you.


Sure.


The same applies also for all of the new domains.


And for all of the new domains, we treat them


as generic domains, even if they look like country or location


domains.


So for example, if you have.Berlin or, I don't know,


.nyc is one, I think, then they're


essentially sold as a location-specific top level


domain.


But we treat them as a generic top level domain


because we haven't had any experience that this is limited


just to one target audience.


So if you have something like.nyc


and you want to make sure that you're targeting users in US,


then make sure that you check out


the international targeting setting in Search Console


so that you can really geographically target the users


that you're looking for.


OK.


Yeah, thanks.


Cool.


Wow.


I did not expect that we would run out of questions.


Let's see.


One in the chat.


If we block Googlebot but do not mark our pages as no index,


will our pages still be indexed in Google?


In our case, we have a staging site


that we would like to use some tools to crawl for errors,


but they require the page to be marked indexable.


So it depends on how you block Googlebot.


Our recommendation for staging sites


is to try to block Googlebot on a server level.


So either with HTTP authentication or with IP address


whitelisting, that you kind of let the users or the tools


that you need to have access to your site


have access and block everyone else.


If you do it like that, then make sure


that we can't crawl anything from your website.


On the other hand, if you use a no index,


then we might still crawl some of those pages


from your staging site.


Or if you use a robots.txt file, then it


can happen that we index pages without crawling them.


So we'll just index the staging site URL.


And if you do a site query for the staging site,


maybe we'll have some URLs from your staging site


that we know about but haven't been able to crawl.


So both robots.txt and no index are two things


that I would not recommend for staging sites.


Instead, try to use either authentication, so username


password setup, or work with IP addresses


that you're explicitly allowing the IP


addresses of the tools and the users


that you'd like to have access for these pages.


So in both of those cases, we wouldn't


be able to crawl as well.


And that would let us understand that this is not something


that you want to have indexed.


The other thing with robots.txt and no index


is that it happens extremely frequently, even


for really large websites, that they


push a version of a new website live that has everything


blocked by robots.txt or everything


with a no index meta tag because they


forget to double check that.


And if you're using authentication or IP addresses,


then it's really trivial to recognize


that you left the wrong settings in place


and you need to fix that before letting it run loose.


SPEAKER 2 I would have another question.


JOHN MUELLER I'm not sure if you will answer,


but is the Google update, the call algorithm update,


already over, or is it still running?


Which update do you mean?


SPEAKER 2 The September call, I don't know how you call it.


JOHN MUELLER Or the call algorithm update.


SPEAKER 2 I think it is, yeah.


JOHN MUELLER I don't know, to be honest.


Probably it's completely rolled out.


Usually updates like these take, I don't know, a couple days,


maybe a week to roll out completely.


But it's something where we tend to announce them


when they happen so that people know what's roughly happening.


But it's really hard to give an exact starting and end time


because there are always so many other things that


are happening in search.


SPEAKER 2 OK, thank you.


Another question from the chat.


Our web dev recently locked down access


to unknown crawlers in Cloudflare, I guess.


I've heard that Google will crawl sites


using nonstandard user agents to check for cloaking.


Is that true?


If so, is there any risk to our content getting crawled


based on our recent changes?


Is there anything I should advise our web devs


to do to accommodate nonstandard instances of Google?


So for web search, when it comes to crawling and indexing


content, we use the normal Googlebot.


So if there's something on your site


that you want to make available, you'll


see us crawl it using normal Googlebot user agent.


The exact user agent can vary a little bit.


So especially on mobile, we try to match it


to whatever device and settings kind of makes sense for that.


We're also working on adjusting the Chrome version in the user


agent so that it matches more what we use for rendering.


So that kind of exact level will vary over time,


or depending on how we access the page.


Also, desktop and mobile have slightly different user agents,


but they all have Googlebot specified directly


in the user agent.


So that's something explicitly to watch out for.


And if it doesn't have Googlebot in the user agent,


then it's not a crawler from Google search.


So if you're blocking everything that


has Googlebot in the user agent, then you


would be blocking Google from being


able to crawl and index that content for search.


We do have a variety of other user agents that access pages.


So things like for AdSense, we need


to be able to access the page to see what this page is about


so that we can show relevant ads.


I suspect there are other similar crawlers as well.


I think we have a list of those in the Help Center,


or a list of the more common ones there at least.


There is also for Search Console and for site maps,


I think, separate user agents that we would


use to confirm verification.


If you need to have the site verified in Search Console,


then make sure that you're not blocking the bot that


checks that this site is verified.


Or if you're using DNS for verification,


then that's one thing less to worry about.


And I believe for site maps, we also


have a separate user agent that fetches a site maps file.


Though I'm not sure, actually now,


it probably also contains Googlebot in the user agent.


That's easy to double check as well.


But if you're blocking all Googlebot requests


to your normal content and you have a site map file,


then probably you would be blocking


all of the requests for the URLs in the site map file


that we try to fetch.


So that shouldn't make much of a difference there.


But again, if you're blocking everything


that contains Googlebot in the user agent,


then you would be blocking everything


that is used for search.


Obviously, that makes our search team kind of sad


if you decide to block all of Google.


But ultimately, that's totally up to you.


And that's a choice that you can make.


Sometimes it makes sense to do that if you


have different things that you're testing out


and you want to let users take a look,


but you want to make sure search engines don't,


then that can definitely make sense.


Or sometimes you might just say, I want my content online,


but I definitely don't want any of it in Google at all.


Then that's also your choice, of course.


Let's see, I have a question.


Past the core update, our impressions on Google Discover


were reduced to zero.


Does this mean that Discover has blocked us?


Does Google Discover have a white labeling process


similar to Google News?


Google News is still giving us traffic.


No.


As far as I understand, Discover is a completely organic


feature.


Obviously, how and when we choose


to show content in Discover is quite different


to normal search because there's no query involved.


And in that sense, sometimes if you write about content


that people really care about, then that's


something we could pick up and show in Discover.


But it's not guaranteed that we would show it there.


On the other hand, Google News, like you mentioned,


is built on the setup where sites are kind of double checked


and placed into the Google News corpus


based on their submissions.


And based on that, we would show them in Google News.


So that's a completely separate setup from normal search


and from Discover.


OK.


Yeah.


More questions from any of you.


Feel free to jump in or let me refresh to see


what else is on the comment.


I think that's just the one that we just had about locking down


access to crawlers.


Was that about what you were looking for, Andrew?


Yeah, we're not blocking Google, but we're


blocking a bunch of other automated scrapers


from accessing the site.


OK, so the other way around.


Yes, yeah.


So if you're not blocking Google, one thing I would do


is double check the user agent and then


do that reverse IP lookup, which we have specified in the Help


Center, so that you make sure that you're kind of allowing


the real Googlebot, not other tools and scrapers that


use a fake Googlebot.


Because there are lots of them out there that say,


well, I'm Googlebot.


You should give me all your content.


OK.


Cool.


We still have 10 minutes left.


If people want to ask questions, feel free to jump on in.


One thing I did want to mention as well, especially


for this Hangout, is we recently announced a Webmaster


Conference in Mountain View.


So if you're in the US, in particular, in the region


there, then check out the Webmaster Central blog


and maybe sign up for that.


It's a free event.


We'll have a number of people from the search side


there as well.


We'll have some lightning talks, some Q&A with product managers


there.


I think it'll be pretty interesting.


We run these Webmaster Conferences


all around the world.


And this is, I think, the first one


that we're doing in the US.


So it's a little bit special for us,


but it's not the last one that we're


going to be doing, at least according to our plans.


So if you can't make it there, then don't panic.


I'm sure we'll have more opportunities as well.


But I'll be going there.


So if you want to drop by and say hi,


check out the blog and sign up.


Cool.


Well, if there are no more questions,


I guess we can close a little bit early.


That works for me too.


All right.


Oh, here comes one in the chat.


For local businesses building directory listings


and citations, do you guys count links


from these places like yp.com as backlinks?


I don't think we would do anything unique for sites


like yp.com.


We do take into account links from all kinds of sites.


We also ignore links from all kinds of sites


when we think that these links are not


that relevant for our algorithms.


So it's not that we would have a separate set of links


from this site should be treated differently because they belong


into this specific category.


It's more that for most sites, it makes sense for us


to treat links like normal links.


And if they have a nofollow, we treat them as nofollow.


If they don't have a nofollow, then we can follow that.


And for some sites where we're really not sure


if there's value in using these links for search,


we just ignore a lot of those links.


But it's not that we would do anything


special for directory sites or local business listings.


Cool.


All right.


So I guess with that, let's take a break here.


Thank you all for jumping in and joining us.


Hope to see you all in one of the future Hangouts as well.


And I wish you all a great rest of the week.


Bye, everyone.


Welcome to a New Series: #AskGoogleWebmasters

Hi, everyone.


I'm John Mueller from Google in Zurich, Switzerland.


Webmasters come to us with all kinds


of questions about their websites in Google Search,


about our tools, and about our search-related documentation


and policies.


We'd like to make it a little bit easier


to get these questions answered for everyone.


So we're introducing a new video series


called Ask Google Webmasters.


Is there something on your mind?


Just send it to us with the hashtag


AskGoogleWebmasters on Twitter.


We already collected a bunch of questions there,


but you're welcome to send us more.


We'll create short videos to answer them and publish


these on our YouTube channel on a regular basis.


Want to stay in the loop?


Make sure to subscribe to the channel


and tune in tomorrow for the first episode.


See you soon.


Remember to edit our page on YouTube to a truly summery


eJoined Curtis!


Next week at 3-inos up.


And next time on YouTube, the UX is endpointed


App Hazel wrecks all the things


you might not expect from the PCs of your local intellectually


Should I hide affiliate links? #AskGooglebot

Today, Emmanuel is asking whether it makes sense to hide affiliate links.


To explain briefly, affiliate links are links to other businesses.


The person placing the link will get paid when users go to that business and buy a product


or a service.


Affiliate links are fine.


It's fine to use these to help monetize a website.


There are two important aspects to keep in mind, though.


First, your website should provide unique content and value of its own.


It can be tempting to just republish a generic or low-quality description, but users expect


to find something useful on your website, too.


Second, affiliate links, as with other paid links, should be declared.


They should be declared both for users as well as for search engines.


For users, it's worth checking with local regulations regarding what you'd need to do.


For search engines, you should use the rel="nofollow", or rel="sponsored", link attributes to express


that this is a paid link.


It's not necessary to hide or obfuscate affiliate links for search engines.


There's no need to use any weird automatic JavaScript, on-click handling, or cloaking


to hide these.


Just link and declare them so that the links can be treated appropriately.


If you use JavaScript to add affiliate links, remember to add the appropriate attributes


there, too.


On this subject, often affiliate links are used within the context of product reviews.


If that's the case for you, double-check our search documentation to see if any kinds of


structured data might be appropriate to implement on your pages.


And that's it for this time.


I hope you found this useful and insightful.


See you in one of the next episodes of Ask Googlebot.


Is my website showing in Google Search? | Search for Beginners Ep 5

How do I know if my website is searchable on Google?


People who own websites, whether they are running an online business or managing a hobby site,


often check Google to see if their websites are appearing on search.


Sometimes they find their website listed, sometimes they do not.


Wondering why?


How do you get your websites to appear in search?


To check if Google knows your website, or if your website is indexed on Google at all,


type site colon followed by your website address into Google.


Searching Google using site colon in front of a domain


specifies that you only want to see search results for that specific site.


If your website appears here, it means Google knows that your website exists


and has already put some of its pages in our index.


What is indexing?


Check out our video explaining how Google search works in the description below.


Notice how your site is showing up on Google search.


Is your description text precise and representative of what your website offers?


If you don't see your website in a site colon search,


there could be a few problems with how your site is being crawled and indexed.


To remedy this, you can submit your site map and URLs to Google Search Console,


a tool for managing your online presence on Google search.


You can also test your URLs using the URL inspection tool.


Now that you're verified, Google knows about your website.


Check that it appears in the results of relevant searches,


like nice shirt, t-shirt store nearby, or buy t-shirt online.


To learn more about Google Search Console and page indexing,


check out the next episode.


And don't forget to subscribe to the Google Webmasters channel.


Absolute or relative URLs, which is better? #AskGooglebot

And now we have a question from Mike


about the difference between absolute and relative URLs


when it comes to search.


We've talked about URLs a few times in the series,


and that's good, since it's the basis of all websites.


Within a website, you can refer to pages


either with an absolute URL or a relative URL.


The absolute URL includes everything


that's needed to access that page.


This is similar to giving someone


the full address of a place they're trying to find.


A relative URL, on the other hand,


is relative to where you are now.


That would be like saying, go to the greenhouse


down the road from here.


When implemented properly, both of these approaches


lead to exactly the same location.


Some web developers or content management systems


have preferences one way or the other.


It's worth checking with the folks working on the website


to get their thoughts.


However, for search, it doesn't matter at all


which one of these you use.


Google treats both of these exactly the same.


You can also use both kinds of URLs within the same website.


There is absolutely no relative difference between them for us.


I hope the short and clear answer is useful.


Catch you next time here on Ask Googlebot.


English Google SEO office-hours from September 17, 2021

All right.


OK.


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


Office Hours Hangout.


My name is John Mueller.


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


And part of what we do are these Office Hour Hangouts


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


We have a handful of questions submitted already on YouTube.


We can go through some of those.


But we can also do some live ones to get started.


And it looks like Christian is the first one with his hands


raised.


Good morning, John.


Morning, everybody.


Yeah, great to have this opportunity


to ask a question here.


John, I already sent it to you.


And I thought I'd ask it again here in the Webmaster Hangout


because I think it can maybe be interesting for other guys


as well.


So it's about an e-commerce website.


We have a category page with products


and a huge advisory text.


And the ranking for one of the most important keywords


dropped after stable rankings for about one a year.


And the interesting thing is that the ranking


dropped only for the keyword in a plural form,


but not in singular form.


And the overall visibility of the websites


has even slightly increased.


So it's just this keyword.


And you already mentioned this could result from Google


not being able to differentiate between transactional


informational content.


But what would interest me is why


is this only with the keyword in singular and not in plural?


And yeah, do you have any advisory for this?


I don't know.


It's hard to tell.


But I looked at your page when you sent it to me.


And one of the things I really noticed


is that it is, on the one hand, a category page.


But also, there is just so much textual information on there


as well, which I think makes it really hard for us to figure


out what we should show it for.


Is it for someone who's trying to buy one of these products


or trying to get more information


about these products?


Is it for someone looking for one product or a bigger


picture of the whole space?


That's something where I could imagine


it's tricky for our systems to try to figure out.


So that's why I kind of recommended there


to try to split this off and to have two pages instead of just


one that tries to cover everything.


And with singular and plural, I don't know for sure


if our systems would take that into account.


But I could imagine that being something where


if you're searching for a kind of product in plural,


maybe you want different kinds of products.


If you're searching for one product in singular,


maybe you just want a product landing page or something.


And I could imagine that our systems, over time,


try to figure out what the intent is of these queries


and also that this intent can change over time, where


if we see that maybe we got it wrong with singular and plural


there, it could happen that we switch it back to something


where you say, oh, actually, this is more informational.


Or maybe it's also seasonal, where we would say, well,


at this time, it's an informational query.


But maybe if in December you're searching for Christmas trees,


then you want to buy one.


You have more of a transactional intent.


And if you have one page that covers both of these intents,


on the one hand, that's kind of good,


because you're trying to cover both sides.


But it can happen that we look at the page and say,


oh, this is a transactional page.


And then your kind of informational intent


that you're also adding there is essentially being ignored.


So by having two separate pages, you


can kind of see that shift in intent over time.


So could it be a solution to have


some kind of compressed information on the category


page, so like a list of bullet points


with the most important advisories,


and to outsource the rest to another page, which


leads to the category page?


Sure.


I think that's good.


I mean, some people have completely separate pages.


Other sites have something like a blog set up


where they put this informational content


in the blog, and then they link to the category


pages or individual products.


However you want to combine that,


I think is generally fine.


OK, and this can be different for different keywords.


So we have other category pages where we have the same setup,


and there we don't have this problem at all.


Can it be that this problem arises only


for special kinds of keywords?


I don't think we would manually create lists


of keywords for these things.


It's something that our systems try to pick up automatically.


And it can happen that our systems pick it up


in one way on one set of pages and in a different way


on another set of pages.


And it can also happen that it shifts over time.


So that's something where I would


try to separate this out so that you have clear intents per


page, and that's something where I might try it with one kind


of page first and figure out what the optimal model is


for you, for your users, so that they can still


go from one part to the other.


And then think about what you want to do with the rest.


OK, thanks, John.


Sure.


All right, Kamal.


Oh, I think you're muted.


Hi, can you hear me?


Yes.


Question to the Christians.


I read a case study about the flow of descriptions


on a category of pages of e-commerce websites.


As you suggested, we shouldn't manipulate the system


about the intent of the page.


But one of the competitors in the market


used the same strategy with the keyword stuff.


And the indexed pages include the same products


but different texts.


But all of them are on the search results.


And in this case, how should we compete with them?


How can we compete with them?


For example, we wrote 500 words for that pages.


But as I read these case studies,


I decided that we should use them on blog posts


and create a link to the category pages.


But does it guarantee the result in that case?


Nothing is guaranteed.


So I think that that's kind of like the basis.


It is something where, like I mentioned with Christian,


it's sometimes tricky for our systems to figure out


what the intent is of the page.


And in some cases, it's a lot easier.


In some cases, it's a little bit harder.


So having some amount of information on a category page


is good.


But having it so that you have clear separate pages


for the different intents, I think,


makes it a lot easier for our systems


and makes it a lot easier for users as well.


If they want information, then they


land on an informational page.


And they don't have to think, oh, is this a store,


or is this, I don't know, something else?


And if after going through the informational content,


they feel they would like to buy something,


then they should have an easy way to get there.


So something like a clear and visible call


to action at the end or in between


or wherever you want to place that.


What if the Google recognizes page information,


but people still engage with products?


How do you mean?


For example, I see that the page is informational,


but I still engage with products and buy something.


And Google have the data that people engage with these pages.


In that case, I think that the page is worth


to see to rank on the top, right?


I don't know if that would always be the case.


I could imagine there are situations


where it makes sense to have that kind of a mixed


intent on a page.


But I wouldn't say that's the ideal situation.


What is the limit for the words that we


have to use on the dev pages?


We don't have any limits.


OK.


300, OK, I think.


There is no limit.


So I am just not going to say yes or no.


I think it's something where, especially with category pages,


you need to have some information on the page


so that we understand what the topic is.


But that's generally very little information.


And in many cases, we understand that from the products


that you have listed anyway.


If the names of the products are clear enough to us


to understand, oh, this is, I don't know, running shoes


or something, like Nike running shoes, Adidas running shoes,


different brands, whatever, then it's


clear that this is a list of running shoes.


You don't need to put in extra text there.


But sometimes product names are a little bit


hard to understand.


And then it might make sense to add some additional text


to give us some context there.


But it's usually additional context in the size of,


I don't know, maybe one or two or three sentences.


Can we use the same text on blog posts and the category pages?


Sure.


Yeah.


I mean, if you're talking about a very small amount of text,


then having that duplicated is absolutely no problem.


Usually on the blog post, you would have a lot more.


And if there is a handful of sentences that are the same,


that's totally fine.


So I can use one or two paragraphs from blog posts


on the category pages.


It's not a problem, yeah?


OK.


Thank you very much.


Cool.


Gaston.


Hi.


So I have two questions, but I'm only going to ask one.


So I'm working on a large website.


We, a couple of million pages, we


did a redirection between two languages,


and merging two Spanish languages, one into the other,


redirecting everything from one Spanish to the other.


So the migration is going well.


The traffic is moving from the second path.


Just to clarify, it's a redirection


between two subfolders, or everything


within the same domain.


The thing that I want to raise here


is we are not seeing any change in the coverage metrics


after almost three weeks of having done that redirection.


We are not seeing any change in the coverage metric,


not dropping the valid pages, not an increase


in excluded pages because of redirections,


or anything like that.


Should we be concerned about that?


So you're moving content from one subfolder


to a different subfolder on the same site?


We are merging two subfolders.


OK.


So we went from a site that had, let's say,


10 million pages to a site that has now 8 million pages.


I don't think there's a fixed timeline for those kind


of things to be visible.


One of the things that plays in there


is that we crawl pages in a different speed


across a website.


And some pages we will recrawl every day,


and other pages we will recrawl maybe once a month,


or every few months.


So if the content in these folders that you're merging


is content that is very rarely crawled,


then it's going to take a long time for that to be reflected.


Whereas if it's content that is very actively being crawled,


then you should see changes there within usually,


I don't know, a week or so.


So those are kind of the aspects that I


might take into account there.


Oh, yeah.


I'm aware of that.


But my thing is the traffic is going


to one part of the site to the other.


Everything's going well.


We are also seeing that in the log files


that Googlebot is crawling the direction well.


But we are not seeing it in the coverage metrics.


We are concerned that that might be either a reporting bug,


or that we should be waiting.


Oh, no.


Coverage metrics are updated once a month, possibly.


No, I think the index coverage report is updated maybe twice


a week.


I'm not 100% sure.


But a lot of the reports in Search Console


are once or twice a week.


So that might be something where it's just a delay.


But if you're seeing the traffic going to the right pages,


if you're looking at the performance report


and you're seeing that kind of a shift,


then I think that's perfectly fine.


I don't think you need to watch out for the index coverage


report for something like this.


Because usually what happens when you merge pages like this


is our systems first have to figure out


that we have to find a new canonical for these pages.


So you take two pages and you fold them into one.


Then we see this is a set of pages.


We have to pick a canonical.


And that process takes a little bit of time.


And then it takes a bit of time for that


to be reflected in the reporting.


Whereas if you do something like a clean site move,


then we can just transfer everything.


We don't have this canonicalization kind of process


that we have to figure out.


So I could imagine that it just takes longer


to be visible there.


Oh, perfect.


Yeah.


Cool.


All right.


Daniel.


Hey, John.


Hi.


Just a couple of questions.


You said quite a few times you can't just


work on a page or a set of pages.


That won't necessarily be enough to get them ranking,


getting them ranking well.


The rest of the website isn't doing well.


So my question is around, I suppose,


specifically the algorithms.


With new pages, much younger pages on the website,


when Google comes along and crawls it and looks


to understand it, does it then compare those pages


to older legacy pages on the site and say, OK, well, yeah,


these pages are great, but these much older pages


are actually rubbish.


That will then affect the quality of the newer pages


and the category pages?


Is that something that the algorithms do, I guess,


to really understand the quality of the website?


I guess in some sense that could be happening.


I mean, what usually happens is when


we try to understand the quality of a website overall,


it's just a process that takes a lot of time.


And it has, I don't know, a fairly long lead time there.


So if you add, I don't know, five pages to a website that


has 10,000 pages of pages, that's


a website that has 10,000 pages already,


then we're going to probably focus on most of the site


first, and then over time we'll see


how that kind of settles down with the new content


there as well.


So I guess that kind of goes in the direction


that you're asking.


SPEAKER 2


Yeah, makes sense.


My other question is around, I guess, backlinks.


So I guess Google isn't, if you get a backlink,


it's not just going to assume that it's a good quality


backlink and then therefore just pass link equity to the site


blindly.


So does Google, when it's crawling these backlinks,


does it either look at the referral traffic


and play that into the algorithm?


Or does it, if it doesn't see the information,


does it try to, I guess, assess whether there's a high


propensity to click on that link?


And so if there is a high propensity to click on that link,


then they will pass link equity.


Whereas if there isn't, then say you could just click it,


you could literally create a blog and link now.


In that situation, in that case, Google will say, well,


actually, there's no traffic.


There's not really a lot going on here.


So why should we pass any form of link equity?


So in terms of that, does that kind of


feed into whether or not link equity does


get passed onto a site?


I don't think so.


So we don't use things like traffic through a link


when trying to evaluate how a link should be valued.


We, as far as I know, we also don't look at things like


the probability that someone will click on a link


with regards to how we should value it.


Because sometimes links are essentially just references.


And it's not so much that we expect people to click


on every link on a page.


But if someone is referring to your site and saying,


I'm doing this because this expert here said to do that,


then people are not going to click on that link


and always look at your site and confirm whatever


is written there.


But they'll see it as almost like a reference.


If they needed to find out more information,


they could go there.


But they don't need to.


And from that point of view, I don't


think we would be taking that into account when


it comes to evaluating the value of the link.


Yeah.


So is it more on page factors then


when there are games that are reviewing that link


and whether or not you should pass on?


Are they assessing that website as a whole


and then saying yes or no, we should pass it on?


Or actually, we don't trust the site, so we won't?


A little bit.


I mean, some of that you will see


if you look into how page rank works.


It's a bit different.


I think nowadays how we handle that.


But essentially, the idea behind that is that we kind of


or in general with page rank, you


set up some value for the individual pages,


and then you pass a fraction of that value


on through the links there.


So essentially, if a page is seen as being very high value,


then the links from there will be


treated with a little bit more weight


compared to some random page on the internet.


And as far as I know, we don't do it exactly the same way


as things were in the beginning with regards to page rank.


But it's a good way of thinking about that.


OK, cool.


Yeah, I appreciate that.


Thanks, John.


Sure.


Cool.


OK, let me go through some of the submitted questions,


and then I'll get back to the folks that have


their hands raised here as well.


Don't worry.


We'll find time.


Let's see.


The first one I have is a domain site migration.


We did a site migration from one domain to a new one,


followed all migration requirements


and recommendations.


We updated redirects, canonical tags, and tested beforehand.


We added the new property, all of these things.


But we can't get the change of address to work.


It has a validation error saying that there


is a 301 redirect where it can't fetch the old domain.


How do we pass the validation for a change of address tool?


So I think, first of all, the most important thing


to keep in mind is that the change of address tool


is just one extra signal that we use with regards to migrations.


It's not a requirement.


So if, for whatever reason, you can't get the change of address


tool to work for your website, if you have the redirect set up


properly, all of those things, then you should be set.


It's not something that you absolutely need to do.


I imagine most sites, when they do moves,


they don't actually use this tool.


It's something more those who know about Search Console


and those who know about all of these fancy things,


they might be using it.


With regards to why it might be failing,


it's really hard to say without knowing your site's name


or the URLs that you're testing there.


One thing that I have seen is if you do something like if you


have a www version and a non-www version of your website


and you redirect step by step through that.


So for example, you redirect to the non-www version,


and then you redirect to the new domain.


Then that can happen.


That throws us off if you submit the change of address


in the version of the site that is not


kind of the primary version.


So that might be one thing to double check.


With regards to the change of address tool,


are you submitting the version that was currently indexed,


or are you submitting maybe the alternate version


in Search Console?


But otherwise, I'm not aware of any general issues


with that tool.


So if you want to send me your domain name or your site name,


I'm happy to double check.


Probably also just posting in the help forum


will also get you some feedback on what


you might be doing kind of differently than what


the tool would expect.


Can I add multiple schema types to one page?


If yes, what would be the best way


to combine both FAQ schema and recipe schema on one page?


You can put as much structured data on your page as you want.


But for most cases, when it comes to the rich results


that we show in search results, we


tend to pick just one kind of structured data


or one rich result type and just focus on that.


So if you have multiple types of structured data on your page,


then there's a very high chance that we just


pick one of these types and we show that.


So if you want any particular type


to be shown in the search results


and you see that there are no kind of combined


uses when you look at the search results otherwise,


then I would try to focus on the type that you want


and not just combine it with other things.


So ideally, pick one that you really want and focus on that.


Our Search Console Crawl Stats report


is showing a steady increase of 404 pages


that are not a part of our site.


They don't exist in our site map,


nor are they generated by internal search.


They appear to be Google searches that


are being appended to our URLs, and Google


is trying to crawl them.


Under the crawl response breakdown,


these 404s make up over 40% of the crawl response.


How do we make sure this doesn't negatively


affect our crawlability and indexability?


So I think, first of all, we don't make up URLs.


So it's not that we would take Google searches


and then make up URLs on your website.


My guess is that these are just random links


that we found on the web, maybe from some scraper site that


is scraping things in a bad way or something like that.


So that's something that happens all the time.


And we find these links, and then we crawl them.


We see that they return 404, and then we start ignoring them.


So in practice, this is not something


that you have to take care of.


If they're 404, if they don't exist, then that's fine.


That's the way it should be.


And usually, what happens with these kind of links


is we try to figure out overall for your website


which URLs we need to be crawling


and which URLs we need to be crawling at which frequency.


And then we take into account, after we've worked out


what we absolutely need to do, what we can do additionally.


And in that additional bucket, which is also, I think,


a graded set of URLs, essentially,


that would also include things like random links


from scraper sites, for example.


So if you're seeing that we're crawling


a lot of URLs on your site that come from these random links,


essentially, you can assume that we've already


finished with the crawling of the things


that we care about that we think your site is important for.


And we just have time and capacity on your server,


and we're just going to try other things as well.


So from that point of view, it's not


that these 404s would be causing issues


with the crawling of your website.


It's almost more a sign that, well, we have enough capacity


for your website.


And if you happen to have more content that you actually


linked within your website, we would probably crawl


and index that too.


So essentially, it's almost like a good sign.


And you definitely don't need to block these by robots.txt.


It's not something that you need to suppress.


It's something that's just super common on the web,


that sites link in a random way, or maybe they


have broken HTML, and then we end up discovering


a bunch of URLs like this.


We have a service website operating in France only,


and we have a lot of traffic coming


from other countries which have really bad bandwidth, which


causes our Core Web Vital scores to go down.


Since we're not operating outside of France,


we don't have any use for traffic outside of it.


Is it recommended to block traffic from other countries?


I would try to avoid blocking traffic from other countries.


I think it's something where, ultimately, it's up to you.


It's your website.


You can choose what you want to do,


but I would try to avoid doing that.


And in particular, in this case, one of the things


to keep in mind is that we crawl almost all websites from the US.


So if you're located in France and you


block all other countries, you would


be blocking Googlebot crawling as well,


and then essentially, we would not


be able to index any of your content.


So from that point of view, if you


want to block other countries, make sure that, at a minimum,


you're not blocking the country where


Googlebot is crawling from, at least if you care about search.


John, can I add something in this?


Similar question.


Actually, we have live TV page for our new channel,


which we are not providing in US.


But as you told, the site crawl in the US only.


So we provide information that this live TV is not


available in the US.


So US crawler crawled, and the Google results show.


If I type in Google, then this live TV


is not available in your location.


Even I search from India as well.


So in that case, can we do blocking techniques


for our live page?


So we show the India version of live TV for Google crawler,


but the user we show, the live TV not available text page.


So that it's an issue fixed automatically


to avoid this issue.


Based on our guidelines, you can't, or you shouldn't.


So our guidelines are pretty clear


that you should be showing Googlebot the same content


as other users from that location.


So if everyone else in the US is blocked,


you shouldn't be showing Googlebot the content.


So that's kind of, I think, the baseline situation.


There is, I think, now that you mention it, especially


with regards to news sites, one way that might work,


I don't know, is the use of the paywall structured data.


In that case, it's something where


you could show Googlebot the normal content.


And then if you have a paywall that's


required to access the content, you


would just need to mark up that content with the paywall


structured data.


And then users, if they have access,


they can log in on their side and actually get that content.


We can't provide even after the paywall.


Yeah, if you can't provide it even after the paywall,


then you wouldn't be able to provide it to Google.


Yeah, I think it's kind of an awkward situation.


And it's, I think, a little bit unfair towards people


who are not in the US or not in the location


where sites are being crawled.


Because the other way around is, of course, possible.


If you have a website that is based in the US


and you block India, then that wouldn't


be affecting the search results because we crawl from the US.


So I think it's a little bit unfair.


But from a technical point of view,


it's just how we have to deal with crawling.


We can't crawl from all countries.


And the policies, at least at the moment,


are such that you should treat Googlebot the same


as other users from that country.


It might be that at some point we change those policies.


But they've been like that for a very long time.


Even we can't redirect to different pages in the US


based on user event or based on country from the server end.


I mean, what you do essentially for users in the US


is essentially what we would use for indexing.


So another approach that I've seen


for other kinds of content is to provide


some level of information that is something


that you can provide in the US.


For example, I think I've seen this with maybe casino


websites.


I'm not sure.


Whereas sometimes the content is illegal in the US,


where they have a simplified version of the content, which


they can provide to the US, which


is more like descriptive information about the content.


So if you have movies that you can't provide in the US,


you can still serve the description


of the movie in the US.


You just can't serve the movie itself.


And that way, at least you have a basis of content


that it would be indexable and that could


be findable then in search.


SPEAKER 2


So earlier, I think I was maybe Gary or someone else


from Google.


But in some condition, you can use clocking.


So you can, in some condition, I don't


use that, but you can show it.


JOHN MUELLER Our policies are pretty clear in that regard.


It should really be what users see in that country.


And I mean, there's an aspect of you


might be willing to take a risk and say, well, I assume


the web spam team will not take action on my website


because I'm a legitimate business.


And if they check, they will see what I'm doing.


But that's something where you're essentially


breaking the guidelines and hoping that it comes out well.


And for normal businesses, I don't think


that's really a good idea.


And the other tricky part there is a lot of the teams


at Google that work on search, they are also based in the US.


So if someone in the US were to double check


what is happening on this website,


they also see it's blocked.


So it's kind of tricky.


I think this question also goes into the core web vitals aspect


there, where maybe you want to block countries


where connectivity is slow.


And from that point of view, I think, I mean, in this case,


blocking other countries would be a problem with regards


to search, first of all.


And with regards to core web vitals,


it's more something, well, if you


want to block other countries, you can do that.


I still don't think it's a good idea.


So I would try to avoid that, if at all possible.


SPEAKER 2


What are the orders for that?


Sounds good.


Cool.


OK, let me see.


Next question I have here.


Google recently regrouped together


30,000 pages on our site that are noticeably different pages


for core web vital scores.


This has brought the average LCP for these pages up


to 3.4 seconds, despite the fact that our product


pages were averaging 2.5 seconds before the rebooting.


We're working to get these pages at 2.5 seconds


below the threshold, but our tactics now


seem too insignificant to get us to the score we need to hit.


Is the grouping set and then a score average is taken,


or is the score taken and then the grouping is set?


This will help us establish if these product


pages under 2.5 seconds will help to solve the problem


or not.


So my understanding is with grouping, in general,


we don't have any clear or exact definition


of how we do grouping, because that's something


that has to evolve over time a little bit,


depending on the amount of data that we have for a website.


So if we have a lot of data for a lot of different kinds


of pages on a website, it's a lot easier for our systems


to say we will do grouping slightly more fine-grained


versus as rough as before.


Whereas if we don't have a lot of data,