Five things to look for in a Core Web Vitals report


What do you really need to be looking for in a Core Web Vitals report?

That’s what we’re going to be discussing today with a man who built his first online store when he was just 16 years old. Since 2011, he’s fully focused on SEO and is currently responsible for international organic visibility for a broad range of SEO clients. A warm welcome to the In Search SEO podcast, Jan Willems Bobbink. You can find Jan over at notprovided.eu. Love the domain name.

In this episode, Jan shares five key elements to improve your Core Web Vitals, including:     

  • The difference between specific segments   
  • Comparing different page templates     
  • Understanding the difference between Pagespeed Insights scoring and CWS scores   
  • Be creative   
  • Prioritizing page types by benchmarking against competitors

Jan: Yeah, I actually scooped a number of the not provided ones. I actually sold a number of local extensions to other SEOs. So when Google released the idea about not provided, it was quite popular, but I was quick at getting them.

D: And is this to appeal to yourself, and other SEOs, or do clients actually get it as well?

J: I think for me, most of my clients know what not provided is. So yeah, it’s a nice brand to be associated with it as an SEO. I can use it as a way to show what I can do for them as an SEO consultant. I can help them out with their SEO questions. One of them is maybe answering what’s behind the not provided segments in Google Analytics.

D: That was a long time ago now. I remember SEO back in the day where Google Analytics would show you every single keyword and then the not provided percentage crept up to 10%. And then suddenly, it went up a little bit more. When did it, I’m trying to remember, what year did it actually raise its head and really become a thing?

J: Ooh, I can’t remember. What I do remember is that people actually started to build trackers. On a weekly basis, they checked for their clients’ data, and then they shared it with the community, and then you saw it going up every week. Must have been like 2004, 2005, something like that.

D: So today, we’re talking about Core Web Vitals. So what is a Core Web Vitals report?

J: Yes, the topic for today is the Core Web Vitals report that Google is providing us as a way to get insights into how our website is performing for real users. Up until Core Web Vitals came into existence, we did have the PageSpeed Insights tools provided by Google, which was basically a one moment static test of analyzing how your page was loading in that specific case. Basically, it inside runs in your browser. And at that moment in time, with your connection settings, and all the things that come with your browser, you do a one-time check.

Then Google said that over time, we want to make sure that we serve our clients, our users, as best as possible. So we need to find a way to make sure that users have a positive experience on the websites that we present to them in our rankings. So they decided that they have access to browser data through Google Chrome and with the browser data, they can get a better feeling of how websites are actually performing instead of a one-time static test. So they’ve been experimenting with it. And it turned out, it was quite a good way of actually seeing differences between individual websites. So what they did initially was put it into the ranking system. And it turned out that it was a good way of measuring the performance of one site against another. And also seeing the relationship with users that were returning to search engine results based on a better or worse performance.

So that’s why they made it a ranking signal. Whenever Google says something is a ranking signal, you do need to be a bit careful. I tend to not take it too literally, because there’s hundreds of factors they can take into account. But what they did say, and I was quite amazed by it, was that it would be a tiebreaker. And with that, it means that let’s say your content is equally well written as your competitor. Your link profile looks quite similar, the authority of your domain or the history of your domain is quite similar, then the faster or the higher performing domain or the page will trump the worst performing page.

So in saying that Core Web Vitals immediately became a really focused topic for many of the SEOs because it was something you could measure. There are multiple tools for it. It’s data actually provided by Google to us, SEOs. And you can easily benchmark against your competitors. So in terms of making SEO more predictive, this was a gemstone that was provided by Google. Because until now, for factors like content or links, we don’t know if we do a better job than our competitors. But Core Web Vitals reports show data about us, but also about competitors. So there’s a clear way of comparing one website to another.

