Candour

Episode 123: Safe browsing, page experience, tie-breakers and canonical images

Play this episode:

Or get it on:

What's in this episode?

In this episode, you will hear Mark Williams-Cook talking about:

Safe Search Page Experience: How much does Google's removal of Search Search from the Page Experience Signals mean?

Tie-breaking: Are Core Web Vitals an important ranking factor, a tie-breaker, or... Does it depend?

Canonical images: Do you get any SEO benefits from other sites uploading images you created?

Rendering and SEO tips: An admission on JS rendering and unsolicited SEO tips.

Show notes

Safe browsing - not part of Page Experience

https://developers.google.com/search/docs/advanced/experience/page-experience

CWV more than just a tie-breaker

https://www.seroundtable.com/google-page-experience-update-tiebreaker-31880.html

https://www.reddit.com/r/SEO/comments/oyp74h/anyone_else_not_buying_core_web_vitals/

https://www.seroundtable.com/google-talks-hypothetically-about-speed-as-a-ranking-factor-31375.html

Can images be canonical reddit

https://www.reddit.com/r/TechSEO/comments/oueiil/do_images_across_the_web_operate_like_pages_with/

504 unsolicited SEO tips

https://withcandour.co.uk/blog/unsolicited-seo-tips

Transcription

Mark Williams-Cook Welcome to episode 123 of the Search with Candour podcast, recorded on Friday the 6th of August, 2021. My name is Mark Williams-Cook and today I'm going to be talking about safe browsing being taken out of the Page Experience report of Google Search Console, and whether this is an important thing or not. We'll be talking about Core Web Vitals and whether or not they are more than just a tiebreaker. Apparently we've been having mixed messages from Google on this. Really interesting question as well we're going to discuss, which is can images be canonical? So do you get benefit from other people downloading and using your images on their website? Apart from that, a slight admission I have about rendering, and lots and lots of SEO tips for you.

MC: Before we kick off, I want to tell you this podcast is very kindly sponsored by the lovely people at Sitebulb. Sitebulb, if you've not heard of it, is a desktop-based SEO auditing tool for Windows and Mac. And in my opinion, and not because they pay to sponsor this podcast, I honestly think it's one of the best bit of auditing kits out there. We've used it for a long time at Candour. Really pleased when they wanted to get involved with the podcast because I'd basically been telling people about Sitebulb anyway for free.

MC: And one of the many features I really like about it that's fairly new in terms of the great stuff they do and is relevant to this episode is they do an excellent comparison of the JavaScript and non-JavaScript versions of your site. So we're going to be talking about rendering later on in this episode, and if you're a tech SEO or you've been doing SEO and dealing with JavaScript frameworks, you will know that JavaScript rendering is a hot topic in that it can really make or break your site, but it can be super complicated to work out what's going on.

MC: Sitebulb will crawl your site and with their engine that then analyzes what's going on, it can give you what I think is the best side-by-side comparison of your raw HTML and your rendered document object model, and it will give you summaries of things like how many links were added by JavaScript on your site, how many links were modified by JavaScript. So it will become really easy to see which parts of your site architecture are reliant on JavaScript being executed, which is hugely important and basically can save you a lot of money, especially if you're testing a new site maybe or having a migration.

MC: Sitebulb has got a free trial anyway, but if you listen to this podcast, there is a special offer for an extended trial of 60 days. All you need to do is go to sitebulb.com/swc for Search with Candour, and you can get this trial. You don't need a credit card, anything like that. You can just download it at sitebulb.com/swc.

MC: There is a couple of things in this episode I'd like to talk about, which are things but they are maybe not things. What I mean by that is they're pieces of news that have been around in the SEO community I've seen this week that maybe actually shouldn't be news. And I think that's important to know so we're not maybe focusing our time in areas where it could be better spent. So the first of these maybe things that aren't things is the announcement Google made around their Page Experience algorithm and Safe Browsing.

MC: For a long time now, Google has had this lovely little graphic which you'll find in the podcast notes at search.withcandour.co.uk, which lists the things they take as search signals for Page Experience. We've seen a lot of this diagram lately as Core Web Vitals has been dropped on there with the LCP, FID and CLS metrics, which we've spoken about a lot in other episodes. And previously in this diagram, we've also had mobile-friendly, Safe Browsing, HTTPS and no intrusive interstitials as part of this. So things Google looks at when they are judging the Page Experience.

