Page Experience Comes to Desktop: What Changes for Your Site

If you are asking whether the page experience update for desktop will hurt your rankings, here is the short answer. Google started rolling it out on 22 February 2022, and it uses the same signals as the mobile version, minus mobile-friendliness. For most sites, the change will be small, but it is a good reason to check your desktop pages now.

In this guide, I explain what is changing, what is not, how to find weak desktop pages in Search Console, and what I would fix first.

What Google Announced and When

Google first shared the plan in November 2021. It said page experience would become a ranking signal for desktop search, starting in February 2022.

On 22 February 2022, Google confirmed the rollout had started. It is a slow rollout, and Google expects it to be complete by the end of March 2022.

Before that, in January 2022, Google added a Desktop section to the Page Experience report in Search Console. That gave site owners a few weeks to see how their desktop pages score before the signal went live.

You can read Google’s own explanation in its post on bringing page experience ranking to desktop. It is short and worth five minutes.

What the Page Experience Update for Desktop Includes

Page experience is a set of signals Google uses to judge how pleasant a page is to use, beyond the content itself. On mobile, it has been a ranking signal since a rollout that began in June 2021.

The desktop version takes almost the same set of signals. The only one left out is mobile-friendliness, which makes sense for a desktop screen.

Core Web Vitals on Desktop

Core Web Vitals are three measurements of real user experience: loading speed, how fast the page reacts, and how stable the layout is. Google says the desktop thresholds are the same as the mobile ones.

• LCP (Largest Contentful Paint): how long the biggest piece of content in view takes to show. Good is 2.5 seconds or less.
• FID (First Input Delay): how long the page takes to respond when someone first clicks or taps. Good is 100 milliseconds or less.
• CLS (Cumulative Layout Shift): how much the page jumps around while it loads. Good is 0.1 or less.

Google looks at these at the 75th percentile. In plain words, at least three out of four visits need to hit the “good” mark for the page to pass.

HTTPS

Your pages need to load over HTTPS, the secure version of HTTP. Most sites already do this, but I still find old HTTP pages, images or subdomains on many sites I check.

No Intrusive Interstitials

An interstitial is a pop-up or overlay that covers the main content. Google does not want pages that block the content as soon as someone lands from search.

Pop-ups that are needed for legal reasons, like cookie consent or age checks, are fine. So are small banners that use a reasonable part of the screen. The problem is the full-screen newsletter box that hides the article you came to read.

What About Mobile-Friendliness?

It stays a signal for mobile ranking only. It does not apply to desktop. If you are still working through mobile issues, my guide on fixing each error in the Mobile Usability report covers that side.

What Is Not Changing

This is just as important as what is new. A lot of panic comes from people mixing up these points.

• Mobile ranking stays the same. The desktop update does not change how mobile results are ranked.
• Content still comes first. Google has said many times that a great page experience does not beat having the most helpful, relevant content. Page experience matters most when several pages are similar in quality.
• Mobile-first indexing still applies. Google still mostly uses the mobile version of your pages for indexing. This update is about ranking in desktop results, not about which version gets indexed.
• There is no penalty. A page with poor scores is not removed or punished. It may just lose a small edge against a competitor with similar content and a better experience.

In my experience, sites that watched the mobile rollout last year will recognise the pattern. A few pages moved, most did not, and content quality explained far more of the changes than speed did.

Desktop vs Mobile Signals: Why Your Scores Can Differ

Many site owners assume desktop scores will be better because desktop computers are faster. Often they are, but not always.

Here is why the two can look quite different:

• Different layouts. A desktop page may show a large hero image, a wide slider or a sidebar full of widgets that the mobile layout hides. That can make LCP slower on desktop.
• Different ads. Desktop ad slots are often bigger and more numerous. Ads that load late and push content down are a common cause of poor CLS.
• Different pop-ups. Some sites turn off pop-ups on mobile because of Google’s earlier guidance, but leave them running on desktop.
• Different visitors. The data comes from real Chrome users. Your desktop visitors might be on office networks, older machines or a different mix of countries.

So I would not copy your mobile results and assume desktop is fine. Check it on its own.

Sites With Separate Mobile and Desktop URLs

Some sites use separate URLs, for example m.example.com for mobile and www.example.com for desktop. Google says that if this is set up correctly, the desktop signal is based on the desktop URLs, the ones desktop users actually see.

“Set up correctly” means the desktop page points to the mobile version and the mobile page points back with a canonical tag (a line of code that tells Google which version of a page is the main one). If you want to check how Google sees a specific URL, the URL Inspection API can help you check canonicals at scale.

How to Check Your Desktop Page Experience in Search Console

The fastest way to see where you stand is the Page Experience report. Here is the process I follow.

