Google's Scroll to Text Fragments - Ramifications & Disabling

Ryuzaki

お前はもう死んでいる
Moderator
BuSo Pro
Digital Strategist
Joined
Sep 3, 2014
Messages
6,229
Likes
13,100
Degree
9
I use Safari and hadn't seen this yet but just used Edge on another computer and found this is active now.

So basically, Google is adding jump links to URLs in the SERPs by appending text to the end of the URL like #:~:text=scroll%20to%20this%20point

Chrome and Edge (I'm sure Firefox and Safari will follow) will automatically find and load the page at the text "scroll to this point" and will highlight it.

This is a disaster for those of us who have optimized our above the fold with comparison tables or are monetizing with display ads, etc.

Google is using this currently in the Featured Snippets. I searched and found that Google claims if we disable this it will not impact our ability to be featured in the Featured Snippets:

aMzlDvP.png

Obviously that should come with a caveat of "No, not right now, not yet." Because obviously this is going to be used in the Google Passages update, where Google is cataloging parts of the page separately and likely wants to scroll users straight to it.

So whether or not we should disable this might change. But for now I'm going to. So how is that done?

The official answer from w3.org is to use a document policy.

You may be thinking "what the hell is that and how do I use it?" Assuming you're using an Apache server, you'll want to find your hidden .htaccess file at the root of your public_html folder on your server and add a document policy as an HTTP header. You want to do this at the server level and not with PHP or anything else on the browser side because it needs to be seen early.

So in your .htaccess you'll want to paste in (ignoring the green part):

Solution: Header add Document-Policy: force-load-at-top

If you do it right, your server should respond with that new policy like seen below in the BuSo Lightning demo site I just tested it on:

NEpRnJt.png

You see at the bottom there. I've confirmed it's working. I'll be adding this to my sites monetized by display ads until I hear or see otherwise that it's a bad idea. The last thing I need is Google loading my page 50% down and me missing out on showing some ads, the bread and butter of the income on those sites.

Can you think of anything else in how this might apply to the Passages update or other ramifications of blocking the Scroll to Text feature?
 
@Ryuzaki Where do you stand on this currently? Still disabling, or allowing it now?
 
@Ryuzaki Where do you stand on this currently? Still disabling, or allowing it now?
That was impressive. Almost two years to the day you checked in!

I'm still forcing the browser to load the page at the top and have not seen any information that makes me think it's a problem (yet).

One thing I can update you on is that the following browsers now all support this feature natively according to CanIUse.com:
  • Chrome since v81-106 and on Android
  • Edge since v83-106
  • Safari since v16.1 (just came out) and on iOS now
  • Opera since v68-90 and on mobile
  • and more
It's going to get universal adoption. So all I'm really looking out for is if Google wants to be cocky enough to tell us how we have to load our webpages. The worst I imagine happening is that they exclude us from Featured Snippets (which is a big deal). I don't see it being algorithmic. If they exclude us from Featured Snippets for blocking this, I'll remove it. And if I ever see that come down the pipeline I'll raise the white flag here so we can all surrender if we choose.
 
Awesome, thank you.

Follow up question:

We are using this to prevent the scroll in featured snippets. But in the process it looks like it may be causing weird behavior when users click links found within our FAQ on the search result. The FAQ shows in the SERP result, and the answer in our FAQ contains a link to a specific section in the article (not a link to a different article). We're using links in the FAQ more like a jump link rather than using it for interlinking.

Here's the behavior by device and browser:

Mobile:
Google Chrome - Click link in FAQ > user lands on top of the article page
Safari - Click link in FAQ > user lands at a completely wrong section within the article

Desktop:
Google Chrome and Microsoft Edge - Click link in FAQ > user lands at top of the article page
Mozilla Firefox - works correctly
Safari - works correctly

The links all work fine when clicked within the article itself. Also, we have validated the schema and google says it's correct.

So I assume somehow the document policy is causing the weird behavior. If that is the case, do you know how we can allow the FAQ links to bring the user to the correct place, but still force the browser to load the page at the top when someone clicks a featured snippet link?
 
So I assume somehow the document policy is causing the weird behavior.
Is the weird behavior specifically only for Safari on mobile where the click lands you at a wrong section within the article?

I've seen two things in regards to Safari with "jump links". The first is that they scroll to the header that contains the #anchor, but they scroll a little too far so that the header ends up just above the visible screen. I've seen this behavior for years and years now.

The other thing I've seen is that Safari (since Apple refuses to do anything standard with their browser or OS) is that it may scroll to the #anchor before the rest of the page loaded, so that when images and things that cause Cumulative Layout Shift occur, it pushes the page down, which makes the user land above the section you meant them to land on.

This is a good point though. I'm assuming this "load at the top" document policy will interfere with jump links to sections even when they don't have text-fragments attached to them. FAQ links in the SERPs are a perfect example. Any links from an external source will load at the top of the page. Once you're on the page, internal jump links should work fine.

Seems like part of the Faustian Bargain of retaining display ad revenue, something we won't be able to get around.
 
@Ryuzaki Chrome causes that user to land at the very top of the page rather than the linked section. And safari causes them to land on the wrong section. But I think what you described about the page loading is probably what is going on with Safari. Appreciate the explanation.

And yeah looks like it’s just something we have to live with if we want to keep the revenue. Hah.
 
Back