MC: Now there is an announcement on Google Search Central. Or, not so much an announcement as so much an update log, which the latest one is August the 3rd, and they've said, "We made several improvements to the Page Experience report." So this is referring now to the Google Search Console Page Experience report, "Including removing redundant, Safe Browsing and ad experience widgets from the report. We also clarified that Safe Browsing isn't used as a ranking signal. Safe Browsing systems continue to play an important role to keep users of Google Search safe and any flags will continue to be surfaced in Search Console outside of the Page Experience report."

MC: What some people are reporting as is ... They're saying, "Well, Safe Browsing is no longer a ranking signal." But I think the truth of all of this is a bit more bland, which is that if you've seen sites that have been compromised in the past, generally they will still be there in Search, but you will have a little notice under them and normally a gateway before you get onto the site that says ... It's something like, "This page may be compromised or may be hacked," or something like that. Anyway, a big sticker on your site in the SERPs that you don't want.

MC: Now, the way at least I consider and I encourage people to consider SEO is anything that's going to really increase the amount of organic traffic you get from search engines. So by that I mean it's not necessarily something that's just focused on rankings. To give another example, you might want to look at optimizing meta descriptions. And what do we mean by that? We mean enticing people to click, to get more clicks from the same amount of searches.

MC: Now we know that meta descriptions aren't going to change the rankings of our pages in a search result, but they may well entice more people to click. Despite that thing we're doing not actually impacting rankings, it's still something we class as SEO because we're getting more traffic, right? And what I think has happened here is Google had provided us with this more general model of, "Here's what we think a good page is about," which included things like Safe Browsing. But now they're talking more about ranking factors with Page Experience, and a lot of this, I think, is around Core Web Vitals, and it's very much muddied the water as if everything on that list is directly in some way affecting whether a site ranks number one, number two or number three.

MC: I don't think anything's actually changed in terms of it's not that, "Okay, Google's worked out your site's been compromised so actually you're going to rank three instead of number two or number one." It doesn't make sense, and it's actually not what we've observed. Generally, as I said, you just get that label on your site. The other thing is that these messages saying, "Okay, well, we think your site's compromised," are still coming through Search Console. And obviously we still need to avoid ... apart from the whole security issue, from a very narrow SEO lens, we still want to avoid sites being compromised because it's going to negatively impact the amount of people that actually click on our result.

MC: Fundamentally, I don't think anything has changed. For all the good reasons, you still want to make sure you're falling within these Safe Browsing guidelines, and any notifications about that are still going to come from Google Search Console. So I don't think this is the big change that some people are making it out to be. Most of the focus around Page Experience is going to be about Core Web Vitals, and we'll talk about that in a minute and just how important or not they might be. But yeah, that's my one out of two of things that possibly actually aren't things this week.

MC: Okay, so in my two of two of things that could be things but probably aren't things is an article actually I found on SE Roundtable today, which was titled Google Says Now the Page Experience Update is More than a Tie Breaker Ranking Factor. So let's rewind a little bit. We've dealt with quite a few of these security/UX ranking factors before. Page speed in general has been something Google's used as a ranking factor we know for a long time. Interestingly, they've said it's not a very sensitive ranking factor in that previously if you have a page that loads in three seconds versus a page that loads in five seconds, you're probably going to notice absolutely no difference there. Where it does have an impact is if you've got really slow pages. So maybe there's a cluster of competing pages that are loading in two seconds, five seconds, three seconds, one second. They're all pretty much treated the same. But then if you've got another page that everything else is equal but it's loading in 12 seconds, that's when likely you're going to see some impact because it's really detrimental to that user experience.

MC: And we got a little bit more history on this for HTTPS. So Google pushed really hard on trying to get all websites and all pages on secure HTTP connections, so HTTPS. And they initially apparently experimented with making this quite an important ranking signal, but actually found that that wasn't an optimal way to give good results, as you might expect. You might actually have really good content on a site that hadn't got around to using HTTPS. So they used it more as what they described as a tie-breaker. Meaning, okay, if these two sites, they're roughly the same maybe in terms of authority or popularity and the content looks roughly the same quality, whether a site is secure or not might be a good factor to make that final decision. So if one's on HTTP and one's on HTTPS, it just moves you towards, "Well, this site maybe cares a bit more about user security and privacy."

