Search Console Help Center

Right, like people will say like,


Search Console Help Center

oh, can we have clarification about what do you mean


Search Console Help Center

by this piece of data?


Search Console Help Center

Or can we provide more explanation


Search Console Help Center

about what this filter actually does


Search Console Help Center

or pulling this type of information up?


Search Console Help Center

Yeah, so like for example, in the HTTPS report,


Search Console Help Center

we did a lot of iterations with product experts


Search Console Help Center

or smaller groups of people using it.


Search Console Help Center

And they were always confused by this other bucket,


Search Console Help Center

which we kept having to rename and figure out


Search Console Help Center

like A, is the naming good for it?


Search Console Help Center

And B, can we be any more specific


Search Console Help Center

on what this really means?


Search Console Help Center

As in like just an error,


Search Console Help Center

it was an error bucket that was other,


Search Console Help Center

that was it's inherently confusing


Search Console Help Center

because it's actually reflecting data itself.


Search Console Help Center

That is, you know, we don't, even though users might think


Search Console Help Center

we can always provide ultra specific information


Search Console Help Center

about the search stack or what's going on,


Search Console Help Center

sometimes we inside don't even have


Search Console Help Center

that level of specificity.


Search Console Help Center

There's a lot of information we just don't have.


Search Console Help Center

And so we were bucketing this information in a larger group


Search Console Help Center

and it can be one of three different possible problems


Search Console Help Center

and users were frustrated by this


Search Console Help Center

and I totally understand that.


Search Console Help Center

So I have to provide labeling either A,


Search Console Help Center

can we split this off sometimes to be more specific?


Search Console Help Center

And B, provide real steps as to like,


Search Console Help Center

it's gonna be one of these things


Search Console Help Center

which are totally unrelated,


Search Console Help Center

but hopefully we think it's one of these things,


Search Console Help Center

what it is and what you can do to fix it.


Search Console Help Center

And hopefully people will not think


Search Console Help Center

that we're just sort of hand-waving


Search Console Help Center

or trying to be secretive, but like, you know,


Search Console Help Center

really this is like information that we don't know


Search Console Help Center

at the product level, like which of these things


Search Console Help Center

is going on.


Search Console Help Center

Totally.


Search Console Help Center

So definitely being specific in the feedback.


Search Console Help Center

I also have, I've set up filters for certain feedback


Search Console Help Center

so that I have a filter for high quality.


Search Console Help Center

So there's something that is behind the scenes,


Search Console Help Center

like looking for what it thinks is high quality,


Search Console Help Center

but I don't think it's very smart


Search Console Help Center

because sometimes it will like ignore a short line


Search Console Help Center

that's like a typo or something.


Search Console Help Center

It's like, okay, the filter thinks that that's low quality,


Search Console Help Center

but that's actually a bug that I'd want to see.


Search Console Help Center

So I have a filter set up to catch those kinds of keywords


Search Console Help Center

that are like typo or 404 or broken link,


Search Console Help Center

but sometimes the broken one will catch other things


Search Console Help Center

that people are like, I'm broken.


Search Console Help Center

Like, why are you writing into the feedback this,


Search Console Help Center

but like, okay, I feel bad, but I don't know why.


Search Console Help Center

Yeah, and sometimes we have product suggestions


Search Console Help Center

like whenever someone searches


Search Console Help Center

for the most beautiful girl in the world,


Search Console Help Center

search should return mirrors.


Search Console Help Center

Thank you for that suggestion.


Search Console Help Center

So kind of taking a step back from the feedback side,


Search Console Help Center

what was your most favorite documentation project


Search Console Help Center

that you've been working on?


Search Console Help Center

In Google or at Search Console?


Search Console Help Center

I guess in general.


Search Console Help Center

You know, at Google, it was kind of exciting


Search Console Help Center

to be the first person on the Android team.


Search Console Help Center

And I got to walk around with a test device,


Search Console Help Center

which I was told not to let anybody see.


Search Console Help Center

Oh, that's pretty cool.


Search Console Help Center

And yeah, you know, it was really cool.


Search Console Help Center

And I was sitting on a bus or subway in New York


Search Console Help Center

or something and the guy across the aisle from me,


Search Console Help Center

like his head turns like a robot and he looks at me


Search Console Help Center

and he looks at the device and he says,


Search Console Help Center

what phone is that?


Search Console Help Center

You know, and I had to put it in my pocket


Search Console Help Center

and sort of say, I don't know, I just don't know.


Search Console Help Center

I just got it from work and walk away.


Search Console Help Center

So that was pretty exciting.


Search Console Help Center

You know, it's funny because we had no idea


Search Console Help Center

that Android would be as big as it would be.


Search Console Help Center

You know, this was 2007, eight or something.


Search Console Help Center

Nobody really knew what phones would eventually become.


Search Console Help Center

That was pretty cool.


Search Console Help Center

There's something about documenting


Search Console Help Center

like a physical item as well,


Search Console Help Center

like hardware documentation compared


Search Console Help Center

to software documentation where you can actually interact


Search Console Help Center

with the device.


Search Console Help Center

I don't know if that's also what you were doing


Search Console Help Center

to sort of know how to use the phone


Search Console Help Center

and then write for that kind of thing,


Search Console Help Center

but you've got like a physical thing


Search Console Help Center

that you can interact with and then test.


Search Console Help Center

Yeah, yeah.


Search Console Help Center

And it's something that everybody uses


Search Console Help Center

and I would be using in my daily life, you know?


Search Console Help Center

And it's, so it was, yeah,


Search Console Help Center

it really was pretty interesting.


Search Console Help Center

Cool.


Search Console Help Center

So taking a step back to even further, I guess,


Search Console Help Center

like, wow, so many steps back,


Search Console Help Center

I'm gonna fall off my chair, right?


Search Console Help Center

Since all of this is around search and SEO,


Search Console Help Center

do you think about SEO a lot


Search Console Help Center

when you're writing these docs?


Search Console Help Center

Again, for me, not a lot because, you know,


Search Console Help Center

I think we're fairly focused in what we write.


Search Console Help Center

I'm not so much worried that somebody else


Search Console Help Center

is gonna be writing similar material about Search Console.


Search Console Help Center

And if they do and it's good information,


Search Console Help Center

I'm actually happy about that.


Search Console Help Center

You know, if somebody else can write the same stuff


Search Console Help Center

and cover it on their website, you know,


Search Console Help Center

we're not depending on ad revenue.


Search Console Help Center

So, you know, it's all okay.


Search Console Help Center

Second of all, like there's a limit to how,


Search Console Help Center

like, you know, we can't add meta tags to our help docs.


Search Console Help Center

We can't do a lot of stuff that, you know,


Search Console Help Center

if you're running your own website, you can.


Search Console Help Center

I'm using a general platform for the Help Center


Search Console Help Center

that's, you know, I have no access to writing a sitemap


Search Console Help Center

or robots.txt or anything like that.


Search Console Help Center

So my tools for SEO are only my wits, you know,


Search Console Help Center

it's like making sure that, you know,


Search Console Help Center

the content is as focused as it is, you know,


Search Console Help Center

I do think about titles for that


Search Console Help Center

and making sure that the titles are really clear,


Search Console Help Center

that the page covers what it covers.


Search Console Help Center

You know, I do use zippies and I don't know,


Search Console Help Center

I, you know, I think, is it true?


Search Console Help Center

Like zippies, we used to say, avoid zippies.


Search Console Help Center

What's the guidelines for zippies these days?


Search Console Help Center

It's okay?


Search Console Help Center

Or?


Search Console Help Center

I think it's kind of controversial.


Search Console Help Center

Maybe it's a personal preference.


Search Console Help Center

I am anti-zippy.


Search Console Help Center

Yeah.


Search Console Help Center

So I think in our, the DevSight's style guide,


Search Console Help Center

I think they have some guidance about like,


Search Console Help Center

don't put stuff in there that's like critical information


Search Console Help Center

because people are going to skip over it.


Search Console Help Center

And I think it also depends on the style of the zippy.


Search Console Help Center

Like if it's not intuitive that you can expand it


Search Console Help Center

because we've got feedback about that,


Search Console Help Center

that the symbol, it was like a plus icon


Search Console Help Center

and people didn't know that they could click that


Search Console Help Center

to expand it.


Search Console Help Center

So even that, and then varying across different regions,


Search Console Help Center

like that symbol might not be intuitive to users


Search Console Help Center

in other countries that like, this is a zippy,


Search Console Help Center

or like, I don't know, like,


Search Console Help Center

then you're hiding this like important information.


Search Console Help Center

Some other country, the, yeah,


Search Console Help Center

the dollar sign is used as an expansion.


Search Console Help Center

I don't know.


Search Console Help Center

Right.


Search Console Help Center

So I think like general guidance is like,


Search Console Help Center

why would you hide it if there's important information?


Search Console Help Center

And then you can't do like command find


Search Console Help Center

and like search on the page for that string.


Search Console Help Center

You have to like expand every zippy.


Search Console Help Center

So I have gotten to like them because,


Search Console Help Center

first of all, our docs can be quite long


Search Console Help Center

and the page size width is limited


Search Console Help Center

and which makes it even longer.


Search Console Help Center

And then you open up a help page and it's extremely long


Search Console Help Center

and you've lost people.


