Op zondag 5 mei ontving ik een e-mail van een persoon die beweerde toegang te hebben tot een enorm lek aan API-documentatie vanuit de zoekafdeling van Google. In de e-mail werd verder beweerd dat deze gelekte documenten als authentiek waren bevestigd door ex-werknemers van Google, en dat die ex-werknemers en anderen aanvullende, privé-informatie hadden gedeeld over de zoekoperaties van Google.

Veel van hun beweringen zijn rechtstreeks in tegenspraak met de openbare verklaringen die Googlers in de loop der jaren hebben afgelegd, met name de herhaalde ontkenning van het bedrijf dat klikgerichte gebruikerssignalen worden gebruikt, de ontkenning dat subdomeinen afzonderlijk in ranglijsten worden beschouwd, de ontkenning van een sandbox voor nieuwere websites, de ontkenning dat een de leeftijd van het domein wordt verzameld of in overweging genomen, en meer. 

Natuurlijk was ik sceptisch. De beweringen van deze bron (die anoniem wilde blijven) leken buitengewoon – beweringen als:

• In de beginjaren onderkende het zoekteam van Google de behoefte aan volledige clickstreamgegevens (elke URL die door een browser wordt bezocht) voor een groot percentage van de internetgebruikers om de resultaatkwaliteit van hun zoekmachine te verbeteren.
• Een systeem genaamd “NavBoost” (aangehaald door VP van Search, Pandu Nayak, in zijn DOJ-getuigenis ) verzamelde aanvankelijk gegevens van Google’s Toolbar PageRank , en het verlangen naar meer clickstream-gegevens diende als de belangrijkste motivatie voor het maken van de Chrome-browser ( gelanceerd in 2008).
• NavBoost gebruikt het aantal zoekopdrachten voor een bepaald trefwoord om de trendmatige zoekvraag te identificeren, het aantal klikken op een zoekresultaat (ik heb hier tussen 2013 en 2015 verschillende experimenten mee uitgevoerd) en lange klikken versus korte klikken (waar ik theorieën over presenteerde in deze video uit 2015 ).
• Google gebruikt de cookiegeschiedenis, ingelogde Chrome-gegevens en patroondetectie (in het lek ‘niet-geplet’ klikken versus ‘geplet’ klikken genoemd) als effectief middel om handmatige en geautomatiseerde klikspam te bestrijden.
• NavBoost beoordeelt ook zoekopdrachten op gebruikersintentie. Bepaalde aandachtsdrempels en klikken op video’s of afbeeldingen zullen bijvoorbeeld video- of afbeeldingsfuncties activeren voor die zoekopdracht en gerelateerde, aan NavBoost gerelateerde zoekopdrachten.
• Google onderzoekt klikken en betrokkenheid bij zoekopdrachten zowel tijdens als na de hoofdzoekopdracht (ook wel een “NavBoost-zoekopdracht” genoemd). Als veel gebruikers bijvoorbeeld zoeken naar ‘Rand Fishkin’, vinden ze SparkToro niet, wijzigen ze hun zoekopdracht onmiddellijk in ‘SparkToro’ en klikken ze op SparkToro . com in het zoekresultaat, SparkToro . com (en websites die ‘SparkToro’ vermelden) krijgen een boost in de zoekresultaten voor het trefwoord ‘Rand Fishkin’.
• De gegevens van NavBoost worden op hostniveau gebruikt om de algehele kwaliteit van een site te evalueren (mijn anonieme bron speculeerde dat dit zou kunnen zijn wat Google en SEO’s ‘ Panda ‘ noemden). Deze evaluatie kan resulteren in een boost of een degradatie.
• Andere kleine factoren, zoals boetes voor domeinnamen die exact overeenkomen met zoekopdrachten zonder merk (bijvoorbeeld heren – luxe – horloges . com of milwaukee-homes-for-sale.net), een nieuwere “BabyPanda”-score en spamsignalen worden ook in aanmerking genomen tijdens het kwaliteitsevaluatieproces.
• NavBoost houdt klikgegevens geo-fences, rekening houdend met land- en staats-/provincieniveaus, evenals mobiel versus desktopgebruik. Als Google echter geen gegevens heeft voor bepaalde regio’s of user-agents, kan het proces universeel worden toegepast op de zoekopdrachtresultaten.
• Tijdens de Covid-19-pandemie gebruikte Google witte lijsten voor websites die hoog in de resultaten van Covid-gerelateerde zoekopdrachten konden verschijnen
• Op dezelfde manier gebruikte Google tijdens democratische verkiezingen witte lijsten voor sites die moesten worden getoond (of gedegradeerd) voor verkiezingsgerelateerde informatie

En dit is nog maar het topje van de ijsberg.

Buitengewone beweringen vereisen buitengewoon bewijs. En hoewel sommige hiervan overlappen met informatie die is onthuld tijdens de Google/DOJ-zaak (waarvan je over sommige kunt lezen in deze thread uit 2020 ), zijn vele nieuw en suggereren ze voorkennis.

