Google laat browser tekst uit snippet op webpagina markeren na doorklikken

Google is begonnen met browsers laten markeren van tekst op een webpagina als gebruikers op de link bij een snippet klikken. Daardoor is voor gebruikers direct duidelijk waar de relevante inhoud van een webpagina staat.

De wijziging is live gegaan na jaren van testwerk, zegt Google-medewerker Danny Sullivan in een tweet die Search Engine Land vond. De functie lijkt niet te werken in alle browsers en op alle pagina's. In een korte tekst bleek het niet te werken in Mozilla Firefox, maar wel in Googles eigen browser Chrome. Het markeren van tekst gebeurt ook in het Nederlands.

De snippet is het korte stukje tekst van een webpagina dat Google bovenaan de zoekresultaten weergeeft, als het algoritme vermoedt dat in die tekst het antwoord staat op een vraag die de gebruiker stelt. Snippets zijn er al enkele jaren, maar nu scrollt de browser automatisch naar het gedeelte van de pagina waar die tekst staat als gebruikers doorklikken. Google geeft de url een 'fragment identifier' mee en de browser maakt vervolgens die tekst op de pagina geel. Omdat het gaat om een functie van een browser, is er geen code van websitemakers nodig om de functie te laten werken, zegt Google op een Help-pagina. Het markeren van tekst gebeurt automatisch.

Reacties (37)

[SeenD]

Oh ja, aan de url wordt wat toegevoegd.

#:~:text=Tweakers%20(leden%20van%20de%20site,naam%20"World%20of%20Tweaking".

Waarschijnlijk kan alleen chrome Chromium daar mee om gaan.
Wel een handige feature.

Even geprobeerd op dit artikel: nieuws: Google markeert tekst uit snippet op webpagina na doorklikken <- als je daar nu klikt dan is in de opening paragraaf een stukje tekst geel gemarkeerd. Ik heb 't alleen op Chrome getest.

[Reactie gewijzigd door SeenD op 22 juli 2024 13:42]

[kevin93w]

Zie hier een voorbeeld op deze pagina: nieuws: Google markeert tekst uit snippet op webpagina na doorklikken

[michielRB]

Bij deze de bevestiging dat hett in FF niet werkt. (FF 76.0.1 op Fedora 32)
Dat het in (new) Edge ook werkt is waarschijnlijk omdat die op chrome(ium) is gebaseerd: dezelfde codebase dus als Googles 'eigen' browser.
Ik ben benieuwd of FF deze functionaliteit gaat volgen.

[Yezpahr]

Ik hoop het eerlijk gezegd niet. Laat Firefox alsjeblieft niet meelopen deze keer.... Laat ze slim zijn.

[Cerberus_tm]

Met een userscript kun je zoiets wel krijgen. En nog meer (betere) functies. Screenshot, in Firefox:
https://i.imgur.com/DMB8xP1.png

[pimsaint]

Werkt ook prima in 'new' Edge

[SeenD]

Dat was ik ook al aan het doen. Ik probeerde alleen een hele zin met de ruimte er tussen weg te laten, alleen dat lukte niet. Net zoals in t voorbeeldje van mn quote.
Oh ja, ik moest de komma toevoegen:
nieuws: Google markeert tekst uit snippet op webpagina na doorklikken. Alleen nu pakt ie een heel groot stuk van het artikel omdat 2 zinnen identiek zijn. Ondertussen is een stuk van het artikel herschreven dus nu pakt ie gewoon 1 zin.

[Reactie gewijzigd door SeenD op 22 juli 2024 13:42]

[yanic]

En als je een meermaals voorkomende tekst neemt (bv. 'het') dan wordt het eerste voorkomen aangeduid.

[karelvandongen]

En ook in vivaldi werkt het prima.

[Christoxz]

Werkt op Opera ook prima!

maar wel in Googles eigen browser Chrome

Zit het dan niet gewoon in Chromium?

[SeenD]

Ja, lijkt er wel op, @pimsaint zei dat het in Microsoft Edge ook werkt.

[The Zep Man]

Waarschijnlijk kan alleen chrome daar mee om gaan.
Wel een handige feature.

Firefox kan dat ook toevoegen, eventueel met een user-agent modificatie als Google dit enkel aan Chrome browsers aanbiedt.

Overigens maak ik gebruik van Google search link fix, dus dat gaat sowieso niet werken, tenzij die add-on een update krijgt.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 13:42]

[stuiterveer]

Overigens maak ik gebruik van Google search link fix, dus dat gaat sowieso niet werken, tenzij die add-on een update krijgt.

Ten eerste is de optie niet beschikbaar in Firefox, dus tenzij de extensie ook in Chrome beschikbaar is (ga er even vanuit van wel, maar ik gebruik Chrome niet meer dus kan het niet bevestigen) is dit sowieso niet aan de orde.