Search Console Help Center

So my feeling is the physically shorter I can make a page,


Search Console Help Center

it can really help people focus on what they need to do.


Search Console Help Center

The things I zip up tend to,


Search Console Help Center

I will only zip up things


Search Console Help Center

that includes procedural material if I can,


Search Console Help Center

so that like, they're not gonna be searching on like that,


Search Console Help Center

you know, the settings button.


Search Console Help Center

So what they will be searching on hopefully will be the,


Search Console Help Center

the title of the zippy expand.


Search Console Help Center

So I'll make the expansion title clear


Search Console Help Center

and then try not to overwhelm people


Search Console Help Center

with so much information on the page.


Search Console Help Center

That's why I use the zippy


Search Console Help Center

so that they can really step through and find exactly


Search Console Help Center

what they need on the page.


Search Console Help Center

Because the ugly thing about being a technical writer


Search Console Help Center

is that nobody wants to read anything that I've written.


Search Console Help Center

You know, they only read it because they have to.


Search Console Help Center

Yeah.


Search Console Help Center

So like, I, you know, people wanna see, read and get out.


Search Console Help Center

If I could put a button, fix this on the page,


Search Console Help Center

that's what they would want.


Search Console Help Center

Just fix the problem instead of reading it.


Search Console Help Center

Right, submit URL to Google, just paste in the URL.


Search Console Help Center

Like I don't wanna have to like interact with the product.


Search Console Help Center

I just wanna tell you, crawl my URL now and get out of here.


Search Console Help Center

Yeah, and so, I mean, the user's part of the bargain


Search Console Help Center

is that they have to spend the time


Search Console Help Center

to actually read this stuff.


Search Console Help Center

And the more you read the docs,


Search Console Help Center

the more you'll get out of it.


Search Console Help Center

And I totally understand when I'm like,


Search Console Help Center

I get into washing machine,


Search Console Help Center

I don't wanna sit down and read the whole user manual.


Search Console Help Center

It's really irritating.


Search Console Help Center

But you know, especially when you're talking about


Search Console Help Center

very subtle aspects of search and what's going on,


Search Console Help Center

there is no three-step answer.


Search Console Help Center

You can't make it happen by following three steps.


Search Console Help Center

You have to know what's going on under the hood,


Search Console Help Center

understand why this is happening.


Search Console Help Center

And the more you understand,


Search Console Help Center

the better you can affect your site and do something.


Search Console Help Center

And also sometimes the effect


Search Console Help Center

is not directly straightforward


Search Console Help Center

as to when you're doing something, why would this happen?


Search Console Help Center

the better it can help you debug your docs


Search Console Help Center

and figure out what's going on.


Search Console Help Center

So we have to have a background,


Search Console Help Center

this long background information and conceptual information.


Search Console Help Center

And when I can, I will put quick steps into,


Search Console Help Center

this is the problem and here's how you fix it.


Search Console Help Center

It's just not everything can fit that medium, unfortunately.


Search Console Help Center

And also sometimes it's like,


Search Console Help Center

when you get like with structured data,


Search Console Help Center

well, can't you just click the fix this issue?


Search Console Help Center

And like, yeah, if you control the webpage,


Search Console Help Center

we, this Google is just reflecting what's on the webpage.


Search Console Help Center

We can't fix your webpage.


Search Console Help Center

So unfortunately we can just tell you


Search Console Help Center

how you have to go in and fix it.


Search Console Help Center

And you have to be able to read it


Search Console Help Center

and be willing to take the time to fix it yourself.


Search Console Help Center

100%, couldn't agree more.


Search Console Help Center

Well, this has been super enlightening.


Search Console Help Center

I've learned a lot and I hope everyone else


Search Console Help Center

has enjoyed listening to this episode.


Search Console Help Center

Thank you, Josh, for coming to talk docs with us.


Search Console Help Center

I always like having another tech writer on the podcast.


Search Console Help Center

If people wanted to find you,


Search Console Help Center

could they find you out on the internet?


Search Console Help Center

Not so much.


Search Console Help Center

There's a lot of Josh Cohens out there.


Search Console Help Center

There's a soccer player named Josh Cohen.


Search Console Help Center

There's a guy who wrote a Broadway play called Josh Cohen.


Search Console Help Center

There's unfortunately someone who wrote


Search Console Help Center

a Pulitzer Prize winning book, which is not me.


Search Console Help Center

I tend to keep a low profile.


Search Console Help Center

I do write under the pseudonym of John Updike.


Search Console Help Center

So you may find me in your library.


Search Console Help Center

I've written a couple of books


Search Console Help Center

and short stories on there.


Search Console Help Center

But other than that,


Search Console Help Center

just look to me as your tireless anonymous


Search Console Help Center

search console documentation guy.


Search Console Help Center

Amazing.


Search Console Help Center

All right, and that's it for this episode.


Search Console Help Center

Catch you next time.


Search Console Help Center

We've been having fun with this podcast


Search Console Help Center

and I hope you, the listener,


Search Console Help Center

have found it both entertaining and insightful too.


Search Console Help Center

Feel free to drop us a note on Twitter


Search Console Help Center

at Google Search C or chat with us


Search Console Help Center

at one of the next events we go to


Search Console Help Center

if you have any thoughts.


Search Console Help Center

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


Search Console Help Center

Thank you and goodbye.


Search Console Help Center


English Google SEO office-hours from June 3, 2022

All right.


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


Office Hours Hangout.


Or I guess not Hangouts, just SEO Office Hours.


My name is John Mueller.


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


And part of what we do are these Office Hours sessions,


where people can submit questions,


and we will try to run through them.


So today is slightly different.


It's like I'm back in the office, which is kind of unique


and kind of, I don't know, makes everything


a little bit challenging because I have to figure out


all of the infrastructure.


So I hope everything goes well here.


I hope the audio and the video quality is OK.


We'll probably end up tweaking things over time a bit


to see what works well and what doesn't work so well.


So like the last couple of times,


I'm going through some of the questions that were submitted


and simplifying them a little bit where


necessary to try to focus on the core of the issues


and the core of the topics there so that we can kind of move


through them a little bit faster.


All right.


So the first question I have on my list


here is, it's theoretically possible to have two different


HTTP result codes on a page, but what will Google


do with those two codes?


Will Google even see them?


And if yes, what will Google do?


For example, a 503 plus a 302.


So I wasn't aware of this, but of course,


with the HTTP result codes, you can include


lots of different things.


Google will look at the first HTTP result code


and essentially process that.


And you can theoretically still have two HTTP result codes


or more there if they are redirects


leading to some final page.


So for example, you could have a redirect from one page


to another page.


That's one result code.


And then on that other page, you could serve a different result


code.


So that could be a 301 redirect to a 404 page,


which is kind of an example that happens every now and then.


And from our point of view, in those kind of chain situations


where we can follow the redirect to get a final result,


we will essentially just focus on that final result.


And if that final result has content,


then that's something we might be able to use for canonicalization.


If that final result is an error page, then it's an error page.


And that's fine for us too.


Does putting a website behind a CDN improve ranking?


We get the majority of our traffic


from a specific country.


We hosted our website on a server located in that country.


Do you suggest putting our entire website behind a CDN


to improve page speed for users globally?


Or is that not required in our case?


So obviously, you can do a lot of these things.


I don't think it would have a big effect on Google


at all with regards to SEO.


The only effect where I could imagine that something might


happen is what users end up seeing.


And kind of what you mentioned, if the majority of your users


are already seeing a very fast website because your server is


located there, then you're kind of doing the right thing.


But of course, if users in other locations


are seeing a very slow result because perhaps


the connection to your country is not that great,


then that's something where you might have some opportunities


to improve that.


And you could see that as something


in terms of an opportunity in the sense that, of course,


if your website is really slow for other users,


then it's going to be rare for them


to start going to your website more because it's really


annoying to get there.


Whereas if your website is pretty fast for other users,


then at least they have an opportunity


to see a reasonably fast website, which


could be your website.


So from that point of view, if there's


something that you can do to improve things globally


for your website, I think that's a good idea.


I don't think it's critical.


It's not something that matters in terms of SEO


in that Google has to see it very quickly as well


or anything like that.


But it is something that you can do to kind of grow your website


past just your current country.


Maybe one thing I should clarify,


if Google's crawling is really, really slow, then of course,


that can affect how much we can crawl and index


from the website.


So that could be an aspect to look into.


The majority of websites that I've looked at,


I haven't really seen this as being a problem with regards


to any website that isn't millions


and millions of pages large.


So from that point of view, you can double


check how fast Google is crawling in Search Console.


And the crawl stats, if that looks reasonable,


even if that's not super fast, then I


wouldn't really worry about that.


OK, next question I have here from Vincent.


Our site is a livestream shopping platform.


Our site currently spends about 20% of the crawl budget


on the API subdomain, another 20%


on image thumbnails of videos.


Neither of these subdomains have content which


are part of our SEO strategy.


Should we disallow these subdomains from crawling?


Or how are the API endpoints discovered or used?


So maybe the last question there first.


In many cases, API endpoints end up


being used by JavaScript on a website.


And we will render your pages.


And if they access an API that is on your website,


then we'll try to load the content from that API


and use that for rendering of the page.


And depending on how your API is set up


and how your JavaScript is set up,


