Maandelijks archief: oktober 2015

You are here: Home / Archive

Mijn oude SEO hoed weer eens op

Ik heb een aantal jaar Search Engine Optimization (SEO) gedaan toen ik nog in loondienst was. Of nou ja, erbij gedaan, naast reguliere ontwikkelwerkzaamheden. Vandaag had ik mijn oude SEO hoed weer eens op, en runde wat testjes op de Google Search. Dat verliep vlot, en toen had ik mijn resultaat. Maar net daarna kom ik een artikel tegen die mijn testresultaten direct tegen spreekt. Dat leek me de moeite waard om eens even een blog aan te wijden…

Voor SEO kun je met een paar gerichte ‘site:testsite.nl “tekst die je zoek”‘ zoekacties en het checken van de laatst door Google gecachete versie al best het een en ander uitvinden. Ook al had ik in dit geval niet direct toegang tot Google’s webmaster Tools voor de site die ik testte.

headless browser

Google crawlt nu met een headless browser

Uiteindelijk laat Google je daar toch ook alleen maar zien wat – ook – in hun beste belang is. Dus Webmaster Tools is ook geen ‘magic bullet’. Maar in ieder geval beter dan vele betaalde tools die allemaal claimen je te kunnen helpen, wat in veel gevallen simpelweg onzin is.

Uiteindelijk is SEO ook gewoon veel werk :). Hoewel ‘Moz‘ en andere tools die Google simuleren je wel een eind op weg kunnen helpen, de uiteindelijke analyse is aan jezelf. De precieze ‘magic sauce’ die Google toepast doen ze toch geen uitspraken over, dus dat vereist veel testen. En daarnaast verandert dit ook nog continue. Als simpele SEO’er kun je – na wat basis optimalisatie – je tijd dan meestal ook beter besteden aan gewoon goede content maken en het verder aan Google overlaten om dit te vinden. In plaats van allerlei ‘black hat’ technieken te gaan proberen, die ook nog tot een drop van je rank kunnen resulteren.

Hoe dan ook, de reden dat ik er nu toch een blogpost aan wijdt is omdat ik net een technische update vind van Google die toch redelijk revolutionair is. Twee weken oud. Dat is nog best nieuw toch? :P. Anyway, Google geeft aan dat ze vanaf deze maand eindelijk ‘headless browser’ gebruiken bij het crawlen.

Of laat ik hun eigen woorden maar (tegen ze?) gebruiken:

Today, as long as you’re not blocking Googlebot from crawling your JavaScript or CSS files, we are generally able to render and understand your web pages like modern browsers.

Daar zaten wij webdevelopers al sinds 2009 op te wachten. Dus goed nieuws toch? Maar – en dit is de grote MAAR – uit het testje wat ik net voor het lezen van dit bericht had gedaan kon ik juist concluderen dat ze dit NOG niet doen. Want daar was ik juist benieuwd naar.

Dat vond ik merkwaardig. Wat kon daar de reden voor zijn? Als gezegd doet Google zelf historisch gezien weinig uitspraken over hun precieze crawl technieken. Reden is dat alle black hatters dit dan gaan epxloiteren. Algemene uitspraken doen ze wel. In een artikel van een Google developer van afgelopen mei geven ze wat meer detail. Dit artikel is dus uit de tijd dat het headless browsen alleen nog maar aangekondig werd. En ze geven daarin niet meer reden dan dit:

  • Sometimes the JavaScript may be too complex or arcane for us to execute, in which case we can’t render the page fully and accurately.

In eerste instantie vind ik dit merkwaardig. Te complex? Als een ‘simpele’ browser er ook in slaagt om uiteindelijk de dynamische tekst tonen, dan kan Google’s geavanceerde crawl bot dit toch ook?

To arcane? In mijn geval betrof het wat functioliteit die grotendeels gebaseerd was op Google’s eigen Google Charts Javascript API. Dus die willen ze toch niet ‘to arcane’ noemen.

Toen ik hier verder over nadacht kon ik echter wel wat redenen bedenken. Het komt neer op asynchroniteit en schaalbaarheid. Het kan namelijk zo zijn dat:

  • De crawler maar een bepaalde maximale hoeveelheid Javascript uitvoert en indien er meer is, dat deze er dan niet eens aan begint. Hoewel de crawler ongetwijfeld geavanceerd is, crawl Google op zo’n grote schaal, dat ze wellicht het headless browsen op deze manier schaalbaar houden.
  • En/of het kan zijn dat indien er asynchrone calls worden gedaan in de Javascript, dat de crawler dan stopt. Hetzij meteen, hetzij na een aantal hops, hetzij er na een bepaalde timeout van enkele milliseconden geen reactie is. Omdat dan onzeker wordt hoe lang het duurt voordat de content klaar is, en de crawler niet opgehouden wil worden. Ook zou  Google via een statische analyse vooraf gedaan kunnen worden of de code asynchroon is of niet. In hun V8 engine (JIT) compilet Google immers ook al Javascript code ivm optimalisatie, dus die techniek hebben ze bij wijze van spreken uitgevonden.

Nou, al schrijvende ben ik ook alweer wat wijzer geworden. ‘ I think better when I write’. Om nog meer te achterhalen zou ik verdere testen moeten doen. Ik heb ook al even een vraag gesteld aan Google onder het artikel. Wellicht dat ze het zelf willen vertellen, hoewel ik maar nergens op reken ;).

Ik kan ook nog eens even de Google hoed verder over mijn hoofd zetten en terug in Google Webmaster Tools duiken. Dat is al weer meer dan een jaar geleden. Maar Google gaf dus in het gelinkte artikel van mei aan dat er een nieuwe tool zou komen voor analyse.

Als ik meer weet en tijd heb blog ik er wellicht over. Voor nu hoop ik dat een enkele lezer hier ook nog iets aan had. En kan ik mijn gedachtengang over een tijdje in ieder geval nog eens teruglezen. Reacties zijn ook welkom, hieronder!

Update 24-11-2015: N.a.v. een vraag nog even een update. Ik ben naderhand inderdaad nog in Google Webmaster Tools gedoken nav deze kwestie. Ik weet niet of de Mobile Test tool, de tool is die Google bedoelde, maar hiermee kreeg ik in ieder geval boven water dat de `corechart` library van Google zelf niet ingeladen wordt door de crawler. Dus dit is de ‘boosdoener’. Dit is een soort dynamische CDN. Wellicht dat Google deze zelf in een robots.txt heeft staan, of dat het komt door het dynamisch laden zoals ik eerder al stelde. Ik zou dus kunnen testen of het wel werkt als ik zelf deze .js download en host op de server (bv. via bower). Via iets als:

 

>bower install google-chart

Zie bijgevoegd (samengesteld) screenshot, deze geeft eigenlijk alles aan:

mobile-tester

Maar momenteel ben ik druk met andere zaken. En in geval ik er weer mee bezig ga, ga ik deze functionaliteit waarschijnlijk toch – ouderwets – naar de backend overhevelen, dat lost het ook op, en is qua security wat beter. Bij een vervolgopdracht komt er een en ander achter inlog te zitten.