MC: It's just that if you were going to bet otherwise blindly on which one's going to be better, it would be a smart bet to place on HTTPS. So there was loads of speculation before the Core Web Vitals and page experience actually update came about as to how this would impact search results. So we had people, as you can imagine, from all ranges. Some saying, "We're not going to notice anything." And some saying, "It's going to be a major shift." As you would know if you've listened to this podcast for a while, we've certainly been on the more cautious end of that scale saying, "I don't think it's actually going to make that much of a difference."

MC: And certainly, at the moment at least, it looks like that's what we've seen. So there's been a few studies. I was reading one, I think it was last week, by SISTRIX. I'll try and find a link to that and, again, put it in the show notes. That was trying to determine if since this page experience update's been rolling out, if we can find any correlation between how sites are scoring with Core Web Vitals and if we can see any difference in their ranking. And to cut a long, detailed study fairly short, no was the answer there.

MC: This is really hard for us to tell on an individual basis because, unless you've been under an SEO rock recently, you'll know we've had a June core algorithm update, we've had a July core algorithm update, we've just had a link spam style update as well. So really big changes in Google's algorithm which could affect our sites. So companies like SISTRIX that have this wide-reaching data are really well positioned to actually do these kinds of studies.

MC: It's very difficult for individual sites over the last few months to say, "Okay, well, we've lost rankings. Yeah, it's definitely because we perform poorly on Core Web Vitals." When actually it could have been the June or July core update, or it could be because there's some links they've had that are now discounted. It's really hard to ... really, really hard to actually attribute that, especially when, with these core updates, the communication we get now from Google is very much the same around each update. They don't really go into specifics with core updates as to what they're focusing on. Normally it is a broad selection of things according to them, but there's nothing we could easily tie back to these changes.

MC: Where this headline from SE Roundtable came from was actually a Reddit thread. If you don't use Reddit, there is a couple of SEO subreddits. So there is one just r/SEO. There's one I like a bit more than that personally, which is called Big SEO. But in r/SEO, someone posted saying, "Anyone else not buying Core Web Vitals?" And they went on to say, "I just find it hard to believe that this actually becomes a greater part of the ranking algo. Has anyone seen dramatic gains or decreases based on it so far?"

MC: He's in a lot of different places, but John Mueller, apart from being on Twitter and answering everyone's questions, and doing his Webmaster hangouts, he is also active on Twitter and participates in these discussions. And John posted this as the response, "It is a ranking factor and it's more than a tie-breaker, but it doesn't replace relevance. Depending on the sites you work on, you might notice it more or you might notice it less. As an SEO, part of your role is to take all the possible optimizations and figure out which ones are worth spending time on. Any SEO tool will spit out tens or hundreds of 'recommendations'. Most of those are going to be irrelevant to your site's visibility in search. Finding the items that make sense to work on takes experience.

MC: "The other thing to keep in mind is that Core Web Vitals is that it's more than a random ranking factor. It's also something that affects your site's usability after it ranks, when people actually visit. If you get more traffic from other SEO efforts and your conversion rate is low, that traffic is not going to be as useful as when you have a higher conversion rate, assuming user experience, speed affects your conversion rate, which it usually does. Core Web Vitals is a great way of recognizing and quantifying common user annoyances."

MC: So to start at the end there and work backwards, that last paragraph, that last point John made about the Core Web Vitals actually being a good way to describe the user experience when they're on the site, this is how I approach Core Web Vitals with everyone in that the fact it's a ranking factor is pretty much secondary. That shouldn't be the core reason that you're tackling these metrics. It should be, "Oh wow. Well, we can actually improve our bottom line. We can improve sales. We can improve how many inquiries we're getting by reducing annoyance, reducing friction by increasing speed, improving response times, reducing layout shift as it loads." And the fact that that may affect rankings is not by-the-by, but a bonus rather than the core reason for doing it.