it might be that it's hard for us to cache those API results,


which means that maybe we crawl a lot of these API requests


to try to get a rendered version of your pages


so that we can use those for indexing.


So that's usually the place where this is discovered.


And that's something you can help by making sure


that the API results can also be cached well,


that you don't inject any timestamps into URLs,


for example, when you're using JavaScript for the API,


all of those things there.


If you don't care about the content that's returned


with these API endpoints, then of course,


you can block this whole subdomain


from being crawled with the robots.txt file.


And that will essentially block all of those API requests


from happening.


So that's something where you kind of first of all


need to figure out, are these API results actually


part of the primary content or important critical content


that I want to have indexed from Google?


And if so, then probably you should not block crawling.


But if this is something where it's essentially


generating something that is almost secondary to your pages


or anything that's not critical for your pages themselves,


then it might be worthwhile to double check


what it looks like when they're blocked.


And one way you could double check this


is if you could create a separate test page that


doesn't call the API or that uses a broken


URL for the API endpoint.


And by that, you can see how does this page actually


render in my browser?


How does it render for Google?


So those are kind of the things that I would look at there.


Cool.


OK.


Is it appropriate to use the nofollow attribute


on internal links to avoid unnecessary crawl requests


to URLs which we don't wish to be crawled or indexed?


So obviously, you can do this.


It's something where I think for the most part,


it makes very little sense to use nofollow on internal links.


But if that's something that you want to do, go for it.


In most cases, I would try to do something


like using the rel canonical to point at URLs


that you do want to have indexed or using the robots


text for things that you really don't want to have crawled.


So try to figure out is it more like a subtle thing


that you have something that you prefer to have indexed


and then use rel canonical for that?


Or is it something where you say, actually,


when Googlebot accesses these URLs,


it causes problems for my server?


It causes a large load.


It makes everything really slow.


It's expensive or what have you.


And for those cases, I would just


disallow crawling of those URLs and try


to keep it kind of on a basic level there.


And with the rel canonical, obviously, we'll


first have to crawl that page to see the rel canonical.


But over time, we will focus on the canonical


that you've defined.


And we'll use that one primarily for crawling and indexing.


OK, here's another question.


Why don't the search results of a site query,


which returns of about so many giant number of results,


match what Search Console in the index data


has for the same domain?


Yeah, so this is a question that comes up every now and then.


I think we've done a video on it separately as well.


So I would double check that out.


I think we've talked about this a long time already.


Essentially, what happens there is


that there are slightly different optimizations


that we do for site queries in terms of we


just want to give you a number as quickly as possible.


And that can be a very rough approximation.


And that's something where when you do a site query,


that's usually not something that the average user does.


So we'll try to give you a result as quickly as possible.


And sometimes that can be off.


If you want a more exact number of the URLs


that are actually indexed for your website,


I would definitely use Search Console.


That's really the place where we give you


the numbers as directly as possible,


as clearly as possible.


And those numbers will also fluctuate a little bit


over time.


They can fluctuate depending on the data center sometimes.


They go up and down a little bit as we crawl new things.


And we have to figure out which ones do we


keep, all of those things.


But overall, the number in Search Console for,


I think, the indexing report, that's really the number


of URLs that we have indexed for your website.


I would not use the of about number for any diagnostics


purposes in the search results.


It's really meant as a very, very rough approximation.


OK, now a question about redirects, again,


about the differences between JavaScript versus 301 HTTP


status code redirects.


And which one would I suggest for short links?


So in general, when it comes to redirects,


if there is a server-side redirect where you can give us


a result code as quickly as possible,


that is strongly preferred.


The reason that is strongly preferred


is just that it can be processed immediately.


So any request that goes to your server to one of those URLs,


we'll see that redirect URL.


We will see the link to the new location.


We can follow that right away.


Whereas if you use JavaScript to generate a redirect,


then we first have to render the JavaScript


and see what the JavaScript does.


And then we'll see, oh, there's actually a redirect here.


And then we'll go off and follow that.


So if at all possible, I would recommend


using a server-side redirect for any kind of redirect


that you're doing on your website.


If you can't do a server-side redirect,


then sometimes you have to make do.


And a JavaScript redirect will also get processed.


It just takes a little bit longer.


The meta refresh type redirect is another option


that you can use.


It also takes a little bit longer


because we kind of have to figure that out on the page.


But server-side redirects are great.


And there are different server-side redirect types.


So there's 301 and 302.


And I think, what is it, 306?


There's 307 and 308, something along those lines.


Essentially, the differences there


are whether or not it's a permanent redirect


or a temporary redirect.


A permanent redirect tells us that we


should focus on the destination page.


A temporary redirect tells us we should


focus on the current page that is redirecting and kind


of keep going back to that one.


And the difference between kind of the 301, 302, and the 307,


and I forgot what the other one was,


is more of a kind of a technical difference with regards


to the different request types.


So if you enter a URL in your browser,


then you do what's called a GET request for that URL.


Whereas if you send something to a form


or use specific types of API requests,


then that can be a POST request.


And the 301, 302 type redirects, they


would only redirect the normal browser requests


and not the forms and the API requests.


So if you have an API on your website that uses POST requests


or if you have forms where you suspect someone might be


submitting something to a URL that you're redirecting them,


then obviously you would use the other types.


But for the most part, it's usually 301 or 302.


And the differences there are very minimal.


I have a website for games.


After a certain time, a game might shut down.


Should we delete non-existing games


or keep them in an archive?


What's the best option so that we don't get any penalty?


We want to keep information of the game


like videos, screenshots, et cetera.


So essentially, this is totally up to you.


It's something where you can remove the content


of old things if you want to.


You can move them to an archive section.


You can make those old pages noindex


so that people can still go there when


they're visiting your website.


There's kind of lots of different variations there.


The main thing that probably you will


want to do if you want to keep that content


is move it into an archive section, like you mentioned.


The idea behind an archive section


is that it tends to be less directly


visible within your website.


That means it's easy for us and for users


to recognize this is the primary content, like the current games


or current content that you have.


And over here is an archive section where you can go in


and you can kind of dig for the old things.


And the effect there is that it's a lot easier for us


to focus on your current live content


and to recognize that this archive section, which


is kind of separated out, is more something


that we can go off and index.


But it's not really what you want to be found for.


So that's kind of the main thing I would focus on there.


And then whether or not you make the archive content noindex


after a certain time or for other reasons,


that's totally up to you.


Is there any strategy by which desired pages can


appear as a site link in Google search results?


So site links are the additional results


that are sometimes shown below a search result, where it's


usually just a one-line link to a different part


of the website.


And there is no meta tag or structured data


that you can use to kind of enforce a site link to be shown.


And it's a lot more that our systems try to figure out


what is actually kind of related or relevant for users


when they're looking at this one web page as well.


And for that, our recommendation is essentially


to have a good website structure,


to have clear internal links so that it's easy for us


to recognize which pages are related to those pages,


and to have clear titles that we can use and kind of show


as a site link.


And with that, it's not that there's a guarantee that any


of this will be shown like that, but it kind of


helps us to figure out what is related.


And if we do think it makes sense to show a site link,


then it'll be a lot easier for us to actually choose one


based on that information.


Let's see, more technical one here.


Our website uses iframes and a script


to embed PDF files onto our pages in our website.


Is there any advantage to taking the OCR text of the PDF


and pasting it somewhere into the document's HTML


for SEO purposes, or will Google simply


parse the PDF contents with the same weight and relevance


to the index of content?


So I'm just momentarily kind of thrown off


because it sounds like you want to take the text of the PDF


and just kind of hide it in the HTML for SEO purposes.


And that's something I would definitely not recommend doing.


If you want to have the content indexable,


then make it visible on the page.


So that's kind of like the first thing there that I would say.


With regards to PDFs, we do try to take the text out


of the PDFs and index that for the PDFs themselves.


From a practical point of view, what happens with a PDF


is, as one of the first steps, we convert it into an HTML page


and we try to index that like an HTML page.


So essentially, what you're doing


is you're kind of like iframing an indirect HTML page.


And when it comes to iframes, we can


take that content into account for indexing


within the primary page.


But it can also happen that we index the PDF separately


anyway.


So from that point of view, it's really hard


to say exactly kind of like what will happen.


I would turn the question around and kind of frame it as,


what do you want to have happen?


And if you want your normal web pages


to be indexed with the content of the PDF file,


then make it so that that content is immediately


visible on the HTML page.


So instead of embedding the PDF as a primary piece of content,


make the HTML content the primary piece


and a link to the PDF file.


And then there is a question of, do you


want those PDFs indexed separately or not?


Sometimes you do want to have PDFs indexed separately.


And if you do want to have them indexed separately,


then linking to them is great.


If you don't want to have them indexed separately,


then using robots.txt to block their indexing is also fine.


You can also use the noindex.xrobots HTTP header.


It's a little bit more complicated because you


have to serve that as a header for the PDF files


if you want to have those PDF files kind of like available


in the iframe but not actually indexed.


Let's see.


I don't know.


Timing, we'll have to figure out how long we make these.


We want to mask links to external websites


to prevent passing of our link juice.


We think the PRG approach is a possible solution.


What do you think?


Is the solution overkill, or is there a simpler solution


out here?


So the PRG pattern is a complicated way


of essentially doing a POST request to the server, which