Uitgegaan van het feit dat de extensie ook in Chrome beschikbaar is heeft hij sowieso alsnog geen effect. De genoemde extensie vermijdt het herschrijven van de URL, terwijl de originele URL al de info bevat voor markering (door middel van een aanduiding van de begintekst en eindtekst).

[The Zep Man]

[...]


Ten eerste is de optie niet beschikbaar in Firefox,

Zoals ik hier schreef:

Firefox kan dat ook toevoegen, eventueel met een user-agent modificatie als Google dit enkel aan Chrome browsers aanbiedt.

Uitgegaan van het feit dat de extensie ook in Chrome beschikbaar is heeft hij sowieso alsnog geen effect. De genoemde extensie vermijdt het herschrijven van de URL,

De extensie herschrijft weldegelijk de URL. Zie de screenshots op de Firefox add-on website.

[stuiterveer]

[...]
De extensie herschrijft weldegelijk de URL. Zie de screenshots op de Firefox add-on website.

Slechte woordkeuze dan van me, ik bedoel dat de extensie het veranderen van de URL naar een google.com/<trackinglink> URL tegenhoudt. De tekstselectie hoort echter al bij de URL voordat deze naar een trackinglink wordt herschreven.

[Tjeerd]

Kwam heel toevallig dit tegen vanochtend (denk bij een zoekopdracht naar een Wikipedia-artikel) en dacht dat het iets nieuws voor Wikipedia op zich was, blijkbaar dus iets van Google/Chrome. Die TIL had ik gedeeld via Twitter, die er weer een URL-verkorter op had toegepast. Maar op die verkorte URL klikken opent wel de Wikipedia-pagina, maar markeert de tekst niet met geel. Ververs ik ik dan de pagina met F5 dan wordt de tekst wel geel gemarkeerd.

[Reactie gewijzigd door Tjeerd op 22 juli 2024 13:42]

[Glodenox]

Hmm, het aanpassen van de URL is een ietwat vreemde keuze in mijn ogen. Het toevoegen van zaken in de hash kan op sommige sites namelijk negatieve effecten hebben als die gebruikt wordt om de state bij te houden (hoewel dat voor een deel ook wel een fout van die site is).

Ik zou eerder verwacht hebben dat men in de browser gaat kijken naar de geschiedenis en men dan deze markering op de zoekterm toepast als de vorige pagina een zoekpagina was. Idealiter kan men het zelfs zo maken dat er zelfs geen whitelist aan ondersteunde zoekmachines nodig is.

[Anders]

Als ik het zo snel bekijk worden er geen aanpassingen gedaan in de code, maar lijkt het highlighten in Chrome (of Chromium) te zijn ingebouwd.
https://i.imgur.com/4h0mTW1.png

Het lijkt voor websites dus niet uit te lezen te zijn welke code wordt gehighlight. Dat is een privacyzorg minder.

[crisp]

De url-fragment is door een site prima met javascript uit te lezen:

console.log(window.location.hash);

Als dit een veelgebruikte feature gaat worden dan kan het voor een site handig zijn om fragments te gaan checken op het voorkomen van `:~:text=` en dat op te slaan om te kunnen analyseren waar veel op wordt gezocht via Google.

Edit: dat lijkt alleen niet te werken in Chromium-based browsers; blijkbaar onderdrukken die de fragment met een dergelijke identifier voor JavaScript. Firefox echter niet.

Ik weet niet wat ik daarvan moet vinden als webdeveloper, dat een browser gaat beslissen wat wel en niet vanuit een fragment beschikbaar wordt gemaakt en daar een duaal karakter qua functionaliteit aan geeft. Je ziet hier duidelijk dat Google zijn eigen browser (ge/mis)bruikt voor deze feature wat je zelfs als oneerlijke concurrentie zou kunnen zien.

Edit2: blijkbaar bestaat deze feature al langer en is er ook al best veel informatie over te vinden. Het is gedocumenteerd en ook al veel besproken. Zie onder andere ook https://chromestatus.com/feature/4733392803332096 en https://github.com/mozilla/standards-positions/issues/194

[Reactie gewijzigd door crisp op 22 juli 2024 13:42]

[SirQuack]

Dit is eigenlijk een best slechte zaak. Nu Google pagina's gaat aanpassen nadat je zoekt met hun zoekmachine, tast de browser hiermee ook de authenticiteit van die pagina aan.

We hebben allerlei "nieuwe" technieken ontwikkeld zoals de Content Security Policy (die zegt wat een pagina mag doen en waar de content van die pagina zoals afbeeldingen of scripts vandaan mogen komen), speciale parameters in cookies zoals SameSite (die misbruik vanaf je sessie op een andere site voorkomen) en zo kan ik wel even verder.