MC: The other thing that we've heard before I dive into the first bit of what John has said there is Google has always said that the impact of Core Web Vitals, of the Page Experience update, would be incremented over time. Meaning that, when the algorithm is first launched, you can expect to see relatively small if any changes, and over time you would expect to maybe see those changes become more prominent, and that makes sense. As you can imagine, with any algorithm update, Google does various tests to make sure they are heading towards their longer term goals of providing the type of search results that they want to provide.

MC: But the interesting thing for me about Core Web Vitals is it's one of those updates that literally impacts potentially every website because all of the sites are being judged by this. So if they just flick a switch and dump this Page Experience algorithm and it has a significant impact, it could cause quite a lot of chaos and it could really disrupt in ways they hadn't maybe foreseen their search quality. So it does make sense, I think, to slowly adjust this algorithm and see what kind of results they're getting and response from users.

MC: Now the first part of what John has said here is, depending on the sites you work on, you might notice it more or you might notice it less. And I think this is particularly important because, as I just said, obviously this is a set of metrics that every webpage will be measured on. You might think, "Well, yeah, it's something that's just going to be blanket applied to every site." But I don't believe that that is the case.

MC: So we've previously listened to people like Lily Ray talk about subjects like expertize, authority and trust [inaudible 00:18:54] and how Google differs in terms of ranking various pages around specific subjects and the metrics it uses. To give you an example and unravel what I just said there is for particularly sensitive subjects, Google may lean more heavily on website authority than actual what they might perceive to be the most relevant or the best content. And it's one of the ways that they can protect against bad information, information that might harm people, spam or conspiracy theories that might be damaging. Because you could write really good content, but if you are not an authoritative subject, it's a risk to surface that content.

MC: So what I'm saying here is while we understand as concepts and ranking factors these different things that are in the ingredients of SEO, we don't know in specific scenarios, in specific niches for specific types of searches for specific types of intent, how they interact and how important they are. Following that logic, and from what I think John is hinting at here, is that Core Web Vitals may not play an equal part in ranking across all different website categories, niches and searches. What he's saying here as well is, "Yes, just because you don't see the result may be because it isn't affecting your site particularly that much." Or again, as we said, it may be because the impact we'll see progress over time.

MC: Going back again to the final thing that he finished on, and I strongly agree with it and I'll keep saying this, is you should anyway be looking at Core Web Vitals because it's highly likely that that's going to correlate to how happy or frustrated your website visitors are. So it's never going to be a bad thing to fix that, and I would just take it as a bonus with no expectation about how it's going to actually impact your search results. So that was my two out of two of things that are kind of things but probably shouldn't be things. Just get on with it, sort your Core Web Vitals out and carry on.

MC: And while we're in the midpoint of the show, I would like to introduce our sponsor Wix who has this update for you. URL customization on Wix is now available on product pages. You can now customize URL path prefixes or even create a flat URL structure if that floats your boat. Plus Wix automatically takes care of creating 301 redirects for all impacted URLs. Full rollout coming soon. Also fresh off the press, bot log reports. Get an easy understanding of how bots are crawling your site without any complicated setup, right inside of Wix.

MC: There's so much more you can do with Wix. You can now add dynamic structured data, upload redirects in bulk, including error notification and warnings and fully customizable meta tags and the Robots.txt file. You can get instant indexing of your homepage on Google while a direct partnership with Google My Business lets you manage new and existing business listings right from the Wix dashboard. Visit wix.com/seo to learn more.

MC: I think this next thing we're going to talk about is probably one of the most interesting SEO questions I've seen. And again, it's actually from Reddit, from a slightly different subreddit this time, which is r/TechSEO. So there's quite a few places to explore on Reddit if you are into SEO. And this is the question: "Do images across the web operate like pages with a 'canonical version' considered by Google?" And then the question goes on to elaborate, "Bit of a vague question, but was trying to get my head around this. Let's say I have a 100% unique photo that I upload onto my website and then later my content is indexed and a few weeks passed. Another website or two find my image and download it as it is before uploading it to their own websites. They don't credit my site with a link or make any reference to it, but they also don't edit the image in any way. Does my website benefit in any way from having the original image? Or will there only be some kind of signals passed if there was a link back to my page or image or a reference of my business name on their page?"