then redirects somewhere else to the external content.


So Googlebot will never find that link.


From my point of view, this is super overkill.


There's absolutely no reason to do this unless there's really


like a technical reason that you absolutely need


to block crawling of those URLs.


I would either just link to those pages normally


or use the rel nofollow to link to those pages.


There's absolutely no reason to kind of go


through this weird POST redirect kind of pattern there.


It just causes a lot of server overhead.


It makes it really hard to cache kind of like that request


and take users to the right place.


So I would just use a nofollow on those links


if you don't want to have them followed.


The other thing is, of course, it's


like just blocking all of your external links.


That rarely makes any sense.


Instead, I would make sure that you're kind of like taking part


in the web as it is, which means that you link to other sites


naturally.


They link to you naturally, kind of like taking


part of the normal part of the web


and not trying to keep Googlebot locked


in to your specific website.


Because I don't think that really makes any sense.


Let me see.


For Google, it doesn't matter if our website


is powered by WordPress, WooCommerce, or Shopify,


or any other service.


A lot of marketing agencies suggest


using specific platforms because it helps with SEO.


Is that true?


That's absolutely not true.


So there is absolutely nothing in our systems,


at least as far as I'm aware of, that


would give any kind of preferential treatment


to any specific platform.


And with pretty much all of these platforms,


you can structure your pages, structure your website


however you want.


And with that, we will look at the website as we find it


there.


We will look at the content that you present,


the way the content is presented,


the way things are linked internally,


and we will process that like any HTML page.


As far as I know, our systems don't even


kind of react to the underlying structure of kind


of like the back end of your website


and do anything special with that.


So from that point of view, it might


be that certain agencies have a lot of experience with one


of these platforms, and they can help you to make really good


websites with that platform, which is perfectly legitimate


and could be a good reason to say,


like, I will go with this platform or not.


But it's not the case that any particular platform has


an inherent advantage when it comes to SEO.


You can, with pretty much all of these platforms,


make reasonable websites.


They can all be appearing well in search as well.


Let me see.


Does Google crawl URLs located in structured data markup,


or does Google just store the data?


So for the most part, when we look at HTML pages,


if we see something that looks like a link,


we might go off and kind of like try that URL out as well.


That's something where if we find a URL in JavaScript,


we can try to pick that up and try to use it.


If we find a link in kind of a text file on a site,


we can try to crawl that and use it.


But it's not really a normal link.


So it's something where I would recommend


if you want Google to go off and crawl that URL,


make sure that there's an actual HTML link to that URL


with a clear anchor text as well that you give some information


about the destination page.


If you don't want Google to crawl that specific URL,


then maybe block it with robots.txt, or on that page,


use a rel canonical pointing to your preferred version,


anything like that.


So those are kind of the directions I would go there.


I would not blindly assume that just because it's


in structured data, it will not be found.


Nor would I blindly assume that just because it's


in structured data, it will be found.


It might be found.


It might not be found.


I would instead focus on what you want to have happen there.


If you want to have it seen as a link, then make it a link.


If you don't want to have it crawled or indexed,


then block crawling or indexing.


That's all totally up to you.


Cool.


All right.


And with that, I think we're pretty much


at the end of this session.


Thank you all for the submissions


on the YouTube page.


I'll put up the next Office Hours section probably not


next week, or maybe the week afterwards.


We'll kind of have to see how that goes.


But watch out for that.


In the meantime, if you have any questions,


feel free, of course, to jump by our Search Central Help Forum.


There are lots of fantastic product experts


there who can help you and try to find out a little bit more


about maybe some questions or issues


that you're running into.


And of course, you can also contact us


on Twitter or social media in general as well.


So with that, thank you for watching.


I hope you found this useful and insightful.


And maybe we'll see each other again


in one of the future episodes.


English Google Webmaster Central office-hours from June 9, 2020

All right, welcome, everyone, to today's Webmaster Central


Office Hours Hangout.


My name is John Miller.


I am a Webmaster Trends Analyst at Google in Switzerland.


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


where people can jump in and ask any question


around their website and web search.


Bunch of things were submitted already,


but maybe we can get started with some view-all,


if there's anything from your side that you'd like to add.


Could we start with some indexing?


It seems like a lot of people are


complaining about indexing issues for the past couple


weeks or months.


This is a new thing where Google is like, you know what?


We're not going to go ahead and index as many pages as we used


to, because we're going to look at quality and say, all right,


if the site's not a certain quality threshold,


we're not going to index as many pages.


Is this anything to do with that?


I don't think there's anything really new in that regard.


But what has kind of changed over, I guess,


maybe the last half year or even longer


is that we show this information a little bit more visibly


in Search Console.


So it's not so much that we're changing how we do indexing,


how we select the pages that we use for indexing or crawling.


It's more that in Search Console, we'll tell you,


we've seen these URLs, but we decided not to index them.


And then people take that information.


They're like, oh, I must be doing something wrong.


Therefore, I need to fix something.


Or maybe Google is broken or something like that,


because it's flagging me all of these pages.


But it's something that I think, at least as far as I know,


has been the case at Google since the beginning,


in that we just can't index the whole web.


There are so many things happening across the whole web


that we can't possibly keep up with everything all the time.


So we have to make decisions along the way


and figure out which pages we really


need to have crawled and indexed and maybe which pages.


It's like, well, it's interesting


that you wrote this, but at the moment, we don't really


know what we should do with this information.


So maybe we should just not index it at the moment.


Yeah.


And I think that's kind of tricky,


because on the one hand, when I talk to Search Console,


the Search Console folks, we tell them


that this confuses people.


And they feel they need to fix something,


because we're flagging it as something not being indexed.


But at the same time, it's also the kind of information


we want to give people, where we essentially want to tell them,


hey, we noticed you put this stuff out,


but we decided not to index it.


We don't really have a human readable reason for why


we decided not to index it.


But we still want to give people the information that we


understand your site is this big,


but we're just picking up a small part for indexing


at the moment.


OK, so just to be clear, it's a reporting thing possibly


that has changed in the past several months,


but not anything new with how Google determines what


to index or anything like that.


Yeah, yeah.


I mean, it's something that happens


with crawling all the time.


Essentially, you see it as an SEO.


If you're looking at your server logs,


you notice it there probably first,


where you realize you put out 100,000 pages,


and Google is crawling 20,000 of them.


And essentially, we might know about these 100,000 pages,


because they're in the sitemap file,


but we're just crawling a small part of them.


So therefore, we can only really index that small part


of your site.


And as you improve the quality of your website,


as you improve things around your website,


maybe improve some technical details,


then that number of the URLs that we crawl,


that tends to go up.


And from my point of view, that's


been the case since, I don't know, since the beginning.


I think in Gary's crawl budget blog post,


he also touched upon this, the crawl demand,


how much we want to crawl from your website.


And that also changes over time.


And if we don't want to crawl a lot of stuff from your website,


then essentially, we're not going


to be able to index all of that.


Thank you.


OK.


SPEAKER 2


John, I have a question about the core Web Vitals


and some of the tools you guys have with them.


So I'm looking at some of the sites,


and I'm looking at the PageSpeed Insights tool.


I'm looking at Search Console, and then I'm


also using the extension in the browser.


And I find that Search Console and PageSpeed Insights


seem to line up pretty well, but the extension


seems to be way off, or at least different.


Is that because the extension is using my network,


and the other tools are using a combination of things?


And then I guess if that's the case,


which would be the source of truth for ranking


at the end of the day?


Yeah.


So I don't know offhand how the extension works,


but my understanding is it does use your current data.


That is kind of like what you're seeing in your browser.


And with regards to a lot of these speed metrics,


we kind of differentiate between lab data and data


that we collect from users through the Chrome User


Experience Report.


I think it's like real user metrics or some word


that they use for that.


And essentially, what we see is that for all kinds of data


like this, it's more of a prediction of what


we expect to see when a new user comes to your site.


And that's kind of based on what we've seen in the past, what


we would see if we tested it kind of in more of a lab


environment, which could be kind of like on your computer.


It could be something.


Maybe it's running on a server at webpagetest.org


if you use their tests, for example.


And essentially, all of these tools


are kind of approximations of what the average user might


see.


I recommend using kind of the lab data in situations


where you're testing things, where you're trying things out,


because that's where you see essentially


the immediate effect.


You change something on your website,


you run the test again in your browser, you see a new score.


And over time, if that's something


that you publish on your website,


if other people can see it as well,


then that will affect kind of the field data


as well over time.


I don't know what the time frame is with regards to the Chrome


User Experience Report.


I'm just throwing a number out there.


I'm guessing maybe it's aggregated over a month


or something like that.


So that's something where over the course


of this period of time, that data needs to be collected.


And then you'll see the changes that you see kind of


on your side.


And sometimes the lab tests don't align completely


with what users would see.


Like if you have the server right next to you,


and it's like, obviously, your network collection


is going to be perfect.


But the average user has to go through the internet,


and maybe your server is in some faraway place


for the average user.


So their network connection will always be slow.


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


With regards to what we would use for search,


we would essentially align it with the data


that we show in Search Console, which


is kind of based on the field data that people actually see.


OK, good.


So the field data in Search Console.


So Search Console uses the source of truth for ranking,


and Search Console is closely related to field data


that you use.


OK.