Nu komt er dus een update in Chrome die deze waarborging teniet doet. Wat is de impact van die #:~:text=-tag, hoe bewerkt dat de pagina, en wat volgt er nog meer.

Het idee is goed, maar de mogelijke side-effects die hierdoor ontstaan maken me wel een beetje ongerust.

[RobinJ1995]

Je zegt dat wel, maar de HTML spec bevat al sinds vele jaren echt een belachelijke security flaw; https://mathiasbynens.github.io/rel-noopener/

Als jij naar een pagina op een extern domein linkt in een nieuw tabblad, krijgt de nieuwe pagina een link naar de browsertab van de oorspronkelijke website en kan daarop dus ook dingen uitvoeren. Hoeveel "web developers" zijn zich hier niet van bewust? Waarschijnlijk de meerderheid.

Na jaren discussiëren of ze de spec zouden breken in favour of security lijkt Firefox recentelijk ook eindelijk besloten te hebben de by default deze verwijzing niet eer door te geven aan gelinkte pagina's. Naar mijn mening in dit geval de juiste keuze.

Toen ik dit artikel las en ik zag dat het niet op Firefox werkt was mijn eerste gedachte dan ook dat er wel van deze zwakheid gebruikgemaakt zal zijn (hoewel het dan in de verkeerde richting zou zijn).

[SirQuack]

De noopener kwetsbaarheid is inderdaad significant, maar is ook al een beste tijd opgenomen in aanbevelingen zoals OWASP.

Het grote verschil tussen de opener-aanval en deze URL manipulatie, is dat sites iets kunnen doen aan het voorgenoemde probleem (rel="noopener" op de anchor tags). Dit werkt niet als de URL speciale browser-only parameters bevat die niet te blokkeren zijn.

Edit: Ik heb even rond zitten kijken in de Google help, en ze bieden wel een optie voor het uitschakelen van snippets middels de nosnippet tag, maar dit is natuurlijk enkel cosmetisch, de aanpassing blijft in de browser zitten.

[Reactie gewijzigd door SirQuack op 22 juli 2024 13:42]

[latka]

Ze hebben er jaren aan gewerkt, maar het werkt alleen op Google browsers (en afgeleiden). Zullen we dit gewoon maar links laten liggen totdat er of een server-side oplossing is zodat het overal kan werken of dat ze het netjes in de HTML5 standaard voorstellen zodat het neergeschoten kan worden als het toch niet breder gedragen gaat worden (zoals html imports door google in chrome gestopt zijn en daarna er toch weer uit omdat het niet cross-vendor goed te krijgen was). Ik krijg hele nare IE6 vibes van Chrome tegenwoordig.

[Yezpahr]

Van mij mag deze hele feature weer de tekentafel op en/of de ijskast weer in.

Je noemde al 1 reden: Het werkt niet eens op Firefox na "jaren" getest te hebben. Dat is natuurlijk gewoon moedwillig omdat ze hopen dat deze feature zó uniek is en zó viral gaat dat alle Firefox nerds er schuimbekkend opaf stormen... beetje jammer Google... beetje heel erg jammer en opvallend en een erg nutteloze feature.

Niemand zit hier toch op te wachten? Wie heeft zichzelf al eens betrapt op het denken van "goh, 2020 en we hebben nog geen eens instant-search-for-relevance". Nee.


-edit
Ik probeer even een use-case te bedenken voor deze feature, misschien zit er toch heil in?
1. Jantje zoekt recept voor koffietaart en krijgt een volledig recept in de snippet.
2. Jantje heeft alles, de snippet is zeer groot, nuttig en geeft gelijk wat je wilt. Waarom nog klikken?
3. Ok, Jantje klikt toch. Plaatje 2 laat gewoon met een kleurtje zien wat Jantje al wist van plaatje 1.

Weg use-case, want: al gelezen. Het is nu gewoon screenfiller en Jantje bakt een eind weg.
In mijn opinie is het 100% nutteloos. Of zie ik iets over het hoofd hier?

[Reactie gewijzigd door Yezpahr op 22 juli 2024 13:42]

[latka]

Op zich zou google direkt in het document moeten linken via de # constructie. Alleen moet de auteur dan wel een aantal markers in de pagina opgenomen hebben. Vermoedelijk fietsen ze er zo omheen en linken ze direkt naar een stuk content en zijn ze niet afhankelijk van de auteur. Ik zie de meerwaarde wel, maar de wijze waarop ze dit lijken te introduceren is niet kies.

[The Zep Man]

De functie lijkt niet te werken in alle browsers en op alle pagina's. In een korte tekst bleek het niet te werken in Mozilla Firefox, maar wel in Googles eigen browser Chrome.

