Welcome to our “Ultimate SEO Guides”. We want to provide readers with actionable insights with regards to different elements of SEO. We understand that our market moves quickly and therefore we have invited search professionals to help contribute to our SEO guides.
In the fifth instalement of our series, we are looking at the Ultimate Guide to Technical SEO and we have four authors who have helped produce this actionable and step by step guide:
Technical SEO is part of the “brilliant basics” of any SEO strategy. You may need to adapt how to implement the recommendations depending on the team and the website platform but it is one of the first elements of SEO that should be planned and incorporated when starting any project. Learning technical SEO can take time and is something that cannot done overnight. There are plenty of resources such as Blue Array’s SEO course and of course Moz. At Tea Time SEO, we tackled just a couple of crucial elements and our authors have shared their experience in the guide.
Technical SEO refers to the process of optimising your website for the crawling and indexing phase. The goals between technical SEO and other SEO channels are pretty much shared whether the technical SEO strategies are there to create solid foundations between both on page and off page strategies to work efficiently.
Before diving into technical SEO practices and how to complete audits, we go through the fundamentals, these being the understanding of how websites work, how search engines understand websites, and then how users interact with websites.
Computers are connected up to the web and called clients and servers. Clients can be defined as a user’s typical internet-connected device, such as computer, smartphone, tablet etc. Servers on the other hand store web pages, websites and apps. When a user types an address or a search query into a browser, a copy of the webpage downloaded previously is served on the client side to the user.
Search engines work by crawling billions of pages throughout the web using hyperlinks. So to do this, search engines will use their own crawlers as also known as search engine bots or spiders. Once a new page has then been discovered, it can then be rendered and indexed. Various authority and relevance metrics are then scored to ensure that the most relevant results are then retrieved against the search query in the search engine.
However, as there’s been a huge rise in JavaScript powered websites, Google realised it had to start rendering web pages more like modern browsers. So back in 2018, it introduced the second wave indexing. If a page has JavaScript in it, the rendering is actually deferred until Google has the resources ready to then render the client side content and then it will index the content further a bit later.
Search engines have some of the most intelligent data mining operations and algorithms than any other piece of technology. They continually collect data to understand an individuals behaviour and help their displayed output become more user-centric. It’s crucial to understand the intent behind queries by dissecting the language used, enticing users to click on your web page, breadcrumbs and a clear navigation, fast site speed and creating a seamless user experience.
Be a lot more human during your auditing process. It’s always encouraged to manually audit your site, so just in the way that a Google bot and users would interact with your site and navigate it, try to get familiar with the site as a whole. Look at the overall site architecture, high value, low value pages, how’s the internal linking working, and get a feel of it there. Then try and identify different technologies that the website’s built on, for example use the Chrome extension Waffleizer to quickly have a look at what our website is built on. Then analyse what tools will be best to use to crawl the site.
Continue to troubleshoot the site from accessibility, crawlability, indexability, all these different areas of the site, and then always make it bespoke to every single audit.
It’s also really important to understand who you are actually delivering your audit to. This will help to really structure your recommendations. If it’s being delivered straight to a developer, these recommendations should be incredibly concise and actionable. However, if it’s being delivered to other stakeholders, who may not come from a technical background and might not have a real understanding of SEO, then include the reason for the recommendations. For example, the return on investment, or talking around the KPIs that the recommendation is looking to tackle.
Don’t worry about what others are doing. Try and not be fazed by those around you that may have more experience or have been in the industry a lot longer than you. Technical SEO as a whole is pretty much a learning curve and comes with all the analysis that you complete. Technical SEO is self taught, you do not learn it at university. No matter if you’re working in an agency, in-house, freelance, try and audit as many sites as possible, whether that be utilising a crawling tool, manually auditing, or a combination of both. This will then give you exposure to a range of issues, range of websites, that you can then look out for in the future, and then also lean on others around you.
Technical SEO is a discipline, it’s something that can’t be taught overnight. It’s ever-evolving, and knowledge comes with time, so keep at it, keep updated with all the different industry news. Twitter is great for that. Take the time to really empower those around you, as diverse thinking really does breed creativity in all senses of life, as well as technical SEO issues. Reach out and explore the incredible communities out there, such as Women in Tech SEO. Good people will always want to help answer your questions and you in turn can help provide the answers to theirs. Technical SEO is never finished and there is always something new to learn.
Unlike many other SEO changes, it can be tricky to get technical SEO improvements implemented; more often than not they require input from developers, who are often quite a stretched resource who have to triage requests from all aspects of the business. So, we need to plan our approach to implementations to make sure they get to the front of the queue.
At our agency ‘Erudite’ we tend to be successful when we take a two-pronged approach to communicating the technical SEO recommendations:
The first ‘prong’ of the Erudite approach will aim to communicate the value of the request in terms of the site performance improvement it will have. When deciding how to prioritise development tasks, it’s much easier to bump a task up the list if it’s clear it’s going to have a tangible performance benefit.
For example, suppose you’d like to implement structured data on your product detail pages to target featured snippets like this:
(They’re magnificent by the way)
It may be tempting to provide a code sample to be implemented on all product detail pages or send a link to Google’s product structured data implementation guide. While this may technically be enough for your developer to get the job done (although sending them a link might be a bit of a pain – your developer probably doesn’t want to have to become a structured data expert before they can start), it doesn’t do a good job of demonstrating why you’re making the recommendation or why it should be a priority. So how could you communicate this request in a way that really sells its value?
Presenting your idea in a hypothesis framework makes it much easier to ground your recommendation in the context of how it will improve the site, and the tangible effect it may have. A hypothesis framework for a product structured data request could look like:
This framework explicitly shows what you hope to implement, why you want to, and a tangible measurement of the benefit to the business.
However, it’s not always easy to estimate what the performance increase of an implementation like this could be until it’s actually complete. Luckily for many technical SEO tasks (canonicals, structured data, hreflang etc.) it’s straightforward to run small scale tests using Google Tag Manager. Test the recommendation on a handful of URLs, monitor the performance of these URLs against the rest of the site and use this as the basis of your estimation.
Sometimes it’s not possible to estimate the potential impact of the recommendations; maybe you can’t use GTM to test, or you may be preparing for a Google Core Update (for example, it’s a good idea to start addressing Core Web Vitals now, ahead of them coming into play next year, but there is no way of telling how much they’ll impact rankings until then).
In this case, it can be useful to present support from Google’s (or another Search Engine’s) documentation, or a piece of third-party research that shows the task’s importance.
Now you’ve presented the recommendations in a way that should help it become a priority, the next step is to ensure you’re making the work as appealing and straightforward as possible, so that developers can easily pick it up and complete it without having to do huge amounts of background research, without the risk that’ll you’ll need to make amendments or revisions once it’s complete.
Going back to the product structured data for our Halloween Crocs. Rather than sending a code example and asking our developer to implement it on every page of the site, there are a few things we might want to consider.
For example, are there any products that you don’t want this implemented for? Many sites include product widgets on content and product detail pages (under a ‘Related Products’ block or similar). It’s likely you only want to implement structured data for the main product on a page, so you need to make sure you’ve identified these caveats and pointed them out.
Or perhaps the developer is particularly busy at the moment, and won’t have time to dynamically create structured data on each page for some time. If you only presented your solution (to have this dynamically created for each page), you might have to wait a long time before it would be implemented. However, if you explain what you are trying to achieve and work with the developer to find a solution, it may turn out that they could create a free form meta field in the CMS that allows you to paste in your own JSON-LD in much less time.
If your recommendation lends itself, it can be helpful to provide code samples for your developer to work from. Canonicals, structured data and hreflang tags are all great examples of implementations where you could provide your developer a code template as a starting point.
Other tasks may be trickier to put together a code sample for, so try to point out some other sites or pages that are good examples of what you’re aiming for.
Finally, make sure your recommendations are realistic. Take some time to understand how complex your request is going to be to implement, and work with your developer to see if you can come up with a sensible compromise or middle ground. You may have the ‘perfect solution’ in mind, but often sites don’t need highly complex ‘perfect solutions’ to see results (‘good enough’ is often good enough!). Consider whether the time and complexity of your task will be outweighed by the benefits or whether there are more straightforward recommendations you could focus on.
While the Tech SEO recommendations are being implemented you can continue to maximise the assets you already have. One of these is Google Shopping which is a must for any eCommerce site. Hamlet Batista shares his recommendations with us on Tea Time SEO.
In June 2020, Google began listing products alongside Google Shopping results for free. This means that your products can be listed in the Shopping tab of Google results at zero cost per click. Your products will also be eligible for product knowledge panels like this:
However, there is some up-front setup needed for Google Shopping to list your products.
Here is how you can get started:
Product images are critical for online conversions, but they can also drive traffic to your site. Google displays image search results alongside the regular organic results. Some sites find that up to 10% of their traffic comes from image searches.
Here are some tips to optimize your images for search:
Also check Google’s detailed guide to best practices for images.
If you are not already using schema.org markup on your pages, you should be! This is a topic that is well-covered elsewhere, so this guide will just highlight a new type of schema for shipping data.
The shippingDetails schema will make it possible for Google to display information about your shipping in the search results. This is an opportunity to highlight free shipping to users. Here is an example from the recent Google Webmasters announcement:
Here are some best practices for implementing this type of schema:
Google’s guide to product schema contains example code. See more details on schema.org.
If you have physical stores, local search results can be a way to drive sales at your retail locations. Customers search for not only the name of stores that they plan to shop at, but also for types of stores and products that they need. Hopefully, you rank well for your brand name, but what about for “kitchenware near me,” “appliances near me,” or “furniture near me”?
Follow these tips to optimize for local search results:
Visit Practical eCommerce to learn how to create a Google Product feed from XML and Search Engine Journal goes into detail about generating text from images with python here.
Core Web Vitals is not just about page speed!
It is a combination of page speed optimization, safe-browsing, adoption of proper monetization policies and ad placements within the context of the Page Experience algorithm and score.
Core Web Vitals has different thresholds to pass in each of these areas in order to get a passing grade from the Page Experience Algorithm.
A page optimized for Core Web Vitals can be effectively ‘labelled’ as providing a “Good Experience” within the scope of Google’s Page Experience algorithm and help it to get a better ranking for competitive queries.
In this article, definitions of Core Web Vitals elements, optimization methods, and instructions for preparing a website for the Page Experience algorithm will be explained.
Core Web Vitals Representation and Thresholds
Core Web Vitals elements that need to be optimized within the scope of the Page Experience Algorithm of Google are listed below.
To optimize Core Web Vitals, Pagespeed, User Experience, and Web Security should also be optimized. In this section, advice for optimizing for Core Web Vitals also includes these three different aspects (Pagespeed, Safe Browsing, and User Experience) and their related sub-sections.
A Core Web Vitals metric that measures the occurrence of the largest content elements in the viewport is the Largest Contentful Paint (LCP). This can be used to determine when all the content of the page has been rendered. Slow server response times are the most common cause of poor LCP.
To optimize Largest Contentful Paint (LCP), the related page speed metrics should be optimized too, such as First Paint, First Meaningful-Significant Paint, or Time to First Byte.
A page speed metric might not be included in the Core Web Vitals directly, but in an indirect way, they can affect the direct Core Web Vitals signals such as User Experience. Every page speed metric is connected to another one in terms of page loading performance, thus the Largest Contentful Paint optimization in the scope of Core Web Vitals should be evaluated with related page speed metrics and not in isolation
The largest Contentful Paint has 25% weight for the end score of the Lighthouse Pagespeed Test in the v7.
The second most important Lighthouse page speed metric is the Total Blocking Time with another 25% weight, but Total Blocking Time (TBT) is not included in the Core Web Vitals since it can’t be measured in page speed tests in a proper way. Total Blocking Time can be understood correctly via Real User Metrics (RUM), not with the lab data. Thus, unlike Largest Contentful Paint, it is not included in the Core Web Vitals. In this context, Largest Contentful Paint is included in the Page Experience Algorithm within the scope of Core Web Vitals (CWV), not just because it is effective, but also because it can be measured without the need of RUM. For a Search Engine, it is easier to measure, but also it has a contextual functionality for evaluating the web page.
Largest Contentful Paint is important for the initial contact section of a web page, and above the fold section of a document. The largest visible element of the initial contact section of a webpage also identifies the web page’s purpose, characteristics, and relevance for certain queries, or industries. So, in other words, LCP is a metric for page speed, but Largest Content (LC) is also a contextual signal for the search engines.
Also, the initial contact section of the web page communicates with the users to define the purpose of the web page. To understand the importance of web page layout and its meanings, signals for search engines you can read the related documentation. And, a slow LCP might dilute the context of the web page layout or the initial contact section for users’ perception, and indirectly search engines.
To determine the LCP Element of the web page, the browser tries to choose the biggest “HTML div” element. But, also visual completeness and being visible are the most vital factors to determine the Largest Contentful Paint element. Knowing how the LCP Element has been chosen is helpful for optimizing LCP and understanding the browser’s working principles.
LCP Elements can be chosen among the HTML Element types below.
In the future, video and SVG elements will be accounted for in the LCP determination.
To optimize the Largest Contentful Paint, the methods below can be used.
The main reasons for the slow LCP are listed below.
The largest Contentful Paint (LCP) has been announced at the end of 2018 within the Github Lighthouse repository. But, it was not an official announcement. It has been used during the development process of these new concepts of page speed.
The next sentences will include opinions about the process of the LCP announcement.
In 2019, Bartosz Goralewicz published a video and announced that LCP will change page speed optimization in the future. I was one of the first people who watched this video. And, I must thank him for publishing this awesome and brief video. During the coming weeks, I have researched the Lighthouse repository of Google on Github to learn more, and I have written an article called Advanced Page Speed Metrics, because “Core Web Vitals” was not a concept or term at this time. I think this was one of the first articles about Largest Contentful Paint and other new and modern page speed metrics.
LCP Thresholds are listed below.
To have a passing score for the LCP, 75% of the users should experience a faster LCP than 2.5 seconds in the Chrome User Experience report.
Despite every page speed optimization methodology, if the LCP couldn’t be optimized, changing the LCP content can help. From an image to a text, or to another image the LCP scores can be optimized. And, sometimes changing the design, the layout, or removing some unnecessary web page weights can help to optimize LCP. So, if you can’t optimize LCP for an LCP Element, you can change the element itself to optimize it.
First Input Delay (FID) is related to the load responsiveness. FID measures the time difference between the input of the user and the event that happens after the input. FID is important to diagnose the web pages that are not responsive during the web page loading process. A web page can be loaded fast, but still, it might not respond to the user’s interaction. In this context, loading the content fast wouldn’t have a meaningful impact on the user experience.
A representation of the first input delay
During the web page loading process, many CPU bottlenecks can happen. If there is no proper compression, minifying, or resource load order optimization for a web page, the main thread of the browser can have bottlenecks. This situation prevents the web page from responding to user’s interactions.
If there are too many long tasks (tasks that are longer than 40ms), the first input delay can happen more. And, if the long tasks happen frequently during the web page loading process, the FID can happen continuously, and the web page might not be able to satisfy the visit intent of the user.
Note: The event itself is not included in the First Input Delay measurement. Only the input and reaction time difference is included for the FID measurement.
Even if there is no FID data within the lab tests, you can check the Long Tasks from a web page speed and loading performance test.
If there is no input on the web page, there is no measurement for the FID. Every input doesn’t create an input latency or input delay. And sometimes, users do not interact with the web page in terms of input events. In this context, if there is no input event, there is no input delay, and there is no FID Measurement.
Note: The sessions without an FID Measurement won’t be included in the FID Score calculation.
The related page speed metrics for FID are listed below.
Time to Interactive measures when the web page is fully responsive for any interaction from the users while Total Blocking Time is the sum of the Long Tasks during the web page loading process. TBT, FID, and TTI are the page speed metrics for the loading responsiveness and runtime responsiveness.
The thresholds for the FID are below.
To pass the FID Score threshold, 75% of the users should have a good FID experience in the context of Core Web Vitals.
The input elements are listed below.
Note: Scrolling and zooming are not measured in the FID. Because scrolling and zooming are not input events.
Methods to optimize First Input Delay have been listed below.
FID is an important user-centric web page loading performance metric because it measures the responsiveness of the web page. Every query has a need behind it. Every click on the SERP has a purpose. And, to satisfy the needs behind the query, and clicks on the SERP, a web page should be able to respond quickly. Even if the page is fast, the content is high quality and the source is reliable, it all counts for little if the web page cannot be used properly, as it cannot satisfy users.
FID is insurance for the Search Engines to keep the SERP full of high quality pages that can respond to the users. And, if a web page cannot respond to the users, its quality or reliability can be hindered in the eyes of the search engine, since it is not as useful to a user as it could be.
Paul Irish from Chrome Dev Summit 2018 while showing the concept of First Input Delay
Cumulative Layout Shift is to measure the layout shift of the web page elements during the lifespan of the webpage and a user’s session. Cumulative Layout shift is a user-centric web page loading performance metric that focuses on visual stability. And, any moving web page element after being loaded and being visible will be included in the Cumulative Layout Shift (CLS) measurement.
Cumulative Layout Shift can be measured by the Layout Installability API. Below, you can find the CLS Formula for measuring it.
layout shift score = impact fraction * distance fraction
To understand how to measure Cumulative Layout Shift, the Impact Fraction and the Distance Fraction terms should be defined.
A representation of the Cumulative Layout Shift
CLS is a way to measure layout instability by looking at how much of a visual area of the screen is impacted as the page changes when loading.
It does this in 3 stages; firstly by measuring all elements that shift on the page; and secondly by measuring the Impact Region (comparing the visual area before and after) and finally by comparing this to the viewport.
Impact Region / Viewport = Impact Fraction
So, Impact Fraction measures how much the page moves in relation to the size of the screen that the website is being loaded on. This is important as a big movement on a small screen is far worse than a small movement on a big screen.
As an example calculation for the Impact Fraction, if a web page element covers 30% of the screen, after the layout shift event, the web page element’s new position and old position will be unified, and the screen coverage ratio will be measured again. In this context, the new and the old place for the same web page element can have 60% of the screen at the top. And, it means that the impact fraction is 0.75.
In this context, because of how big the web page element is, the layout shift will create greater Impact Fraction.
Impact Fraction Example from Google Devs
Distance fraction is not related to the size of the web page element or the area that it covers, but it is related to the distance from the web page element to the viewport’s edges according to its biggest dimension. For instance, if a web page element is higher than its width, its layout shift event’s distance fraction will be measured based on the vertical distance.
As an example calculation for the distance fraction, if a web page element is at the top section of the viewport, the web page element’s height is greater than its width, and if it moves 30% to down during a layout shift event, its’ Distance Fraction score will be 0.30.
In this context, if the Impact Fraction isr 0.75 and the Distance Fraction is 0.30, the layout shift score will be calculated as below.
Layout shift score 0.225 = 0.30 (Distance Fraction) * 0.75 (Impact Fraction)
Cumulative Layout Shift Score is the sum of all of the layout shift scores.
Distance Fraction example from Google Devs
The Cumulative Layout Shift Thresholds are listed below.
Note: Cumulative Layout Shift can happen in the direction of vertical moves or horizontal moves.
Cumulative Layout Shift Thresholds from Google
No, not every layout shift is not included in the CLS measurement. Only the unexpected layout shift events will be included in the CLS measurement. If there is a layout shift based on expected user behavior such as clicking, or hovering, it is an expected web page behaviour for the user interaction and therefore it doesn’t bother the user.
Thus, Layout Shift events can be categorized into two sections as unconditional layout shifts and conditional layout shifts. The conditional layout shifts happen after a certain user interaction within the scope of acceptable standard web behaviours. Even if a page speed measurement tool says that a conditional layout shift has been included in the CLS, the developer and the SEO should know that it is not a problem as long as it makes sense for the UX.
This is a conditional and expected CLS example
The reasons for CLS are listed below.
To improve the CLS score, the following methods below can be used.
To improve CLS you can check the Cumulative Layout Shift Guide.
To observe Cumulative Layout Shift, you can use Google Chrome’s Performance Tab and Experience sub-tab. When you click on the Experience tab, it will show all the Layout Shift, and Long Task or Input events. And, if you click one of the Layout Shift events, you will see that it shows the layout event’s position changes and it overlays the web page element that has shifted.
To observe the Layout Shift during the web page loading process, follow the steps below.
Cumulative Layout Shift is important because it shows the visual stability of the web page elements during the web page loading process. CLS is not related to the page speed, but it is about the web page element’s position changes. Layout shift events can create stress for the user by resulting in the wrong and/or unwanted clicks or events.
A high cumulative layout shift score signals to a search engine that even if the web page is fast, quality, reliable and responsive during the loading process, it can create stress and harm the users. Thus, a high and bad CLS score could result in a search engine ranking drop.
Hypertext Transfer Protocol Secure (HTTPS) is the secure version of HTTP. HTTPS provides a secure and encrypted data transfer. HTTPS is important to transfer data in a secure way, especially for e-Commerce sites, email services, banks and insurance providers. If a website uses login credentials, it should definitely use HTTPS. There are different types of SSL Certificates such as Company Level HTTPS, or regular SSL Certificates. On 7 August 2014, Google published a blog post and made it clear that HTTPS was a ranking signal.
Google also published a new tool for safe-browsing. And, if a website includes malicious code or malware, Google Chrome can flag the website, and Google can remove it from the SERP.
Google has many products, but every product of Google represents its vision that every SEO should follow, learn and understand.
TLS or Transport Layer Security is the formerly known Secure Sockets Layer (SSL). TLS ensures that the communication between the server and the user can happen via Private and Public Keys. The Public Key is open to anyone, and it is used to encrypt the information on the server, and the private key is controlled by the server, it is used to decrypt the information that has been encrypted by the public key.
For Google Chrome, TLS 1.0 and 1.1 have been deprecated in 2019. A website should have a laterTLS version than 1.1 to be used within Google Chrome after version 72.
To check the TLS Version for a website, you can follow the steps below.
Below you can see an example of TLS version check with Google Chrome.
HTTPS is important for secure and private browsing. HTTPS was announced by Google using the slogan of “HTTPS Everywhere”. As a ranking signal, HTTPS is increasing its importance every year. Using a fast and secure HTTPS will help websites to thrive on the SERP. IT’s table stakes for all websites.
If a web page contains high quality content and is trustworthy, fast, responsive during the loading process and visually stable but it is not safe, Google won’t consider the web page as a proper candidate for the given query.
To pass the Core Web Vitals assessments, websites should be mobile-friendly. A mobile-friendly design has three main components.
A Mobile-Friendly Test Tool Result example from “Am I Responsive”
A web page can change its elements’ sizes according to the viewport width of the device or the browser. Responsive design is helpful to keep the content the same on different devices. To keep a web page responsive, different CSS properties can be used, such as “media queries” or “clamp”. But in terms of page speed, and usability, using a single line of CSS code for all of the layout is more useful in terms of visual responsiveness.
Responsive Web Design Announcement and Guideline from Google
To keep a website responsive, knowing the most used screen widths are important. The most used screen widths for desktop devices are below.
The most used screen widths for mobile devices are below.
Data Source: Statcounter
An SEO, UX Expert, or Developer should test all of these screen widths for responsiveness to pass the Core Web Vitals Assessments.
Lastly, responsive design is not just about viewport width! I recommend you to watch Una Kravets from Google I/O 2021 Event.
The common mobile design and mobile-friendliness mistakes are listed below.
To test a web page’s mobile friendliness, the tools below can be used.
In the mobile-friendly test tools, a search engine can show a webmaster how it perceives a web page, and what it could crawl and digest from the webpage. Also, Google Analytics, or Adobe Analytics data can be used to examine the mobile-friendliness of a web page, by analyzing the audiences. Hotjar or Clarity can be used to record and watch the users’ sessions.
A Mobile-friendly design example from the Search Engine
The mobile user and mobile traffic percentage change from year to year, but in 2018 desktop user and traffic percentage have been exceeded by the mobile user percentage. Today, mobile users and traffic percentage are 54%, according to Statistica. Based on Perficient’s data, the mobile user percentage is 68.1%. But, due to the pandemic conditions, the desktop user and traffic percentage have increased.
Google has switched to the mobile crawling scheme for all of the websites. In 2018, Google announced mobile-first indexing. In this concept, Google has given more weight to the mobile version of the web pages for ranking. In 2021, Google has switched to mobile-only indexing, in other words, if the content doesn’t exist within the mobile version, it won’t be evaluated by Google.
Mobile-friendliness is important because most of the users are using mobile devices for browsing on the web. And, if a website is not designed with the mobile-first design mentality, it might create a frustrating experience for most of the users. Even if a web page has good, quality content, and it is secure, fast, responsive during the loading, and visually stable, if it is not usable by the users, it won’t be considered as a quality web page by the Page Experience algorithm in the context of Core Web Vitals.
To pass the core web vitals assessments, proper monetization is important. In 2021, Google started to publish “Monetization Policies” videos on YouTube. Monetization Policies include “invalid clicks and impressions”, “encouraging clicks or views from users”, “abusive experiences” and more. Most of these monetization policies are about ad publishers’ mentality and behaviour on the web. In the context of the Core Web Vitals, the proper ad experience for the users is important. If you deceive users, then Google will discover this and penalise you.
To use ads in a user-friendly way, ensure the ads do not cover all of the above-the-fold section of the page. Every screen of a web page during the scrolling shouldn’t have more ads than 30% of the web page. To keep the ad relevant to the web page, a website shouldn’t use interstitials or too many repetitive ads that are irrelevant to the topic.
Natural ad placement is important to keep a web page profitable and also user-friendly. In fact, banner blindness can happen in the case of an excessive amount of ad usage.
Against aggressive monetization, Google has published the Page Layout Algorithm. The page layout algorithm of Google especially targets the excessive amount of ads on the above-the-fold section of the web pages.
And, today we have the Page Experience Algorithm, it is similar to the Page Layout Algorithm in the context of monetization. Google has improved its concepts and algorithms’ configuration to differentiate between the excessive amount of CTA Elements or Banners within a web page.
An announcement from Matt Cutts for the Page Layout Algorithm from 2012
To learn more about the Page Layout and the importance of context, you can read the importance of context for SEO Case Study.
If a user can’t see the main content of the web page because of the excessive amount of ads, it means that the web page can’t perform its purpose in the context of the search intent of the user. If a web page doesn’t let the user interact with the main content by displaying a pop-up, or irrelevant ads, forms, and CTAs, it means that the web page is abusing the user and the search engine’s decision tree.
An excessive amount of ads on a web page can oppress the context of the main content, this situation can create a contextual dilution, and it can make a Search Engine think that the web page is actually about something else. Thus, using relevant ads with optimized placement is important to keep things consolidated and congruent.
Page Layout Algorithm Announcement from Google in 2012
In the past, Google has published a tool to audit the web page layout to help webmasters to organize their web page layout for the benefit of the user experience in the context of ad placement. This tool basically says users prefer fewer ads and a greater distance between ads.
If a web page includes an ad for a harmful industry, brand, or non-reliable product or organisation, this situation can harm the web page’s performance. Ads are part of the web page’s content. They should be secure, logical, honest, and legitimate. In the Core Web Vitals assessments, you should also care about the ads’ content, along with their impact on the user experience.
In the context of Core Web Vitals, proper monetization is important because an ad can harm a user with its content or its effect on the web page layout. It can suppress the main content and prevent users from focusing on the main search intent. It can distract the audience, and delay their interaction with the web page.
Even if a web page is secure, fast, visually stable, responsive during the loading process and mobile-friendly, if the web page has a harmful ad or bad ad placements, the web page won’t let users perform their purpose during their session. Thus, a web page with bad monetization practices can be dropped from rankings in the context of Core Web Vitals.
Google’s Monetization Policy Starting for Content Publishers.
Core Web Vitals is the conceptualized version of a Good Page Experience. A secure, fast, relevant, and responsive web page can satisfy a user, and Google tries to improve the SERP Quality with this conceptualization and Page Experience Algorithm. Also, Core Web Vitals heavily focus on web pages’ speed, and a faster web page means also a cheaper web page to be crawled. In both ways, Google improves its internal economics and SERP quality.
The Page Experience Algorithm is likely to change over time. Its content, ranking signals, the weight of these signals over time, and all of these page speed metrics, or security measurements can change their definitions or measurement methodologies, so as SEOs we should all follow the state-of-art level information to keep SEO Projects ready for these future changes.
Finally, I’m passionate about Core Web Vitals as they are so closely connected to my day-to-day work at Holistic SEO, as it’s not just about page speed, it is related to the different verticals of SEO such as coding, user experience and security. And, anything that relates to the SERP and rankings is under the umbrella of SEO.
If you’ve got this far then you must also share my passion for technical SEO. If so, come and join me and other fellow optimisers in our community for a chat about all things Core Web Vitals and tech SEO.
We have only just touched the surface of Tech SEO in our first part of the Tech SEO guide. If you would like to contribute to it, reach out to us at marketing@authoritas.com.
The technical part of any site should ideally work hand in hand with Off-page SEO and On-page SEO which we have talked about in our guide. Technical SEO is the foundation of any site, if you do not have your “ducks in a row” and do not have a healthy site, then it will be difficult to appear higher in the SERPs generate more visits and sales. Depending on resources, some tech audits can take anywhere from 1 to 5 days or sometimes even longer. Therefore it is important to not compare your site with others, instead, focusing on maximising the performance of your site with the time allowed.
Learn Technical SEO tips and tricks from our blog to help you build the most efficient website.
Try Authoritas for free today and crawl your website to see where changes need to be made.
Or, get in touch with our team and see how our software can make your job easier and take your website to the next level.
Georgie is a Technical SEO Executive at Vinterior. Georgie has a fascination around digital innovation, growth marketing, and marketplace SEO. In her spare time, you’ll find Georgie volunteering at Nottingham Women’s Centre or reading empowerment books.”
Jess has a background in traditional marketing, having worked in both B2B and B2C roles before specialising in digital in 2016. Jess spent 2 years as a Senior Technical SEO Consultant at Erudite before becoming Account Director, and particularly enjoys working cross-discipline to find lucrative opportunities for clients.
Hamlet was the founder and CEO of RankSense. He had a Technical SEO background with an emphasis on ecommerce and was a big part of the search community. Hamlet invented RankSense, an app to simplify implementation of SEO fixes using Google Sheets. He will be missed by all.
Koray believes that SEO is the intersection of Marketing and Coding with a creative mind and growth hacking love. Therefore his symbol is “” which means “Marketing” as a web component with HTML Tags. He spends his time learning new things and methods, working on his coding skills, attending meetings, and educating his team. In the future, he will be publishing a new SEO Case Studies with the things he loves most about SEO!
Featured image by Christian Wiediger on Unsplash
