Evaluating page experience for a better web- How to make sure your site doesn’t get penalized by Google’s new policies

5 min read

As a part of an aim to give users a better experience, information giant Google has provided a set of metrics that would determine and measure how web users consider the experience of interacting with a web page.

This change is signaling that Google will favor websites in rankings that are safe, mobile-friendly, and have less loading time.

According to Google, great page experiences will help people to more valuable information and engage more deeply. By adding these metrics, Google aims to help more people easily access the information they want, while practically “shadowbanning” sites that have lower ranks in terms of page experience.

Google has announced this development in May 2020 and the gradual rollout of this feature has started this month, June 2021.

Right now, the current metric (Core Web Vitals) for page experience are:

1). The largest Contentful Paint (LCP)

is used for measuring the site’s perceived loading speed. The higher the LCP is, the better because it signals the perceived usefulness of the page.

2.) First Input Delay (FID)

is used for measuring the site’s load responsiveness. A developer would want a low FID as that would mean that the webpage is usable.

3.) Cumulative Layout Shift (CLS)

is used for measuring visual stability. Low CLS for a site is a sign that a page is delightful to use.

Industry experts have reported that by June to August 2021, Google will start rolling out four more benchmarks to the system, namely;

  1. Mobile-friendliness,
  2. Safe-browsing,
  3. HTTPS, and
  4. No intrusive interstitials.

So how could developers make sure that their sites would not be affected by these updates?

We will talk intensively about the four new updates in this post.


Make sure that the site is mobile-friendly:

Mobile devices account for almost half of the web traffic worldwide. If a site is not mobile-friendly, it might be difficult for it to be viewed and used on a mobile device, which users often find frustrating.

Step 1 is to ensure this is using Google’s Mobile Friendly Test to test the developer site’s mobile friendliness.

If the developer’s site is mobile-friendly, then they can rest easy.

However, if it is not, it could be due to a web layout that is not optimized for mobile, resulting in texts being too small to read and links that are situated too close together. To mitigate this problem, the developer can choose from the following options:

  1. Responsive web design (recommended by Google)- this means the same website and the same URL, but the page automatically adapts to the layout of each device. This means the developer does not need to go back and recreate everything from scratch. This option is easy to maintain and easy to implement. However, this might not be an option for some developers that need to have a specific user interface among devices.
  2. Creating a mobile version- this method is utilized by most social media sites, notably by Facebook. To create a mobile-friendly version, the developers would create another domain on their webpage that only caters to mobile users (i.e., m.facebook.com instead of facebook.com). That means the developers still get to control the user interface and branding without sacrificing mobile-friendliness.
  3. Dynamic serving- this means every time a device accesses the site, a custom page shows up specifically for that device. However, this option can be more costly than the responsive web design as the developer needs to create specific HTML sites depending on the mobile device.
  4. Have an app- this is also one alternative for mobile users. This might be more costly, but you will have complete control over user experience, features and this is the best option for mobile.


Advocate Safe Browsing

 and make sure the developer page does not contain hacked content, malware, or social engineering. Once Google determines that the developer’s site is unsafe to use, they will automatically display an interstitial warning page preventing a user to move on further. It will also show up on the Google results section, practically preventing traffic on the developer site.

To prevent this, the first step is to check the developer Security Issues Report here. If the developer site is secure, you will see a green checkmark at the top of the report, but if it is not, you will see a count of all security issues.


What are the steps to be taken to fix a security issue on the developer site?

  1. Go back to the Security Issues Report and expand the issue description, read the description, and follow its “Learn more” link for more information.
  2. The developer can use the sample of affected pages provided in the details section to fix the issue. They will need to fix the issue throughout the developer’s site.
  3. Then, you will need to test the site’s fixes. When all issues listed are fixed, the developer will need to send a reconsideration request. These reconsideration requests should explain the exact quality issue on the developer site, describe the steps taken to fix the issue, and document the outcome of their efforts to fix the site. Reconsideration reviews may take some time and Google will keep the developer posted on the status of the developer request. The developers will have to wait for a final decision on the developer’s outstanding request before they can resubmit another reconsideration request. This might take several dates or weeks.


Security is critical, and so is HTTPS.

HTTPS ensures that there is secure communication between browsers and servers. In 2014, Google announced that HTTPS would pose a small percentage in calculating customer experience, but that was before technology for an easier shift in site migration from HTTP to HTTPS was developed. Now 7 years later, the need for security is one of the top priorities of a user, and therefore it will largely impact the overall user experience. If the developer site is still using HTTP, it might be time to consider migrating to HTTPS.


What are the best practices when implementing HTTPS on the developer site?

  1. Use strong security certificates- get the developer certificate from a reliable certificate authority.
  2. Next, make sure that the developer sites can be crawled and indexed by Google. Use the URL Inspection tool and test if Googlebot can access the developer pages. Do not block the developer HTTPS pages by robots.txt files, and make sure that noindex tags are NOT included in the developer HTTPS pages.


Minimize or remove the developer site’s intrusive interstitials.

 No one has ever heard of users being glad that their computer or phone screen is populated by interstitials or what is commonly known as pop-ups. Most pop-ups will now be penalized by Google, except for a few select ones, which are namely, Age Verification pop-ups, Cookies that use pop-ups, and Legal pop-ups or password-protected sites. Any other interstitials will impact the site ranking negatively.

  • To avoid Google penalties on site, the developer must audit the site’s pop-ups, which means removing those interstitials that can cause penalties.
  • Second, make sure any ads on the site do not obscure the view of the content.
  • The third is to test different versions of the pop-ups, including how it will look across different platforms.
  • Fourth, the exit signs to the pop-ups should be clear, responsive, and should not trick the user into clicking a link to another site.

Basically, the aim here is to make the user experience seamless and enjoyable, and it should help the user get the information they need in the least amount of time.

With millions of sites on the web to compete with, make sure the developer site is in tiptop shape before Google fully implements the New Page Experience Signal.

Sarkar SEO
[email protected]

Mohit Parnami aka Sarkar is an entrepreneur, marketer and Co-Founder of SarkarSEO. He is passionate about SEO and lifelong learner to learn new things. He has been in the internet marketing industry for 10+ years.