Fixing Page Experience Signals That Hold Rankings Back
Page experience covers how a page feels to use: whether it loads and responds quickly, stays still while you read, works on a phone, is served securely and lets you reach the content without fighting pop-ups.
Google rewards pages that do this well, but it has been clear that relevance comes first and a fast page will not outrank a better answer. This guide is for site owners who suspect a poor experience is costing them positions or visitors. It shows which signals Google actually describes, how to measure each one properly, how to fix them, and which popular "UX signal" ideas to ignore.
What Google means by page experience
Google's documentation describes page experience as a set of aspects that its core ranking systems look at, rather than a single ranking system of its own. The aspects it lists have changed over time, and the current guidance asks site owners to consider:
- Core Web Vitals. Loading (Largest Contentful Paint), responsiveness (Interaction to Next Paint, which replaced First Input Delay in March 2024) and visual stability (Cumulative Layout Shift).
- Secure delivery. Pages served over HTTPS.
- Mobile display. Content that works properly on phones.
- No intrusive interstitials. Visitors can reach the main content without a pop-up blocking it.
- Clear main content. Visitors can easily tell the main content apart from adverts and other material.
Google has also said that good results on these aspects do not guarantee a high ranking, and that great page experience cannot make up for content that does not answer the search. In practice that makes page experience a tie-breaker between pages of similar relevance, and a factor in whether people who arrive stay, enquire or buy.
| Core Web Vital | Measures | Good | Poor |
|---|---|---|---|
| LCP | Time until the largest visible element renders | 2.5 s or less | Over 4 s |
| INP | Delay between an interaction and the next screen update | 200 ms or less | Over 500 ms |
| CLS | How much visible content moves unexpectedly | 0.1 or less | Over 0.25 |
A page passes when each metric is good at the 75th percentile of real visits, so three out of four page loads need to hit the target.
Bounce rate, dwell time and pogo-sticking
Older advice on "UX signals" often claims that Google ranks pages by bounce rate, time on page or whether searchers return to the results and click another listing (pogo-sticking). The picture is less tidy than that:
- Google has said it does not use Google Analytics data for ranking. Your bounce rate and engagement time in GA4 are not sent to the ranking systems.
- GA4 bounce rate is not the old bounce rate. In GA4 a bounce is a session that was not engaged: it lasted under ten seconds, had no key event and viewed only one page. A reader who spends four minutes on one article and leaves is not a bounce.
- Interaction data does exist. Testimony in the US Department of Justice antitrust case against Google described systems that learn from aggregated search interactions. Google does not publish how such data is used, and there is no evidence that any single site's dwell time is scored directly.
The sensible conclusion is to treat short visits and quick returns to search as symptoms. They tell you the page did not satisfy the visitor, which is worth fixing for its own sake. Trying to game them, for example by hiding the answer lower down or adding autoplay video to lengthen visits, makes the experience worse and often makes the underlying problem worse too.
The fix, step by step
Step 1
Check whether experience fits the timing
Open the Algorithm Impact monitor and see whether your ranking movement lines up with a tracked Google update, a technical fault or a competitor gain. Page experience problems rarely cause a sudden large drop on their own; they tend to leave you slightly behind similar pages. If a big loss matches a core update, work on content first and treat experience as supporting work rather than the main explanation.
Step 2
Read field data, not a single lab score
Open the Core Web Vitals report in Search Console, which groups URLs by status using data from real Chrome users. Then run the worst groups through PageSpeed Insights and read the top section, which shows field data, before the Lighthouse score lower down. A Lighthouse score of 60 with passing field data is not a problem to rank on; a score of 95 with failing field data is.
Step 3
Fix the Core Web Vital that fails
Work
on the metric that is actually failing. For LCP, serve the main image early with fetchpriority="high",
never lazy-load it, and cut server response time. For INP, break up long JavaScript
tasks and remove heavy third-party scripts from click handlers. For CLS, set width and
height on images and embeds and reserve space for adverts, cookie notices and banners before they load,
so the layout does not jump.
Step 4
Remove intrusive interstitials on mobile
Load each key template on a phone as a first-time visitor from search. Any pop-up that covers the content straight away, such as a newsletter or discount offer, should be replaced with an inline banner, a slide-in that covers a small part of the screen, or a delayed prompt after real engagement. Legally required cookie notices and age checks are acceptable, but keep them compact.
Step 5
Test real journeys on a real phone
Use a mid-range Android phone on a mobile connection, not a flagship on office wifi. Complete the journey a searcher would: read the answer, open the menu, use filters, add to basket, fill in the contact form. Note text that needs zooming, tap targets too close together, sideways scrolling, sticky bars that cover content and forms that fight the keyboard. Fix these in the templates, not page by page.
Step 6
Close HTTPS and mixed content gaps
Check
that every page redirects from http:// to https:// in a single hop, that the
certificate covers every hostname you use, and that no page loads images, scripts or fonts over plain
http. Look at the HTTPS report in Search Console for pages that are not served securely. Once everything
is clean, add a Strict-Transport-Security header so browsers stop trying the insecure
version.
Step 7
Put the main content first
Look at the first screen of each template on mobile and desktop. The visitor should see the heading and the start of the content, not a stack of adverts, a full-screen hero image, a carousel and a subscription prompt. Reduce advert density above the content, move related-post widgets below it, and make sure the answer to the page's main question appears early rather than after a long preamble.
Pop-ups: which are acceptable
Google's guidance on intrusive interstitials is mainly about the moment someone arrives from search on a phone. The table shows how common patterns compare.
| Pattern | Typical judgement | Better option |
|---|---|---|
| Full-screen newsletter pop-up on arrival | Intrusive | Inline sign-up box within the article |
| Standalone interstitial before the content loads | Intrusive | Remove it or show it after a real interaction |
| Above-the-fold layout that pushes content below the screen | Intrusive | Compact header with content visible straight away |
| Cookie consent banner | Acceptable when needed | Bottom bar or small panel, not a full-screen wall |
| Age verification for restricted products | Acceptable when needed | Keep it simple and remember the answer |
| Small slide-in using a modest part of the screen | Usually acceptable | Easy to dismiss, shown once per visit |
Platform notes
WordPress
Popup and page builder plugins are the usual sources of intrusive interstitials and layout shift. Check each popup's trigger and device settings, and disable arrival triggers on mobile. Caching and image optimisation plugins help LCP, but stacking several that overlap can cause conflicts; use one of each and test after changes.
Shopify
Apps inject scripts into every page, and uninstalling an app does not always remove its code from the theme. Audit the theme files for leftover snippets after removing apps, and check which apps load on product and collection templates, where INP matters most.
JavaScript frameworks
React, Vue and similar sites often pass LCP on the server-rendered HTML but fail INP because of heavy hydration. Split code by route, defer non-essential components and move work that is not needed for the first interaction off the main thread.
<!-- Load the hero image early and reserve its space -->
<img src="/images/hero-kitchen-1200.webp"
width="1200" height="675"
fetchpriority="high"
alt="Finished oak kitchen with island">
# Nginx: send HSTS once HTTPS is clean everywhere
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;Reports that changed or disappeared
Several tools referred to in older guides no longer exist, which confuses many audits:
- Search Console no longer has a combined page experience report. Use the Core Web Vitals report and the HTTPS report instead.
- Google retired the Mobile Usability report and the standalone Mobile-Friendly Test in late 2023. Use Lighthouse in Chrome developer tools and real device testing for mobile checks.
- First Input Delay is no longer a Core Web Vital. Any report still quoting FID is out of date; look at INP.
For deeper work on each metric see the Core Web Vitals Guide, Fixing INP and Fixing mobile Core Web Vitals.
1. Is page experience a ranking factor?
Google says its core ranking systems look to reward content that provides a good page experience, and it describes aspects such as Core Web Vitals, HTTPS, mobile display, avoiding intrusive interstitials and making the main content easy to find. It has also said page experience is not a single ranking system and that relevance comes first. Expect it to matter most between pages that answer a search about equally well, not to lift a weak page above a strong one.
2. Does Google use bounce rate or time on page to rank sites?
Google has said it does not use Google Analytics data in ranking, so your GA4 bounce rate and engagement time are not fed into search. Evidence from the US antitrust case suggests Google learns from aggregated search interactions, but it does not publish details and there is no sign that one site's dwell time is scored directly. Treat short visits as a sign the page did not satisfy people, and fix the page rather than trying to lengthen visits artificially.
3. My Lighthouse score is low but Search Console says my pages are good. Which is right?
Search Console is closer to what Google uses. Its Core Web Vitals report is based on field data from real Chrome users, measured at the 75th percentile over the previous 28 days. Lighthouse runs one simulated load on a throttled device and gives a lab score, which is useful for finding problems but is not what ranking uses. If field data passes, a modest Lighthouse score is not a ranking problem, though it may still point to improvements worth making.
4. Will passing Core Web Vitals bring my rankings back after an update?
Unlikely on its own, if the drop was large. Core updates mainly reassess how useful and relevant content is, and Google has said good Core Web Vitals do not guarantee good rankings. Fixing failing vitals is still worthwhile because it helps between similar pages and improves conversions. Check whether your drop lines up with a core update, and if it does, put most of your effort into the content of the pages that lost positions.
5. Are cookie banners counted as intrusive interstitials?
Google's guidance treats interstitials that respond to a legal obligation, such as cookie consent or age verification, as acceptable when used responsibly. Problems arise when a consent banner becomes a full-screen wall that hides the content, or when it is combined with a newsletter pop-up on arrival. Use a compact bar or panel that leaves content visible, remember the choice, and keep promotional pop-ups away from the first moment a visitor lands from search.
6. Why has my page experience report disappeared from Search Console?
Google removed the combined page experience report and folded guidance into its documentation. The underlying reports you need still exist: the Core Web Vitals report for real-user speed and stability, and the HTTPS report for secure delivery. The Mobile Usability report and Mobile-Friendly Test were retired in late 2023, so mobile checks now rely on Lighthouse in Chrome developer tools and on testing key journeys yourself on an actual phone.
7. How long before page experience fixes show up?
Field data in Search Console and PageSpeed Insights is based on a rolling 28-day window of real visits, so an improvement typically takes several weeks to show fully in those reports. Low-traffic pages may have no field data of their own and be grouped with similar pages. Any ranking effect follows once Google has updated its data, and it is usually modest. Conversion and engagement improvements often show sooner, in your own analytics.
The Algorithm Impact monitor lines up your daily ranking movements with tracked Google updates, helps separate update effects from technical faults, content decay and competitor gains, tracks your recovery and suggests actions suited to the type of update.
Open Algorithm Impact Fixes →