MC: I thought it was a really, really interesting question. We've spoken before on the podcast and various webinars and to clients about the importance of Google image search particularly and the different algorithms that are used in Google Images to general web search. What I find the most interesting, the different behavior people have, especially around ecommerce and maybe things specifically, even like fashion, I think is a really good example whereby people might Google a type of clothes or trainers or coat or something that they like. And rather than then just look through Google PLAs or visiting individual websites, I've seen a lot of people just hit Images, and then they scroll through visually what kind of fashion and images they like and then find the website, find the product they'd like that way, through Google Images.

MC: We've given lots of clients, and ecommerce clients particularly, the advice around using unique images. Because, as you'll know if you've done a search on Google Images, you rarely get the same picture over and over again, even though lots of websites use the same library of photos that maybe they get from stockists. So this a really interesting question because obviously there is some mechanism for Google to fingerprint and identify these images and make sure it's not showing multiple versions of the same image in a search result. Therefore, it must be attributing some kind of canonical signal to one image, or at least saying, "Hey, this is the one place I want to choose this image from." Because they tend to stay static. You don't tend to see one image cycling around the different sites that it's on. They tend to get there and they stick.

MC: The logic of then, well, if Google has seen all of these other images and has chosen my website as the canonical source, to use the term the poster's using here, the canonical source of this image, does it make sense if someone else uses that image that there is some kind of credit given to me by Google? Because this person's question specifically says, if these websites find their image, download it and then reupload it to their site, essentially stripping out any way through the HTML that would be possible to detect where the image came from unless, obviously, you're Google and you're crawling the media on the web and you've recorded and logged this kind of information.

MC: Gary Illyes from Google was kind enough to jump in again on Reddit and give an answer to this. Again, it's a very short answer, as many answers from Gary are. And he says, "Surprisingly hard to answer. In short, you do get some benefit from an image syndicated on other sites if your HTML landing page can become canonical." What I think he means by that is, and feel free for anyone to correct me if you think I've interpreted this wrong, is whenever we have an image in Google Image results, when you click on it, it will bring up, essentially, the page where Google found that image. You used to be able to go straight to the image. Google doesn't do that by default now. But you can click and go through to that landing page which is then, I believe, considered the canonical source for that image.

MC: Whether the correct term for the image source or not is canonical, I believe what Gary's saying is you are trusted as the original source for this image if it is your page that's actually coming back when that image result is appearing. And someone else has actually gone on then to say, "Do you identify the same image via hash or similar?" So for those that don't know, a hash is essentially a way to give a text numerical string to an asset that is unique to that asset so you can tell just be generating this hash, because it will be the same every time for that image, whether it's the same image or not. And Gary answers somewhat cryptically, "Something similar. I'm not going to say exactly because spammers."

MC: Which, to be honest, is a fair enough answer. But I thought this was an incredibly interesting question, and really interesting that Google's giving us a, I think, as far as Google is at least, a very direct answer in that you do get some benefit. So even if these people are not directly hotlinking your image, if they're not mentioning you, if they're not linking back, if Google's worked out that that image came from your page then you are going to get some kind of credit for that, which I thought was really interesting and just adds one more grain of rice onto the scales of, "Should we bother doing our own photography or our own imagery?"

MC: Lastly on this episode, I'm going to do kind of a little bit of a self promo but also an admission, so they go hand-in-hand. You get them together. I think that's a fair way to deliver it. For those that have either already followed me on LinkedIn or have listened to the podcast now for more than a year, you'll know every working day I go on LinkedIn and I scream into the void of bad SEO advice and information and myths, and I post what I call an unsolicited SEO tip. Which is a short piece of advice about SEO that I try to make generic to anyone that's reading it and most websites, which is harder than it sounds because there's always someone giving me an, "Actually, but," or some edge case, but generally it goes fairly well.

