Page Experience Signals Beyond Core Web Vitals

When Google introduced the Page Experience update in June 2021, the industry’s attention focused almost exclusively on Core Web Vitals—LCP, CLS, and the metric that would later become INP. This narrow focus overlooked the fact that Core Web Vitals represent only one component of a broader page experience signal set that Google evaluates holistically. The complete page experience framework encompasses HTTPS security, mobile-friendliness, the absence of intrusive interstitials, safe browsing status, and—while not formally announced as a ranking signal—accessibility compliance that is increasingly factored into Google’s evaluation of user experience quality. Each of these signals functions as a binary or threshold-based qualifier: falling below the acceptable standard on any individual signal can undermine the positive impact of strong performance on the others. A site that achieves perfect Core Web Vitals scores but serves pages over HTTP, displays intrusive popups on mobile, or carries a safe browsing warning has not met the page experience standard, and the ranking benefit of its performance investment is neutralized by these foundational failures.

HTTPS has functioned as a confirmed Google ranking signal since August 2014, making it the longest-standing component of the current page experience framework. As of 2026, over 95 percent of pages loaded in Chrome use HTTPS, and Google Chrome displays a “Not Secure” warning in the address bar for any page served over HTTP—a warning that measurably reduces user trust and engagement. The ranking benefit of HTTPS is documented as a lightweight signal, meaning it serves as a tiebreaker between otherwise equivalent pages rather than a dominant ranking factor. However, the absence of HTTPS creates cascading negative effects that extend beyond the direct ranking signal: it disqualifies pages from HTTP/2 and HTTP/3 protocol benefits that improve load performance, it prevents the use of service workers required for progressive web app functionality, it triggers browser security warnings that increase bounce rates, and it undermines consumer trust for any site that processes form submissions, login credentials, or payment information. Implementing HTTPS requires obtaining and maintaining a valid TLS/SSL certificate, configuring the web server for secure connections, implementing 301 redirects from all HTTP URLs to their HTTPS equivalents, updating internal links and canonical tags to reference HTTPS URLs, and submitting the HTTPS version of the site to Google Search Console as the primary property. Free certificates from providers such as Let’s Encrypt have eliminated the cost barrier entirely, making HTTPS a baseline requirement rather than an optional investment.

Mobile-friendliness transitioned from a standalone ranking signal to an integrated component of the page experience framework, and its importance has only increased as mobile devices account for approximately 63 percent of all Google searches globally in 2026. Google’s mobile-first indexing—meaning that Google uses the mobile version of a page as the primary version for indexing and ranking—has been the default for all websites since late 2023, making mobile rendering quality a fundamental rather than supplementary consideration. The specific mobile-friendliness criteria that Google evaluates include viewport configuration (the meta viewport tag that enables responsive rendering), text readability without requiring zoom (a minimum font size of 16 CSS pixels is recommended), touch target sizing (interactive elements should be at least 48 by 48 CSS pixels with adequate spacing between adjacent targets), content width fitting within the viewport without requiring horizontal scrolling, and the absence of plugins such as Flash that are unsupported on mobile devices. Google Search Console’s Mobile Usability report identifies pages that fail specific mobile-friendliness criteria, providing a diagnostic starting point for remediation. The most robust implementation approach uses responsive web design with CSS media queries, flexible grid layouts, and relative units (percentages, viewport units, rem) rather than fixed pixel dimensions, ensuring that the same HTML content renders appropriately across the full spectrum of device sizes.

Intrusive interstitials represent the page experience component most frequently violated by well-intentioned businesses that deploy popups, overlays, and modal dialogs without understanding Google’s specific guidelines on acceptable versus penalizable implementations. Google’s interstitial penalty, first introduced in January 2017 and refined in subsequent updates, targets full-screen popups and overlays that obstruct the main content when a user navigates to a page from search results. The penalty specifically applies to interstitials that cover the main content immediately on page load or during the user’s interaction with the page, standalone interstitials that must be dismissed before accessing the content, and above-the-fold layouts where the primary visible portion of the page functions as an interstitial. However, Google exempts several categories of interstitials from the penalty: interstitials required by law (cookie consent banners under GDPR, age verification for restricted content), login dialogs for sites with paywalled content, and banners that use a reasonable amount of screen space and can be easily dismissed (Google’s examples suggest banners occupying no more than 15 to 20 percent of the viewport). The strategic implication is clear: businesses that rely on popup-based lead capture, email signup modals, or promotional overlays must implement them in a manner that avoids triggering on initial page load from search results. Time-delayed popups (appearing after 30 or more seconds of engagement), scroll-triggered modals (appearing after 50 percent or more scroll depth), and exit-intent overlays (triggering only when mouse movement indicates intent to leave the page) represent compliant alternatives that preserve conversion functionality without incurring the ranking penalty.

Safe browsing status functions as a binary page experience signal that effectively removes a site from competitive consideration when triggered. Google’s Safe Browsing infrastructure continuously scans websites for malware distribution, phishing content, unwanted software installations, deceptive page elements, and social engineering attacks. When a site is flagged by Safe Browsing, Chrome and other browsers display prominent warning interstitials that prevent users from reaching the site without explicitly acknowledging the risk, and Google’s search results display a warning label that effectively eliminates click-through traffic. The Safe Browsing signal differs from other page experience components in that it is not a gradual ranking factor but a catastrophic disqualification that requires immediate remediation. Common causes of Safe Browsing flags include compromised WordPress installations with injected malicious code, third-party advertising networks serving malware through ad creatives, outdated CMS plugins with known security vulnerabilities being exploited by automated attack tools, and user-generated content sections where spam accounts post links to phishing sites. Prevention requires maintaining current software versions across all CMS components, implementing web application firewalls, conducting regular security scans with tools such as Sucuri or Wordfence, and monitoring Google Search Console’s Security Issues report for early detection of any flagged content.