Yeah.


Thank you.


Just one brief note.


I need to drop out maybe 10, 12 minutes early to join


something else afterwards.


But I'll run through some of the questions that were submitted.


And if you all have any questions along the way,


feel free to jump in.


I'll see if I can get through them a little bit faster


than usual.


Maybe we can go through.


For an e-commerce site, we want to implement a login area.


So either use a new page or embed the login


with an iframe.


What option should you use?


Do I need to block it in robots.txt?


Essentially, search doesn't care.


You can do whatever you want there.


Blocking it in robots.txt is also fine.


Essentially, if someone would be searching


for your site closed login, they might


come to this roboted page in the search results.


But essentially, that would lead to your site anyway.


So that's perfectly fine.


Then there's a question about discovered currently not


indexed.


I think we talked about that briefly already.


Review websites could have many low-quality pages, thin content,


poor site structure.


Most reviews won't rank or even get indexed,


which isn't a problem.


But could this hurt other high-quality pages


on the same site?


Should we use rel ugc to tag the on-page content like this?


So in general, you don't need to flag user-generated content.


But if you're publishing user-generated content


on your site, that's essentially what we


think your site is publishing.


So just because it originated from some user,


if that's what you publish on your website,


we think that's the content that you'd


like to have shown, which is kind of the case.


So if you think this user-generated content


is low-quality or even bad content,


then it's kind of up to you with regards to whether or not


you want to publish it.


So that's something where I generally


recommend trying to evaluate the quality of the user-generated


content on your website and making sure


that what you publish aligns with what you want


to have your site known for.


A question about, I guess, HTML.


The lead paragraph of our articles is inside a div.


P is more correct.


If we're speaking about HTML5, what about Googlebot?


Does it care about div or p's?


We essentially don't care.


Totally up to you.


I don't know what the kind of semantically perfect variation


would be in this case.


But from Google's side, for indexing,


we treat them the same.


We have a news website, 200 articles every day.


There are two options.


All links for all the time are stored in a sitemap,


hundreds of thousands of links.


Or only the 1,000 last links are stored in a sitemap.


So any benefit to using a second variant versus the first.


So essentially, these kind of map


directly to news sitemaps and general sitemaps


that we have.


With general sitemaps, we recommend


including all of your pages in the sitemap file.


With news sitemaps, it's limited,


I think, to the last 1,000 pages.


News sitemaps are specifically meant for Google News,


but you can use news sitemaps for essentially any kind


of website if you want.


Or you can alternately just create an extra sitemap


with just 1,000 links in it and submit that individually.


So I think both of these options are fine.


In general, I do recommend including all of your URLs


in a sitemap file somewhere just so


that you have full coverage in Search Console in the reporting.


For websites that rely heavily on UGC


to create millions of pages of Q&A, like Quora,


what's the best way to structure them so that the crawl


budget is used efficiently without having to remove pages?


I think there is essentially no difference with regards


to where your content comes from when it comes to crawl budget


or kind of the internal crawling and indexing of a website.


Essentially, you want to create a structure of a website


where it's easy for us to crawl and find


your most important pages as quickly as possible.


And where we can somehow reach all


of the content on your website, at least all of the content


that you want to have indexed.


And that's independent of the source of the content.


If that's something where you're writing all of these articles


yourselves, if you have a team of writers creating content,


if it's created by users, it essentially doesn't matter.


I'm doing a 301 redirect from subdirectory on my site


to subdirectory on a new domain once they're redirected.


I will be displaying a pop-up to inform users


that they have been redirected to this new page.


Once they read it, they can click Continue to move on.


Would that affect anything?


So usually, the way to implement something like this


would be to check the HTTP refer that you get.


When a user clicks on a link and goes to a new site,


you can pass that refer along.


And that way, you can recognize on the new site


that the user came from clicking a link on the old site,


for example.


For Google, when we crawl and index the web,


we don't send the refer at all.


Even if we follow a redirect, even


if we follow a link on a page somewhere,


we essentially don't forward a refer at all.


So we would never see this kind of extra pop-up there.


So in that regard, this would be essentially something


that wouldn't affect search at all.


Can image quality on my content page


affect the overall page quality rank?


If yes, then what aspects of quality


matter, the resolution, camera, sharpness, et cetera?


So my understanding is that the quality of the images


doesn't affect the ranking in normal web search,


but it can affect how these images appear in Google Images.


So specifically for Google Images,


we do try to recognize high-quality images.


And we do try to show those appropriately in the search


results in Google Images.


So that's something where if you care about traffic from image


search, if you see that your users are searching


in kind of a visual way with Google Images,


then obviously you'd want to improve


the quality of your images.


I mean, that's kind of, I'd say, the logical conclusion anyway.


If you want people to search visually


and you want to present your site in a visual way,


then you need to make sure that that presentation is


as good as possible so that people click through


to your site.


With regards to just pure web search,


that's not something that we would directly


care about indirectly.


I don't know, maybe if users come to a page


and they think this is a really bad page because the images


on the page are really bad, then maybe they won't recommend it.


But that's more of an indirect effect and more something


between you and your users.


Why is it so that my website ranking keeps decreasing


until last March, even though I didn't build any link


for the past three years of my site?


Now when I built some links in April,


the traffic went up only to crash by 80% in the May update.


Why is that so?


Whether or not I build links, I get hit by the update.


It's really hard to say without looking at your website.


In general, I suspect the kind of link building


that you're doing there doesn't really


affect the way that Google shows your website in search.


So probably what you're seeing in this case


is kind of the natural changes in the algorithms over time.


But that said, I really don't know


what exactly you've been doing with your website,


what your website is, what it's about,


what kind of links you've been building to the website there.


It's really hard to say.


My general recommendation here would


be to get more feedback from peers.


And the best way to do that is maybe


to go to either our Webmaster Help Forum


or some other forum for webmasters


and explicitly mention your site's URLs and the queries


that you're looking at so that other people can take a look


at your site and give you some tips on what


you could be doing differently.


SPEAKER 2


When we're showing which pages are most important on our site,


you said it's really more about our internal structure.


Did you mean it's more about the way


we have internal links going on the site, placement of pages


on the home page, let's say?


Or is it more about this proportion of the content


that's about bananas versus about other topics?


Does that also play a factor?


I think there are multiple things that kind of play


into that.


I guess where usually I start is things around internal linking


with regards to the anchor text that you use internally,


how you refer to your other pieces of content.


And with regards to how visibly they're referred to.


So for example, if you have a page about a specific topic


and that's only linked way down in your site's architecture,


then for us, we probably assume this page is not that critical.


Whereas if you have that same page linked


with an important anchor text from your home page,


then generally, because we assume your home page is


probably an important part of your website,


then that's going to make that page much more important


within the structure of your website.


So that's kind of how you would structure your website


a little bit to make it clear to us


which parts of your website you think


are particularly important.


OK, and so even if we're writing a lot about strawberries


and oranges and stuff, the ratio of that content


to the bananas content doesn't really play a factor.


It's just more about the linking and the anchor text.


Yeah, I mean, specifically with regards to things


internally within your website.


I think it's always tricky with regards


to the amount of content that you have


and how visible that content is within your website,


because it's very easy to be kind of in a situation


where you create a lot of content,


but within your website, you're positioning it


in a way that it's more secondary.


So just by absolute counts, you might have,


I don't know, a lot of terms and condition pages,


but your website is not about kind of legal topics,


but rather you're selling something specific.


So just the absolute number of pages on a specific topic


that you have, that's kind of secondary to how important you


frame them within your website.


OK, perfect.


Thank you.


Sure.


Let's see.


I've been working really hard on a particular website


with content and SEO.


My website is now returning good position in the search engine.


Do I now stop altering the content and the SEO,


or will I have to keep updating it as I may lose rankings,


or do I just leave it as it is kind of as it was built up now?


Yeah, I think in general, there is always


a temptation to kind of let things be once they work well,


but the web is evolving so quickly


so that if you don't stay on top of things,


it's very easy to kind of end up in a state


where your website has been doing well


for a number of years, but suddenly the rest of the world


moves on and your website becomes less relevant.


And it's not so much that you've been doing something wrong


for a number of years.


It's just that things have evolved since then.


So with that in mind, I would not just


stop when you're in a good position,


but kind of keep working at it and keep


trying to optimize things, try to recognize trends ahead


of time before other people kind of jump on them,


and keep evolving your website to make sure that it


remains relevant over time.


And that's sometimes easier said than done,


but I think the hard work is kind of getting


into that position first.


So you're probably in a good spot to keep that momentum up.


After the May core update, the home page of my website


jumped from the seventh position to the first


and stayed there up until you announced the new core web


vitals.


In a position of a few days afterwards,


my website dropped to the fourth position.


My home page is poorly optimized for speed,


and top three websites right now have worse content,


but better optimization.


So I guess the question is, did I get penalized for core web


vitals?


So the short answer is no.


We have not announced a date when


we're going to start using the core web


vitals as a ranking factor.


So this is not yet in place.


We decided to announce it early on, just so that these metrics


are out there as early as possible,


that people understand which direction we're headed.


But we also said that we would, I think,


give a heads-up time of something like a half a year


before we would start using them in search as a ranking factor.


So that's something where we announced these.


But if you're seeing a change on the date of the announcement,