MC: And every time I got to 100 of these, I would add them to originally a LinkedIn article but now it's too big for LinkedIn, which I found out, unfortunately, last time after spending hours and hours filling out this document, only for LinkedIn to refuse to save it and lose all my work. But we have just published ... I say we because I was very kindly helped by some of the team at Candour to get them all live. We now have 504. I don't know why I went for the odd number this time. I just felt I'd put everything out there that I've got. But we have 504 unsolicited SEO tips published on our website for you to read for free. The easiest way to find them is just to search for unsolicited SEO tips.

MC: So you've got obviously over this time period, I started this back in 2019. So I have tried to keep this list up to date. I.e. when some information changes like rel=previous rel=next turns out not to be a thing, or when Google sunsets their unofficial support for Robots.txt Noindex, I will go back and try and update the article to keep it up to date. The admission and, I guess, apology I want to give Google and specifically maybe Martin Splitt here was around the advice I was giving around Google and JavaScript rendering.

MC: So, as we know, Google can process, can render JavaScript. And like many people that have been in SEO for a while, we've probably been massively burned at some point by a client probably putting live a website that's reliant on client-side JavaScript, and essentially just getting ourselves into all sorts of bother. So one of the actually second tips that I ever published back in 2019 was around how Googlebot itself doesn't process JavaScript as it crawls. It goes back to HQ and this web rendering happens. There can be quite a big delay for client-side rendered sites.

MC: Martin Splitt was kind enough to point me to a Chrome Dev web summit he did in 2019 where he actually looked at this data and said, "I've found that the median time for this JavaScript to be rendered is actually five seconds." And this got me scratching my head because I was like, "This is definitely not what I'm seeing in the wild." But this is where my small revelation came. And again, you'll probably laugh if this is obvious to you. It certainly wasn't obvious to me in my model in my head about how Google works.

MC: But originally I was measuring this amount of time that it takes Google to process JavaScript by doing tests whereby I would publish a page and I would, as soon as it's published in the first version, it would have some JavaScript that, for instance, edits the title. And what you would see is Google would crawl the page, index it. It would not process the JavaScript. So the non-JavaScript title would be indexed. I would then measure the amount of time that it took, checking every hour for days and days until Google actually put the JavaScript edited title into the SERP. And that was my measurement for how long it took Google to render JavaScript.

MC: Which, actually is incorrect. What I'm actually measuring there is the outcome of many different systems of Google, apart from the rendering of JavaScript, back to systems that handle titles, which are apparently separate to everything else, which I didn't know before. And of course Google actually updating their search index, which may come way later than when a page has been internally rendered.

MC: One of the biggest concerns that SEOs have around JavaScript rendering, apart from content and things like this, is actually around internal link discovery. Because, especially if you're in a situation where lots of links require JavaScript, you might think you're in the situation where you're going to have to then wait days or weeks for Google to be able to find the next set of links that it needs to crawl and build that internal linking graph and work out which pages are important or not.

MC: However, what may well be happening, and I checked with Martin and said, "Are you happy with the accuracy of this?" And he said, "Yes." Is that that rendering may well happen in the background long before the search index that we're measuring becomes updated. So Google has access to all of those URLs, can go off and crawl them nice and quickly, before what we actually see in the search result is updated. So, for instance, I updated this tip to that if you are editing your page content with JavaScript, you need to be aware that it's very likely the first crawl Google will do, it will just grab the vanilla HTML without any additions, modifications made by JavaScript, and that will be indexed. And that could sit in the index then as we've seen in tests for days or sometimes weeks before the JavaScript amended version goes in. Doesn't necessarily mean the rendering is taking that amount of time.

That's my apology for my misunderstanding. I understand it's a pretty complex system apparently, this whole search engine thing. And it just highlights how careful we need to be when we're running tests and we're making assumptions about how certain parts of this huge infrastructure run. But the tips are there. I've tried to keep them up to date. Easiest way to find them is just do a Google search for unsolicited SEO tips. If you want them on a daily basis, if you want to come and talk to me about them, ask advice, tell me why they're wrong, correct me, I welcome that. Follow me on LinkedIn. I post one every day. And look forward to talking to you.

That's all I'm going to cover in this episode. It's been fun. If you're enjoying the podcast, as usual, tell a friend, subscribe, all that nice stuff. I will be back in one week's time, which will be Monday the 16th of August. Until then, I hope you have a lovely week.

More from the blog