(...)

Het markeren van tekst gebeurt automatisch.

Aangenomen dat Google geen enge zaken doet zoals AMP/proxyen wordt dit natuurlijk gewoon door de browser gedaan. Het is een nieuwe functie vanuit zowel Google als zoekmachine (markeert de tekst op google.com pagina's) en vanuit Chrome (leest die tekst en markeert het op de bijbehorende pagina zodra deze bezocht wordt).

[Reactie gewijzigd door The Zep Man op 22 juli 2024 13:42]

[Trousercough]

Volgens mij zijn er 2 manieren om dit te implementeren, maar ik ben geen expert:

1. Je komt niet bij de werkelijke site uit, maar een door google uit de cache geladen site, zoals AMP bijv.
2. Het is ingebouwd in de browser. De browser herkent dat je op Google iets zoekt of Google parsed iets naar de browser, waardoor de browser de betreffende tekst kan highlighten. Ben er persoonlijk geen fan van, omdat dit weer verschil oplevert in beleving tussen browsers. Ik vind dat browsers ten alle tijden de website op eenzelfde manier moeten laten zien/functioneren, ongeacht de maker van de browser.

[Reactie gewijzigd door Trousercough op 22 juli 2024 13:42]

[Anders]

Niet helemaal mee eens. Als jij in je browser zoekt op een bepaald woord, wordt dat woord gehighlight. Daarmee wijzigt voor jou het uiterlijk in vergelijking met wat anderen zien, op basis van jouw zoekopdracht. Deze aanpassing van Google is m.i. niet wezenlijk anders en ik denk dat veel mensen er prijs op stellen.

[Ikheetchris]

Aan het antwoord van SeenD te zien is het optie 2 geworden. Het zat blijkbaar al een tijdje achter de flag chrome://flags/#enable-text-fragment-anchor en er is een voorstel voor een standaard gemaakt.

Ik vind dat browsers ten alle tijden de website op eenzelfde manier moeten laten zien/functioneren, ongeacht de maker van de browser.

Tegenwoordig blokkeert Firefox standaard trackers en daardoor mogelijk ook reclames. Hierdoor veranderd de weergave en mogelijk functionaliteit ook. Dus beide browsers zijn hier aan schuldig.

[Smokeyy_TR]

Super handig! In Edge (chromium) werkt het ook.

[Gwaihir]

Handig.. en eng. Google brengt wijzigingen aan in webpagina's van derden. Iedere link kan nu wijzigingen aanbrengen in webpagina's van derden. Erg, erg tricky vanuit beveiligingsoogpunt.

[Ikheetchris]

Hier is wel over nagedacht: https://wicg.github.io/sc...ent/#security-and-privacy. Maar de beveiligingsrisico's op het eerste oogpunt zijn niet veel anders dan ze al waren met normale ankers in koppelingen, ze gedragen zich namelijk hetzelfde, behalve dat er een stuk tekst wordt gemarkeerd. Nu zou je hier met CSS wellicht bepaalde aanvallen kunnen doen door bepaalde stukken tekst visueel te verbergen, maar datn zul je controle over de website zelf of de browser zelf nodig hebben en dan zijn er wel makkelijkere aanvallen die je kunt uitvoeren.

[dragonlords1]

Dan wordt het misschien eindelijk terug mogelijk om een indicatie te hebben waarnaar bezoekers op zoek zijn. Je kan dit ook wel een stuk je met webmaster tools, maar dat is ook niet zo goed. Google geeft al heel lang de zoekwoorden niet meer door aan websites. Door hun machtspositie willen ze daar geld voor.

[bones]

Volgens mij kun je zelfs niet met betaling die zoekwoorden zien. Volgens mij zie je de woorden niet ivm privacy (setting).

[dragonlords1]

Je kan de zoekwoorden perfect zien in Google Adwords. Wil je zoekwoorden zien moet je adverteren.

[bones]

Ja maar de organische zoekresultaten niet. Staan meestal op “not provided”.

[Gustaaf437]

Op pagina's die een hash gebruiken voor de navigatie werkt de functie ook. Het gedeelte :~: werkt dan als splitter. Voorbeeldje: https://caniuse.com/#feat=dnssec:~:text=Mitigates
Beveiliging technisch hebben ze het goed aangepakt. Het gedeelte achter de splitter is niet beschikbaar via window.location of via window.getSelection().

De splitter wordt door andere browsers natuurlijk niet herkend, want dit is nergens als standaard voorgesteld. Het zal dus problemen op gaan leveren met andere browsers die dit niet ondersteunen (als je de link bijvoorbeeld deelt). Zoals @latka al zegt heeft dit wel een aardig IE6 gehalte daardoor.