that would not be related to that announcement at all.


That's something where maybe other ranking changes happen,


maybe other things in the web that you're active in


have changed.


So speed is still important.


It's still something you should focus on,


but it's probably not the reason why your website dropped.


Can you talk a bit about Discover?


My page suddenly started getting traffic from the source.


And just like that, it stopped again in a few months.


I don't have anything really specific to add about Discover.


I think we have a Help Center page about Discover,


which goes into a little bit of what happens in Discover.


But essentially, it's something where


you need to understand your audience well and create


content that works well for your audience,


that they really appreciate, that makes sense for us


to show in this proactive stream where they get content that


might be interesting to them.


As far as I know, there are no technical requirements


that you need to be in a specific format for being


visible in Discover.


There's no meta tags you need to use other than, of course,


making sure that you're not blocking crawling and indexing.


With regards to the previews in Discover,


I believe if you're using AMP by default,


you have the or you can have a bigger image preview.


You can also use the meta tags to select


that you would like to have a bigger image preview as well.


So there are various ways of getting in there,


but there is no kind of simple trick


to force your site into being visible there, which


is kind of tricky because when it comes to search,


you can understand what people are searching for


and create content that matches those searches with Discover.


People are not searching.


So there are no queries that we can show you where we can say,


well, people are interested in this topic.


You should create some content on this topic.


Makes it a bit trickier sometimes.


I have a question for my domain.


A large number of more than nine years old,


millions of events pages are still


getting crawled and indexed regularly,


even though I've removed the site map and everything.


And many upcoming events URLs fall


into the category of discovered currently not indexed.


And this number is increasing.


What should I do?


So I think discovered currently not indexed,


we talked about that briefly in the beginning.


With regards to site maps and crawling,


site maps help us to crawl better,


but they don't limit what we crawl.


So just because pages are not in a site map file


doesn't mean we would not crawl them or not index them.


We would still crawl the website normally.


Hello, John.


I'm here.


How are you?


Cool.


Good to have you here.


So I have a question.


I raised this question.


So my past year, low-quality pages are still indexing.


And my upcoming events, URLs are not indexing.


So this might be some Google issue or something else.


I don't think there's any issue with regards


to indexing at the moment.


But my upcoming events have high-quality pages.


And these past year, events are already low-quality pages.


So why Google continuously crawls these old pages


since it's too many years ago?


Yeah, my guess is that these are just


URLs that we have indexed at some time in the past.


And we tend to keep URLs indexed for a fairly long time


once we know about them.


So probably we just haven't gotten around


to kind of reshuffling things around here.


There are things you could do if you wanted to control that more


on your side.


One thing is to use the noindex meta tag on pages that you


don't want to have indexed anymore.


Another thing that you can do is use the unavailable after meta


tag, which lets us know ahead of time


when you think that a certain page will no longer be


relevant.


So for example, if you have events,


you could say maybe a month after this event took place,


you will kind of use the unavailable after meta tag


and tell us, this only makes sense


to keep indexed until a month after the event has taken


place.


And then afterwards, we'd be able to drop that out


a little bit quicker.


I don't know if removing pages from the index


will make it so that we index newer pages faster


on a website, though.


So it's not the case that you have a limited number of pages


in our index, and if we have the old ones,


then we can't add new ones.


AUDIENCE 1 But my question is, Google is still


crawling my oldest page compared to my new pages.


So that's why I raised the question.


Yeah.


I think from a crawling point of view,


we crawl a lot of things, but that doesn't necessarily


mean that we would still index them.


So my general recommendation here


would be to think about what you want


to continue to have indexed, and let us know about things


that you don't want to have indexed


if you want to make that decision.


But otherwise, to really make sure


that the quality of the website overall


is as high as it could possibly be.


I haven't taken a look at your website specifically,


so it's kind of hard to say.


But a lot of the pages that I've seen on Twitter that


get flagged for these issues where they fall into discovered


not indexed or crawled not indexed,


it tends to be that the website overall is


kind of in this murky area where we think, well, some parts are


pretty good, some parts are kind of OK but not fantastic.


And then at some point, we just say,


well, we're going to wait to see that we get more signals


for these particular new URLs before we spend time


to actually index them.


SPEAKER 2


After implementing online schema,


we lost all ranking in the feature snippet,


in event feature snippet.


SPEAKER 3


So any other ways?


That should be unrelated.


So the kind of the structured data


that you supply on these pages, when you additionally


add additional structured data types,


that wouldn't change the ranking of those pages.


It would just be it would give us


more information or different information about those pages,


which could result in other rich results.


But it wouldn't change the ranking of those pages.


So if you're seeing ranking changes,


that would be independent.


SPEAKER 2 No, no, no.


I'm not talking about ranking.


I'm talking about we lost our feature snippet in event


schema part.


Event list and event rich results.


I mean, if you could drop some sample URLs maybe


in the chat here, I can pick those up afterwards


and double check with the team.


SPEAKER 3


Yeah, so maybe you can continue with another webmaster.


Yeah, thank you.


All right.


SPEAKER 4


On the note of, oh, sorry.


On the note of the crawling or discovered not indexed,


sometimes I get AMP pages in there,


and they appear, they're freshly published,


and they do when I check them after they get indexed


or they have been indexed.


So is it just kind of a fluke if I ever


see AMP pages in the crawled or discovered not indexed reports?


Yeah, usually what would happen there


is we might discover and try to index those pages first,


because maybe we find a link to them, or for whatever reason,


we find them fairly early.


And once we've processed the AMP page


and we've processed kind of the canonical HTML page that


belongs to it, then we can connect the two and say, oh,


we just need to focus on the HTML page.


So as a first step, if we see the AMP page first,


we'll be like, oh, it's a page.


We'll index it.


And then as a second step, we'll see, oh, it actually


belongs to this other page, which


we crawled in the meantime as well,


so we can kind of fold things together.


OK, it's interesting that you might


be able to see the AMP page first,


though, because it's always connected to my canonical.


Yeah, I mean, it can happen that people link to these pages.


I see that every now and then that people


will take the AMP URL they find in their browser


and they link to that directly.


And in cases like that, we might pick that up a little bit


faster than the HTML page.


My guess is these would kind of just


clean themselves out over time.


It's more like, well, kind of a disconnect


with the timeline of crawling, where usually we'd


pick up the HTML page first and then understand the AMP


connection.


This time we picked up the AMP page first


and then shifted over to the HTML version.


OK, I see.


Thank you.


Is it possible I ask a question about page experience,


or you want to guess?


Go for it.


So could you open up your crystal ball and say,


it seems like the HTTPS, the page speed,


are all relatively historically minor signals


when it comes to linking.


The weights are just minor in general,


especially because you let Gary program them


and you don't really trust him too much.


I'm joking.


In any event, this page experience obviously


lumps a bunch of those elements into this overall thing.


And each one will be individually,


from what I've spoken to Google, each one


will be an individual factor.


It's just brand new purposes calling them page experience.


So the core vitals and all this other stuff,


I suspect also will be relatively minor.


Could you tell us if you think that would be true or not?


I know obviously nothing's been programmed yet.


I don't know.


My feeling is it depends a lot on the search results pages


where these pages are shown.


So in situations where it's very clear


that there is one relevant answer,


then we're not going to just pick one


that's a little bit faster.


So if someone is searching for a CR roundtable,


then we're not going to show some random blog that


talks about this site just because it's


a little bit faster.


We really, really know that people


are looking for this site.


On the other hand, if someone is searching for maybe something


more generic like SEO news, and we


have a bunch of different sites, and they're all


kind of in a similar level, then that's


something where we can take a lot more of these factors


into play and say, well, actually this


is kind of relevant, and it's a really good result.


Therefore, maybe we should show it a little bit higher.


And finding that balance is really hard.


That's something where the ranking team, they


spend a lot of time on this.


And they do a bunch of tests on this


to try to figure out what is the right balance between all


of the different ranking factors in all


of these different kinds of situations.


So it is really not possible to say how strong of a signal


it will be because it really depends on the circumstances.


And at the same time, it's not going


to be something where we say, well, speed has to kind


of dominate everything else because we really


need to also make sure that we're providing


relevant results to people.


SPEAKER 2 OK.


And if I could add one new factor in the suggestion


pool for those overall page experience,


the no date for a news site.


If the news site doesn't have a date in an article,


could you please add that as one of the type


that down in the book?


SPEAKER 1 OK, fine.


I hate that as well.


That's a good point.


SPEAKER 3 Can I jump in?


SPEAKER 1 Sure.


SPEAKER 3 We are making a new page format for a news website


in which stories will be told by cards.


For example, on the page, there are nine cards


for each question.


After clicking on the card, it slips over.


On the other side of the card, there is an answer.


It detects about 300 or 500 of characters.


We know that Googlebot does not leak,


which means that there may be problems with how Google will


understand such articles.


But at the same time, Martin Shplit repeatedly


said that if such content is in the DOM tree,


then the Googlebot will see it and use it.


So can you give us advice on how to correctly implement


a new format with cards from a technical point of view


so that they will be fully indexed?


And a link with an example code, if necessary,


I'll throw in the chat now.


So if the answer is in the HTML, then essentially that


will just work.


On the other hand, if the answer has


to be loaded from the server as soon as someone


clicks on that card, then probably we would miss that.