The other thing is that Core Web Vitals is measured through the browser. But before that, we were already used to using tools like PageSpeed Insights to actually optimize our websites to get a higher score on those kinds of tools. So the step from doing nothing and using equal websites as a metric to benchmark against competitors was a small one and for some SEO is an easy one to make. However, I think Google still makes it a bit complicated for many stakeholders in companies like marketing managers, because it’s still a technical topic to actually implement optimizations for. So I would say that’s the biggest challenge. And that’s why we have five points to discuss today.

D: So just to clarify, where can SEOs find this report?

J: Google has multiple sources. The most obvious one is if you check a page to page with Insight tools, Google does provide the data from the Core Web Vitals data set if it’s available. And that’s a good thing to remind you of that Google doesn’t share that data for all URLs. Usually, it only shares popular URLs. So you need to achieve a certain level of traffic to be presented in a public data set. That’s one way the Core Web Vitals data set is published every month.

The second way is by following their Twitter accounts, then you can see where they actually updated the public datasets. And the public data set can be used in any way you want. It’s basically a database that you can download, or you can couple to Google Data Studio templates as once you have it tied to your account, it will update every month automatically.

And the third most important way to see the data is in your Google Search Console. There in Search Console, there’s a report, Site Fidelity, that shows how certain groups of pages are performing for the three main Core Web Vitals. And that’s individual page and website data that are dated on the fly. The only thing that you need to take care of is that you understand the fact that it’s a 20-day average rolling metric. That means that if you implement something today, it may take 28 days to actually get into a mode where you can see the actual values at that point. That’s also why I tell clients to find other ways to keep on checking the data points. One thing you could do is measure the Core Web Vitals yourself on the fly and use Google Tag Manager, for example, to shoot them into your own Google Analytics setup. So instead of having to wait 28 days before Google updates the public datasets, you can measure the metrics themselves. So if you launch an improvement on your domain, then you can immediately see if the impact is positive or negative. Especially with all the recommendations that Google PageSpeed Insights gives, for example, or things you come up with yourself. Some things are counterproductive. So sometimes you focus on optimizing one of the specific metrics. And indeed that one improves, but then the other two will go down. What I usually do with the bigger clients is run an A/B test even for performance optimizations. Because you never know if your own development environment works out for your actual group of users of your website.

D: And as you’ve mentioned, you’re going to be sharing your five things to look for in a Core Web Vitals report. Starting off with number one, differences between specific segments.   

1. Differences Between Specific Segments

J: This all ties into my last point. It’s really important to understand the group of users you have on your website. The most obvious distinction is between mobile and desktop users. But what you don’t need to forget is you may have a group of people that have slow connections or fast connections. There may be a US-based group of people close to where you actually host your websites. Or next to that there’s a whole group of Indian visitors that need to connect from all different parts of the world. So they will have a completely different experience, they will have a different environment, and they will have different mobile phones, that may be much lower in processing JavaScript.

So what I’ve seen in the past few years working on Core Web Vitals is that you need to reach a threshold of at least 75% of your users having a good experience for those three individual Core Web Vitals. But what often happens is that the biggest bunch of your users have a good experience but then there’s a really small subset of users that has a really poor experience. And that subset of users is bringing the whole average number down. So sometimes you really need to dive in to see and identify the group of users that’s actually bringing the average down. Because solving it for that group of users will make you reach the threshold. So the whole idea of making really specific segments is that you find and understand which group of users has the worst experience possible and see what you can do about that. That could mean for certain devices you set up a different server or you recommend downloading the app or whatever. But since it’s all about averages, it’s good to find outliers. On one end, what are the devices and environments that get the perfect scores? And what are the outliers on the other side that have a really poor experience? And how can you optimize for that?

D: And number two, compare different page templates. For example, a homepage versus a category page versus a contact page. 

2. Compare Different Page Templates