Dus afgelopen vrijdag 24 mei (na verschillende e-mails) had ik een videogesprek met de anonieme bron.

Update (28/05 om 10:00 uur Pacific): De anonieme bron heeft besloten zich te melden. Deze video maakt hun identiteit bekend: Erfan Azimi , een SEO-beoefenaar en de oprichter van EA Eagle Digital.

Voorafgaand aan de e-mail en het telefoontje had ik Erfan nog nooit ontmoet of gehoord. Hij vroeg dat zijn identiteit verborgen zou blijven, en dat ik alleen het onderstaande citaat zou opnemen:

Een adelaar gebruikt de storm om onvoorstelbare hoogten te bereiken.
– Matshona Dhliwayo

Na het telefoongesprek kon ik details bevestigen over Erfans werkgeschiedenis, gemeenschappelijke mensen die we allebei kennen uit de marketingwereld, en een aantal van hun beweringen over hun deelname aan bepaalde evenementen met insiders uit de branche (waaronder Googlers), hoewel ik de details van de bijeenkomsten niet kan bevestigen. noch de inhoud van de discussies die zij beweren te hebben gevoerd.

Tijdens ons gesprek liet Erfan me het lek zelf zien: meer dan 2.500 pagina’s met API-documentatie met 14.014 attributen (API-functies) die afkomstig lijken te zijn van Google’s interne ‘Content API Warehouse’. Op basis van de commitgeschiedenis van het document is deze code op 27 maart 2024 naar GitHub geüpload en pas op 7 mei 2024 verwijderd. (Opmerking: omdat dit stuk na de publicatie werd aangepast om de identiteit van Erfan weer te geven, wordt hij hieronder “de anonieme bron” genoemd).

Deze documentatie toont geen zaken als het gewicht van bepaalde elementen in het zoekrangschikkingsalgoritme, noch bewijst het welke elementen in de rangschikkingssystemen worden gebruikt. Maar het toont wel ongelooflijke details over de gegevens die Google verzamelt. Hier is een voorbeeld van het documentformaat:

Nadat hij mij door een handvol van deze API-modules had geleid, legde de bron hun motivaties uit (rond transparantie, het ter verantwoording roepen van Google, enz.) en hun hoop: dat ik een artikel zou publiceren waarin dit lek werd gedeeld, waarin enkele van de vele interessante stukken zouden worden onthuld. gegevens die het bevatte, en het weerleggen van enkele ‘leugens’ die Googlers ‘al jaren hadden verspreid’.

Is dit API-lek authentiek? Kunnen we erop vertrouwen?

Een cruciale volgende stap in het proces was het verifiëren van de authenticiteit van de API Content Warehouse-documenten. Dus nam ik contact op met een aantal ex-Googler-vrienden, deelde de gelekte documenten en vroeg naar hun mening. Drie ex-Googlers schreven terug: één zei dat ze zich niet op hun gemak voelden om ernaar te kijken of er commentaar op te geven. De andere twee deelden het volgende (off the record en anoniem):

• “Toen ik daar werkte, had ik geen toegang tot deze code. Maar dit ziet er zeker legitiem uit. “
• “Het heeft alle kenmerken van een interne Google API.”
• “Het is een op Java gebaseerde API. En iemand heeft veel tijd besteed aan het naleven van de interne standaarden van Google voor documentatie en naamgeving.”
• “Ik heb meer tijd nodig om het zeker te weten, maar dit komt overeen met de interne documentatie die ik ken.”
• “Niets dat ik in een korte recensie zag, suggereert dat dit allesbehalve legitiem is.”

Vervolgens had ik hulp nodig bij het analyseren en ontcijferen van de naamgevingsconventies en meer technische aspecten van de documentatie. Ik heb een beetje met API’s gewerkt, maar het is twintig jaar geleden dat ik code schreef en zes jaar geleden dat ik SEO professioneel beoefende. Dus nam ik contact op met een van ‘s werelds belangrijkste technische SEO’s: Mike King , oprichter van iPullRank .

Tijdens een telefoongesprek van 40 minuten op vrijdagmiddag heeft Mike het lek beoordeeld en mijn vermoedens bevestigd: dit lijkt een legitieme reeks documenten te zijn van de zoekafdeling van Google en bevat een buitengewone hoeveelheid eerder onbevestigde informatie over de interne werking van Google.

2.500 technische documenten is een onredelijke hoeveelheid materiaal om aan één man (een vader, echtgenoot en ondernemer, niet minder) te vragen om in één weekend te beoordelen. Maar dat weerhield Mike er niet van om zijn best te doen. Hij heeft hier een uitzonderlijk gedetailleerd eerste overzicht van het Google API-lek
samengesteld , waarnaar ik in de onderstaande bevindingen meer zal verwijzen. En hij heeft er ook mee ingestemd om op 8 oktober aanwezig te zijn op SparkTogether 2024 in Seattle, WA, waar hij het volledig transparante verhaal van dit lek veel gedetailleerder zal presenteren, en met het voordeel van de komende paar maanden van analyse.