1. Open the Page Experience report. In Search Console, go to Experience, then Page Experience. You will now see a Mobile section and a Desktop section. Look at the share of “Good URLs” for desktop.
2. Open the Core Web Vitals report. Switch to the Desktop view. It groups URLs as Good, Needs improvement or Poor, and shows which metric is the problem.
3. Click into each issue. Search Console groups similar pages together. One fix to a page template often fixes hundreds of URLs at once.
4. Check HTTPS. The Page Experience report flags URLs that are not served over HTTPS. Fix these first because they are usually quick.
5. Test sample pages in PageSpeed Insights. Pick one or two URLs from each problem group. Choose the Desktop tab and look at both the field data (real users) and the lab data (a test run).
6. Fix, then validate. After you ship a fix, click “Validate fix” in the Core Web Vitals report. Search Console then tracks the group over about 28 days of new data.

When I audit a site, I always start with the Core Web Vitals groups rather than single URLs. Fixing a template is far better use of your time than fixing pages one by one.

If You See “Not Enough Data”

The report uses real user data from the Chrome User Experience Report. Smaller sites, or sites with little desktop traffic, may not have enough data for some or all pages.

This does not mean anything is wrong. It just means Google cannot judge those pages on field data. In that case, I use PageSpeed Insights lab data as a rough guide and fix the obvious problems.

Lab Data vs Field Data

Lab data comes from a single test in a controlled setup. Field data comes from real visitors over the last 28 days.

Google’s ranking signal uses field data. Lab tests are still useful for finding the cause of a problem, but a lab score of 100 does not guarantee “good” status. Also, lab tools cannot measure FID directly because there is no real user clicking. They show Total Blocking Time instead, which is a helpful stand-in.

Common Desktop Problems and How to Fix Them

These are the issues I usually see on desktop pages. They are worth checking even if your report looks mostly green.

Slow LCP From Large Hero Images

Desktop layouts often use a big banner image at the top. If it is a heavy file or loads late, LCP suffers.

• Compress the image and serve it at the size it is shown, not a huge original.
• Use modern formats like WebP where your setup supports it.
• Do not lazy-load the main image at the top of the page. Lazy loading is great for images further down, but it delays the one that matters most for LCP.
• Look at your server response time. A slow server makes every metric worse.

Layout Shifts From Ads, Embeds and Fonts

CLS problems are common on desktop because of wide ad slots and sidebars.

• Reserve space for ads and embeds by giving the container a fixed height.
• Always set width and height on images and videos.
• Avoid inserting banners above existing content after the page has loaded.
• Check web fonts. A font that swaps late can shift text around.

Slow Response From Heavy JavaScript

FID is usually poor when the browser is busy running scripts at the moment someone clicks. Desktop pages often load more scripts: chat widgets, sliders, tracking tags and so on.

• Remove scripts you no longer use. Most sites I look at have at least one old tracking tag nobody remembers adding.
• Delay non-essential scripts, like chat widgets, until after the page loads.
• Break up long tasks if you have a developer who can work on the code.

Desktop Pop-Ups

Review every pop-up that shows on desktop. Ask yourself: does it cover the main content right after someone arrives from Google?

If yes, I would change it to a smaller banner, delay it, or show it on exit instead. Cookie consent and legal notices are fine as they are.

Should You Worry About This Update?

My honest view: for most sites, this is not a big ranking event. Google calls page experience one signal among many, and relevance and content quality still carry much more weight.

That said, I would not ignore it. Here is how I would prioritise:

• High priority: sites with lots of desktop traffic, like B2B, software, and some ecommerce sites, where buyers research on a computer.
• Medium priority: sites whose desktop pages are rated Poor, especially on key templates like product or category pages.
• Low priority: sites where nearly all traffic is mobile and desktop scores are already good.

Check Google Analytics to see what share of your organic traffic comes from desktop. If it is a small slice, put your time into content and mobile first.

One more thing: faster, more stable pages help visitors whether or not they help rankings. People leave slow, jumpy pages. That alone makes this work worth doing.

How to Track the Impact During the Rollout

The rollout runs until the end of March, so do not draw conclusions from a few days of data. Here is what I would do instead.

1. Note the start date, 22 February 2022, in your analytics or reporting notes.
2. In the Search Console Performance report, filter by Device and compare desktop clicks and average position before and after.
3. Compare desktop and mobile trends. If desktop drops but mobile stays flat, page experience is one possible reason. If both drop, look elsewhere first.
4. Check your top desktop landing pages against their Core Web Vitals status. Are the pages that dropped the ones marked Poor?
5. Wait until the rollout is complete before making big decisions.

Keep in mind that Google makes many ranking changes all the time. A desktop dip during this period is not proof that page experience caused it.

Conclusion: What to Do Next

The page experience update for desktop brings the same Core Web Vitals, HTTPS and interstitial checks to desktop results, without mobile-friendliness. It started on 22 February 2022 and should be finished by the end of March.

Your next step is simple: open the Desktop section of the Page Experience report, find your Poor URL groups, and fix the templates behind them. Then fold this into your wider plan for the year. My SEO checklist for 2022 shows where page experience fits alongside content, links and technical basics.