So that's kind of the different approach there.


So that's something where one way you can do it


is load the page and then look at the render


DOM that you have in your browser with the inspect


element.


And if the answer is already in there,


then you're already covered.


On the other hand, if the answer is not in there,


then you need to do an interaction first


before it's loaded into the visible page,


then that's something we wouldn't see.


OK, thank you.


OK, I need to take a break here.


Sorry for cutting things short.


I'll have a bit more time on Friday in case any of you


want to join in then.


Thank you all for joining.


And thanks for all of the questions that were submitted.


And hope to see you all soon, one of the next times.


Can I just thank you, John, for just a minute here?


Thank you.


I really need to go.


You need to go, OK.


Yeah.


No problem.


Maybe ping me on Twitter.


Thank you so much.


Bye bye.


Why are SEOs and Devs from different planets?

Why do moves such as EHEU's ranking factor still come up?


Why do engineers expect SEOs to prove themselves before they can trust them?


Why can't SEOs say I don't know when they don't know?


Why is it depends always the answer?


How can developers be better partners for SEOs?


How can SEOs be better partners for engineers?


Hello and welcome out there.


I'm so excited to have you all back here for another episode of SEOs and developers.


Today with me is Jan Matthews, who is an SEO at GitHub, which is a company that is dear


and near to my heart as a developer and developer advocate.


And she is known by the handle SEO goddess, which I think is an amazing name.


And I wish there would be more cool titles like that out there.


And I'm here with Martin.


The first time we met was over our crazy hair.


We both had purple and pink hair.


And now we're back to normal.


You know, there's times for everything and I think in wild times like these, it's a good


thing to come back to normal air at least if normality can't be achieved elsewhere.


Jan, I'm super, super excited to actually have you here today with me.


And I want to discuss something that I find very intriguing when it comes to SEOs and


developers working together.


I want to hear your perspective because you work in such an engineering driven organization


that you must have come across this as well.


The thing that I am finding very interesting is that it sometimes seems, I have the impression


SEOs and developers are sometimes speaking completely different languages.


And I don't mean like German versus English versus Russian.


I mean, even if we're speaking the same natural language, we seem to be not on the same wavelength.


Is that something that you have experienced in your career?


And how is that at GitHub?


Yeah, definitely.


I think GitHub just as much as any place else.


It's a company that's run by product managers, content writers, marketers, and of course


engineers just like any other company does.


And our engineers are just as bright as they are at any other company.


But yeah, I think the language definitely, speaking to engineers is just a completely


different thing.


And a lot of SEOs today aren't as technically savvy as I think that they should be when


they're talking to engineers.


And I think there's a gap in that.


Yeah, for sure.


I think that, yeah, I see your point, but I don't think necessarily that every SEO has


to be as tech savvy.


Because I mean, that's what the engineers bring to the table, right?


They are the tech savvy ones, they can help you with that.


But I have the feeling like sometimes it's so bizarre that when you as an engineer are


working on something on a software product, and then SEO comes in and they tell you stories


that feel like from a fairy tale.


And it's stuff like, oh, EAT is a ranking factor that just keeps sticking around or


stuff like, oh my god, we have multiple URLs pointing to the same content, this is going


to get us a penalty and things like this.


Why does this keep sticking around and why can't they just move on and be more, I don't


want to say honest, but like more realistic about the importance of these things and also


how certain they are about certain things.


Yeah, I think that it's tough for engineers to not think of SEO as a bunch of smoke and


mirrors.


I've been told that statement a million times.


Engineers want concrete evidence, if I do X, then Y will happen.


When it comes to SEO, we never know, right?


Like unless Google gives us the actual sauce, the recipe to the sauce, we can't decipher


it.


And so when we make decisions, a lot of times, especially on my end, I'm doing this for 20


years.


My best guess is my best guess, I basically could say if I do this in the past, this is


what's happened.


I can't guarantee that's going to happen.


And so everything is always test and learn, which is the only way I can get the language


to kind of resonate with engineers is that test and learn, like, let's try this.


We'll work together.


Let's see if it works.


And if it doesn't, then let's try something else and just keep doing that.


Yes.


And this is at the core.


Yeah.


But that you say that as if that would be a normal mode of operations.


And that would be the normal thing.


Because I think what you just said is amazing because it just realized how similar again,


how similar SEOs and developers are in the circumstances that they work in because you


say like, oh, yeah, you know, the developers want to know like, the real thing and like


hard facts.


But the reality is in engineering, and software engineering, specifically, we often also don't


know.


And oftentimes, we don't even know what we don't know.


And then we just have to, as you say, test and learn, we have to try things out, we have


to experiment.


But the thing that I find strange, and I think that's causing friction as well, is that an


engineer, when they don't know something, it's like, hey, can you build me this thing?


They have never built something like that before.


They'd be like, I don't know.


But you know, we can build a prototype and we can try things out.


And then if we figure it out, then we can make that production ready.


That's a thing that we can do.


And that's a very normal thing.


So like saying, I don't know, let's find out.


Or I don't know, I'll have to check.


Or I don't know, I have to do some research is a perfectly reasonable thing to do for,


I think, both SEOs and developers.


And yet, in my career, I have mostly heard engineers or developers say that, but SEOs


seem to be unwilling to admit that they don't know something.


Yeah, that's true.


And I think, you know, we're constantly, I mean, throughout my career, I've always been


questioned.


Every time I start with a new company, I'm constantly questioned.


It's that smoke and mirrors, right?


I say something will happen if we do this thing.


We'll get on, of course, I can never guarantee first position, right?


But I'm like, let's try it.


Let's try at least for the first page.


And they're sitting there going, you know, Google is a, we have no control over this,


right?


Like you have no control.


You don't know.


And so it's hard to convince people to try to do that thing and get that result.


And that's where we get into that test and learn.


And SEOs are constantly questioned, constantly, right?


So it gets to a point where we almost kind of get on the defensive.


So when we're asked a question or how's this going to work, or if we do this thing, what's


the result going to be?


It's hard for us to say, I don't know, just for that reason, right?


Because we're constantly under scrutiny or constantly being questioned.


But what I usually, so what I usually tell other SEOs is say, it's okay to say, I don't


know, because they're going to say, I don't know too sometimes.


Right?


So everybody is going to use the word test and learn, right?


Let's try this out.


Let's work together as a partner.


Let's try it out.


Let's test it.


And then let's see what happens.


And when we do launch things and they say, how come it's not working?


Instead of us digging in and trying to understand which algorithm is not letting us rank, right?


Like it's okay to say, I don't know.


And let's try something else and move on.


But it is, it's very difficult for SEOs because we are constantly under scrutiny.


Under scrutiny from whom?


Is it developers questioning your expertise or is it like someone else in the organization


questioning your expertise?


Yeah, pretty much the whole organization runs into it.


You know, because it's, you know, when you're asking content writers to put a keyword in


the header and keyword in the H2 and a keyword in the body, and they're like, why do I have


to use this word?


It doesn't make sense in the copy I'm writing.


And it's like, well, if you don't use this word and then they say, you know, then it


won't show up because Google won't find it.


And then they say, well, it doesn't fit with the narrative.


And you're like, well, this is what people are searching.


So it becomes this conversation and they're, you know, this back and forth to the point


where they're like, I don't know if I believe this.


Right.


And then you just have to that test and learn.


It's like, well, let's just put this one keyword in the body somewhere and cross our fingers


at works.


And if it does, and it's like, look what you did.


Interesting.


Yeah.


So it's the Oh my God.


Okay.


So yeah, then it's no wonder that you're pretty much like always on the defensive if everyone


kind of fights and everybody's you and okay.


Yeah, maybe leadership, you know, you even get leadership.


But then maybe developers can actually probably be their your allies because they should,


and I say should, because I know there's lots of different developers out there.


Developers should understand that I don't know is a reasonable statement, especially


if you then follow up with let's test and learn.


That should be on their wavelength.


And then maybe you have like at least someone backing you up, even if it's not the content


side.


I think having the technical side on on your side as well is probably a good thing.


But then speaking of becoming allies, what could the engineering side, what could developers


do to to help SEOs, you know, get get over that friction, get over that scrutiny, I think,


definitely helping you with tests and learn.


So so being open in the style of on their end as well and being open to try things out


with you and other SEOs.


But what else is there something that you would say like developers could do to make


SEOs lives easier?


I think it's kind of a back and forth, right?


I mean, I think it's.


How engineers can best make SEOs or be best advocates for SEOs is I mean, I hate to say


it, but just make the changes right that are asked, I think, to be blunt, as I'm known


for, you know, an SEO will say, hey, but it's also the other side of it, like SEOs need


to understand that what we're asking sometimes aren't super easy to do, like what we think


might be a simple like let's say there's a few redirects that are happening in the footer,


right, of the entire website.


And we're like, just fix this one link, right?


Like it's just have it point to the main one and stop this, you know, like maybe it's a


302 because somebody thought it was a temporary and no, no, no, we need to make it permanent.


So even just having that conversation, you know, SEOs were like, it's just one link,


but from an engineer perspective, it's like a whole going to figure out where the programming


is that makes it create the footer and where it's, it's much more complex than just fixing


one little link.


And so I think, you know, engineers, I think where that partnership comes in is that engineers