J: One thing to keep in mind is that if Google doesn’t have enough page-by-page level data, it will look to the overall domain performance. But it does mean that if you want to optimize for the average of your whole website, you do need to segment on a page-by-page level. But as you can imagine, a whole page often has a couple of images, not that much text, but it’s fairly static so it’s easy to load and cache, etc. But if you have a category page in a webshop, for example, there are many more images, often lots of product data. There’s a completely different template and that may result in different scores on different levels.

What I often see is that people start optimizing for the obvious things that are present on every other page, like a header or a footer. But often the key to reaching your thresholds is more in the page-by-page approach. Meaning, you really have to dive into, for example, how the gallery page is performing, why the contact page is not performing well. Maybe the form on the contact page is dynamic pushing the page down causing a CSS shift. So when benchmarking, also against the competitors, it’s good to first identify all the different page types you have, the page templates that are with that, and compare those with your competitors. Because on the one end, if you go back to how Google is using the data, on a page-by-page comparison level in the rankings for a specific keyword, it checks out the performance of those individual pages against each other.

D: And number three, understand the difference between PageSpeed Insights scoring and CWS scores.   

3. Understand the Difference Between Pagespeed Insights Scoring and CWV Scores

J: Yeah, PageSpeed Insights should be seen as completely different compared to Core Web Vitals. Core Web Vitals are measured in the browser by actual users. Basically, PageSpeed Insights is a static one-time test at that moment in time. And the thing is, you can have a perfect PageSpeed Insights score of 100 and still have a poor Core Web Vitals score. So if you take all the optimizations that are recommended by the PageSpeed Insights scoring tool, you will get a 100 score. But if your server is still too slow or specific user groups have a slow experience, then you can still have a bad Core Web Vitals score. But it also works vice versa, because some of the recommendations done in the PageSpeed Insights scores are counterproductive for your Core Web Vitals scores. So you need to understand that one is a technical checklist and you get points for every item on the list that you can check. And then you get a high PageSpeed Insights score. Core Web Vitals are actually measured in the browser and represents our user is experiencing the data. So both datasets are useful to make the domain perform better. But you do need to make sure that you understand the differences between the sources of data and how the scores are calculated. Because on one end, what I see with most of the bigger websites that have perfect Core Web Vitals. They usually don’t score that high on PageSpeed Insights. But inside, there are exceptions. But if you look to sites like Amazon, don’t expect high PageSpeed Insights scores, but they do have perfect Core Web Vitals scores. Because performance is key for those platforms but they don’t care about a checklist based on PageSpeed Insights. It’s more about the actual performance and not about reaching a PageSpeed Insights score.

D: Which takes us up to number four, be creative. LCP elements are sometimes easy to fix by making the elements smaller.   

4. Be Creative

J: Just for understanding, LCP means Largest Contentful Paint. And with that, Google means that the time between requesting the page and the element that’s the biggest on the page is loaded. It needs to be below two and a half seconds. Because Google looks at how big certain elements are, what you can do is, I wouldn’t call a ticket, but you can have a good look at what the current element is that Google thinks sees as the biggest element. And if you can’t make that element load faster, let’s say you have a block, and you have a big header image in every individual article, and on a good day, your server is just too slow to serve that image within two and a half seconds. So instead of having the header image as the biggest element, you may want to increase the font size of your main H1 header. So the main heading of the page is bigger than your main image header. And by doing that, Google will detect the H1 text as being the biggest element. So instead of trying to speed up the current element that’s being seen as the biggest content piece, you can try to change the element that’s considered the biggest.

One of the things you often notice is that cookie warnings are considered as the LCP element. But cookie popups often take lots of processing time to actually pop up, because the browser needs to check if there is already a cookie installed, and it needs to check against previous visits, etc. and that takes time. So what I’ve done with a couple of clients is to minimize the amount of text in such a cookie banner. Then another element on the page is considered the biggest element, and then the whole score improves quite easily.

D: And number five, prioritize page types by benchmarking against competitors.   

5. Prioritize Page Types by Benchmarking Against Competitors