need to understand that we're not just asking for simple little fixes just because we feel


like it, right?


There's method to our madness as I say often to everyone I talk to.


And I also, there's always a method to my madness and the other one is it's a small


part to a bigger part of the problem, right?


And so little time when you add up, you know, one little fix is not that big a deal, like


one little redirect, but when you have, let's say, um, a million pages and 850 some thousand


of them are all redirects, that's not a good thing.


And so you want to clean those up as much as possible.


And so that's why I say, yeah, this one little thing isn't a problem, but you got to do five


of them because they're creating a hundred and, you know, 850 some thousand redirects.


And once they see that, and so I think, yeah, I think it's kind of both sides of it.


If engineers understand that when we're asking for a simple fix, a lot of times it's not


just one simple fix.


It's you know, just kind of a conglomerate of a bunch of things and there's a reason


more often than not why we're asking for it.


So yeah.


And then there's like this, this quadrant situation.


It's like low impact, low efforts, high impact, the high, high impact, high efforts, uh, is


probably high impact.


High effort is like the tricky ones.


High impact, low effort is where it's like the low hanging fruit that you want.


And then there's like high effort, low impact.


That's the ones you want to avoid.


And I think understanding where, where things are on these quadrants with developers is


probably also helping SEOs figure out when to suggest what.


Right.


Exactly.


Yeah.


And I actually, um, my SEOs that have worked for me in the past, I have taught them actually


how to do that low impact, you know, the impact versus effort.


And when you have fixes, you know, make sure you put that rating in there or talk to your


engineers that you work with.


And that helps them develop a partnership as well with the engineers.


And then we can kind of gauge what needs to get done.


That's really cool.


That's really nice.


And I think if we look at the working relationship between SEOs and developers, as you said,


it needs to be a dialogue.


It needs to be a two way conversation and we can both learn from each other, I guess.


Would make our lives easier.


Wouldn't you say?


Yeah, for sure.


I mean, um, yeah.


It would be, it would be so nice to just have that more happen more often in organizations.


Is there something that we can do from the developer side to make sure that these dialogues


happen in our organization?


Yeah.


I mean, that's, I think it's up to engineers at that point for sure.


But if I am an engineer that who doesn't really know what to do to help my SEO in question,


what would you say is a good icebreaker or a good door opener for me to become a better


partner for the SEOs I'm working with?


I'm afraid of approaching you kind of.


Oh gosh.


Um, I don't know.


It sounds like you figured it out.


So I just, well, from my perspective, yeah, I'm not an engineer, so that one's a tough


one to answer.


I think maybe kind of asked you, yeah, it's a good question for you.


But I mean, from my perspective, your perspective, what would you love an engineer to come forward


with to you?


Yeah, I think, I mean, I'll give you my perspective and then, um, I'd love to hear yours on it


is, um, you know, from my perspective, when I come into a situation and I get to know


the engineers that I'm working with, there's ones that are kind of like, I don't get it.


I don't want to do it.


Leave me alone.


And I leave them alone.


Right.


And then, and that's where maybe you can help answer that question.


The other ones are, you know, every once in a while there's somebody who just gets a passion


for SEO with what they do.


And they'll kind of, you know, become my ally and then do some of the changes that I've


asked.


And then they actually even asked me for the followup, like what were the results of this


change we did three months ago?


And I show them and they get excited and they share that out with their team and they want


to do more.


And they asked to be assigned to the SEO work.


And so then we become this like, you know, synergistic and there's quite a few of them


I have at GitHub, which is really nice.


But there are some of them that I've asked them for help or asked that, like, have them


look at something that I'm seeing and like, Hey, can you help me problem solve?


And they're like, let me give it to someone else.


Yeah.


So maybe you can help give insight into somebody who's just not there.


I think I see where that's probably coming from.


I can see two reasons where that comes from.


The number one reason is probably that they work in some sort of process or system that


does not reward this kind of interaction or help.


And that's an organizational issue, I would argue.


So for instance, if you were doing scrum and you're, you have to do, or you're committing


to doing whatever is in the iteration.


And then someone comes up and asks you for additional stuff that isn't in the plan that


you were basically overcommitting yourself because now I have to balance what I promised


you with what I promised everyone else on the team, including the product owner and


probably business stakeholders.


And then there's like, ah, and the easiest way to deal with that is because you didn't


come in through the regular channel of where commitments come in through is to drop your


request.


That's the obvious thing because everything else has been committed.


And now you're asking me to commit something or to commit to some activity.


So I can deny that, which would mean that you need to figure out where in the process


you can place this request so that it gets picked up by someone in this friend.


So that's one reason.


The other reason that I could see for this to happen is, and we come back to the, I don't


know, that they don't know why that would matter.


There are a lot of developers who look very technocratically on their work.


It's like, I measure myself by the features that I output.


I measure myself by the systems that I build or by the systems that my code touches or


something like that.


Basically they're looking only at what they can immediately see and touch, which is the


code.


They might not necessarily be aware that it isn't that much fun to work on something that


no one ever uses because no one knows it exists and no one knows it exists because it can't


be found where everyone looks for knowledge, which is search engines.


So that's an approach that I have taken whenever I talk to developers.


And I mean, I have been at lots of developer conferences and it's tricky to get them to


listen to you when you are talking about SEO.


Even as a developer, it is not necessarily trivial to get everyone in the room to listen


instead of just reading something on their phone.


And the way that I have done this is like, look, you want to build stuff that has an


impact, most likely a positive impact on someone else's life.


And if that impact can be as big as it can be, that is great, right?


You're not building software for the sake of building software.


You're building software so that people can solve problems or fulfill needs with it.


And if no one knows about your software, then why did you build it in the first place?


And that oftentimes hooks them in.


And then you can say like SEO gives us a tool or is a tool for us to bring people's attention


to the things that you build.


And I need a little bit of your time to make sure that this attention is given to your


work.


Sometimes that works.


It doesn't always work, but I would say these two things would probably hook most of the


developers to help you.


I hope.


So instead of leaving them alone.


So how do you think that, I mean, an example of myself or other SEOs could be better partners


for those types of engineers or engineers in general?


There are a few things.


So definitely, I love that you said, yes, I have been and we have in our organization,


we have been doing this quadrant thing because that helps immensely.


Because if I have to sort through lots of concurring items that all need my attention,


I'm always obviously like, we are all human.


We are not super human.


No, none of us is a superhuman.


We look for the high impact, low effort thing.


And if that's something that you would like to get out of the way, then presenting me


with this first is definitely a good chance for me to pick your thing up.


Because I don't have to do that much, but someone out there will be very happy that


I did it.


And I can say, I did this thing and my work here had impact.


So that's helping.


And lots of SEOs, unfortunately, don't do that.


They come with a variety and not even single items.


They basically just come with a long list of stuff.


And I have no way of ordering this list or figuring out how important any of the items


really is.


And then I'm like, why would I even do more research on which of these things needs to


get done first if they don't even do it?


If they just throw me an unordered list of stuff, I'd be like, can't be that important.


Because if it would be important, they would be elaborating on this.


So if you elaborate on it, that's amazing.


Also, at least I know lots of engineers that would love to be asked about stuff.


So I know that engineers have a huge issue with people coming with solutions.


Like, oh, you have to do this thing.


Oh, can you please change the template so that it goes straight to the right URL instead


of redirecting in between?


And then I'm like, we're not even using templates.


But thanks for your suggestion.


It's true, isn't it?


Engineers are problem solvers as much as SEOs are problem solvers.


So why don't we do the problem solving together rather than SEOs who might not even know the


platform or the tech stack that they work with going into details there and making things


up that they don't know about and then coming to me with a solution that is nonsensical


in the circumstances that our product and our tech stack is in.


Instead of that, just go like, hey, I noticed that we have this weird redirect thing here.


And I was wondering, what would it take to fix it?


And if they say, oh, actually, that's just the thing in the template.


Can you tell me what the URL for this is?


Oh, yeah, the URL that it should be is this.


But the URL it actually goes to right now is this, which then redirects three times.


And you're like, oh, OK, in that case, let me take that URL, put it in the template.


I'll commit it.


I'll do a one line change maybe.


And then the developer is happy because they accomplished something that you tell them,


oh, that actually is great because this fixes I don't know how many thousand links in one


go or redirects that are happening every month in one go.


So they are happy.


You are happy.


Everybody wins.


So that's the thing that I think is very important, to come with problems and find the solution


together because developers, A, probably have better insight into what these solutions should


look like, and B, also are interested in the solving of a problem, not necessarily in just


stamping out the solution.


Does that make sense?


Yeah, that totally makes sense.


And I think sometimes, like I said earlier, the SEOs may think that they know what the


solution is.


And yeah, like, hey, just fix this one link.


It shouldn't be that big a deal.


Maybe the template's more complex, right?


And you have to really define it.


But I understand where that's coming from because if you are under scrutiny, then you're


like, I don't want myself to be vulnerable again to someone being like, you have no idea


what this one takes.


Like, this is a lot of work or something.


But you make yourself somewhat vulnerable by saying like, hey, I just noticed this problem.


Could we work together on solving this?


So I think, yeah, I think that would, yeah, that's the key to working with engineers and


getting them to be so the ones that are quiet.


That's what I need to do is just kind of like go to them and say, I see this thing.


Can you help me solve it?