J: As we shared with point two, there’s often a big difference between different page types, but also in terms of privatization. Core Web Vitals are important, but it’s a tiebreaker. So there are other SEO activities that may bring in much more value for your clients. And understand that clients are really focused on core websites because they can actually understand it and measure it, which is not the case with other SEO factors. So what I try to do is show them by benchmarking against competitor’s rank for the similar keywords that they want to rank for. That there may not be a big difference between what they are doing and what the competitors are doing. I’ve had cases where when I did the benchmark, it turned out that they were doing better than all of their competitors. So it doesn’t make sense to put all the different resources on optimizing something that won’t bring any additional value. If you know you’re the fastest performing website in your markets, I would focus on content or links or whatever instead of having the expensive dev resources focus on something that won’t bring in any value at the moment. However, it’s good to keep an eye on that. So what I usually do is that the monthly data set updates by Core Web Vitals can also be used to track your competitors by setting up a dashboard that also brings in the competitor data every month. So you can at least keep a close eye on if your competitors are proofing that you need to make sure that you keep on being the best in the markets. But yeah, showing and being honest against your clients about how you’re doing compared to your competitors is valuable for every SEO.   

The Pareto Pickle – Optimizing Internal Linking

D: Great advice. Let’s finish off with the Pareto Pickle. So Pareto says that you can get 80% of your results from 20% of your efforts. What’s one SEO activity you would recommend that provides incredible results for most levels of effort?

J: That’s an easy one. I’ve gotten most of the quick wins out of optimizing internal linking. Many SEOs remember it. It’s a technique called second-page poaching, which originally came, I think, from Dennis Weaver when he was working with eBay. The idea behind it is that you’re looking into your Search Console data, for example, and see which pages are ranking around position 11-15 that have a low number of internal links pointing to them. So Google already understands those pages, it already ranks them, but just not in any positions that actually deliver traffic. So a quick win will be to add more internal links to those pages. And on the scale of eBay, you can automate that kind of thing.

The other thing is, that internal linking can often help Google discover your new pages. Again, for data websites, often the challenge is to get Google to the pages that are new or updated. So you may want to introduce dynamic elements within your pages that actually help Google find new product pages or new blogs written, etc. The other thing that’s often not looked at in detail is the whole internal link structure to begin with. Because most websites depend on their main navigation but forget about breadcrumbs, or forget about related products, or forget about the latest product uploads. So even for e-commerce, the default internal linking often looks okay. But if you download the whole website and check out the relationships between pages, there are often big gaps in it.

That’s why for me, one of the quick wins I always try to begin with is making sure that the pages that are most valuable get most of the links and also relay that value back to structure pages or related pages if it’s products or blogs, or whatever. And I think that’s an easy, quick win. And there are multiple tools. There are multiple WordPress blog plugins to use if you have a blog to start linking out to related blogs within your article or as a widget on the sites, etc. So yeah, even for smaller websites, I think there’s value in making sure that you point Google to the most relevant or new pages.

D: And I love your very specific advice there about how to go about selecting which pages to build more internal links to. Many people have shared for the section of the podcast internal linking as a quick win. But I don’t think anyone’s been as specific as you in terms of strategy of identifying pages that are ranking in 11 to 15, and then maybe I guess, overlaying that with the potential opportunity based upon keyword volume that you’re targeting for those keywords, and then prioritizing those internal pages based on that. So I love your very specific advice there.

I’ve been your host, David Bain. You can find Jan-Willem over at notprovided.edu. Jan, thanks so much for being on the In Search SEO podcast.

J: Thank you for hosting me. Have a nice day.

D: And thank you for listening. Check out all the previous episodes and sign up for a free trial of the Rank Ranger platform over at rankranger.com.

About The Author

The In Search SEO Podcast

In Search is a weekly SEO podcast featuring some of the biggest names in the search marketing industry.

Tune in to hear pure SEO insights with a ton of personality!

New episodes are released each Tuesday!



Source link

Related Articles