Als u een SEO-specialist bent en geen ontwikkelaar, hoeft u waarschijnlijk niet alle fijne kneepjes van het ontwikkelen van websites te benutten. Maar u moet wel de basis kennen, aangezien de manier waarop een website is gecodeerd een grote invloed heeft op de prestaties en dus op het SEO-potentieel. In de plaatsen op HTML-tags, hebben we de HTML-basisprincipes doorgenomen die u moet begrijpen om website-SEO efficiënt uit te voeren. Deze keer bied ik je aan om je te verdiepen in andere codeertalen die ontwikkelaars gebruiken om een ​​website er goed uit te laten zien en deze interactief te maken. 

De taal is JavaScript en in dit bericht zullen we de belangrijkste JS-gerelateerde fouten doornemen die u kunt tegenkomen bij het controleren van uw website. Ik zal uitleggen waarom elk van de fouten ertoe doet en hoe ze kunnen worden verholpen. Het reparatiegedeelte is iets dat u waarschijnlijk zult toewijzen aan uw website-ontwikkelaars. Alleen spreek je deze keer met hen dezelfde taal.

Is JavaScript goed of slecht voor SEO?

Helaas is er geen eenvoudig antwoord op deze vraag. Het hangt er allemaal van af, echt waar!

Wanneer Javascript doordacht wordt geïmplementeerd, met een focus op pagina-ervaring, prestatie-optimalisatie en correct indexering technieken, kan het gunstig zijn voor zowel SEO als gebruikers. Het meest vermeldenswaard is dat het kan resulteren in een verbeterde gebruikerservaring. Websites met JavaScript hebben meestal verschillende soorten animaties en overgangen die geweldig zijn om de betrokkenheid van gebruikers te vergroten.

Als u nu geen balans kunt vinden tussen interactiviteit en zoekmachinevriendelijkheid, heeft uw website een grotere kans op problemen zoals beperkte doorzoekbaarheid, lange laadtijd van pagina's en compatibiliteitsproblemen. Al deze problemen samen kunnen leiden tot een hoog bouncepercentage. Dat willen wij ook niet!

En ondanks het voortdurende debat over de impact van JavaScript op de zichtbaarheid en posities van een website, zou het niet juist zijn om te zeggen dat Javascript een bedreiging vormt voor website-optimalisatie. Toch kan een verkeerd gebruik van Javascript een nadelig effect hebben op uw rankingpotentieel, dus het wordt aanbevolen om op zijn minst enkele fundamentele Javascript SEO-praktijken te volgen. We zullen die later behandelen. Dus maak je geen zorgen, je zult binnenkort in staat zijn om de kracht van deze scripttaal ten volle te benutten.

Wat is JavaScript-SEO?

Voordat we ingaan op JavaScript SEO en de betekenis ervan voor succesvolle websiteprestaties, moeten we eerst de essentie van JavaScript zelf identificeren.

JavaScript is een scripttaal die voornamelijk wordt gebruikt om interactieve elementen en dynamische inhoud aan websites toe te voegen. Het is gemaakt door Brendan Eich bij Netscape Communications in 1995 en is sindsdien uitgegroeid tot een van de meest gebruikte programmeertalen op het web. Pop-upformulieren, interactieve kaarten, geanimeerde afbeeldingen, websites met voortdurend bijgewerkte inhoud (bijv. weersvoorspelling, wisselkoersen) zijn allemaal voorbeelden van het implementeren van JavaScript. 

Vanaf juli 2023 is Javascript de meest gebruikte client-side programmeertaal, gevolgd door Flash en Java. Sommige van de meest populaire websites die momenteel deze taal gebruiken, zijn Google, Facebook, Microsoft, YouTube, Twitter, Netflix, enzovoort.

Hier bij SE Ranking gebruiken we ook JavaScript. Veel van de coole effecten die je op het SE Ranking-platform ziet, worden ook mogelijk gemaakt door JS. Bijvoorbeeld onze Controle van paginawijzigingen landingspagina bevat nu een door JavaScript aangedreven animatie die is ontworpen om uit te leggen hoe de tool werkt. 

Om u een beter idee te geven van hoe JavaScript websites transformeert, wil ik u hetzelfde gedeelte van de bestemmingspagina laten zien met JavaScript uitgeschakeld.

Nu u bekend bent met JavaScript en de rol die het speelt bij de ontwikkeling van websites, gaan we onze aandacht verleggen naar JavaScript SEO.

JS SEO omvat het optimaliseren van websites die sterk afhankelijk zijn van JavaScript-technologie. In het verleden hadden zoekmachines moeite om JavaScript-afhankelijke webpagina's correct te indexeren en te crawlen, omdat hun algoritmen zich voornamelijk richtten op het ontleden en begrijpen van statische HTML-inhoud. Zoekmachines hebben enorme vooruitgang geboekt in hun vermogen om JavaScript-inhoud te interpreteren en te indexeren. Niettemin, om de uitdagingen van JavaScript aan te pakken en de zichtbaarheid van uw site in zoekmachines te verbeteren, is het essentieel om Javascript SEO-praktijken te implementeren.

Al deze problemen kunnen zeker worden vermeden zolang u begrijpt hoe Google JavaScript weergeeft en hoe u uw JS-code zoekvriendelijk kunt maken.

Hoe Google omgaat met JavaScript

De laatste tijd heeft Google een honderdvoudige sprong gemaakt in zijn vermogen om JavaScript te crawlen en te indexeren. Maar het proces is nog steeds vrij ingewikkeld en er kunnen veel dingen fout gaan. 

Met gewone HTML-pagina's is het allemaal duidelijk en eenvoudig. Googlebot crawlt een pagina en parseert de inhoud, inclusief interne links. Vervolgens wordt de inhoud geïndexeerd terwijl de ontdekte URL's worden toegevoegd aan de crawlwachtrij en begint het proces helemaal opnieuw. 

Wanneer JavaScript aan de vergelijking wordt toegevoegd, wordt het proces een beetje omslachtiger. Om te zien wat er verborgen is in het JavaScript dat er normaal uitziet als een enkele link naar het JS-bestand, moet Googlebot het eerst ontleden, compileren en uitvoeren. Dit wordt JS-rendering genoemd en pas nadat deze fase is voltooid, kan Google alle inhoud van een pagina zien in HTML-tags, de taal die het kan begrijpen. Op dit punt kan Google doorgaan met het indexeren van de JS-aangedreven elementen en het toevoegen van de URL's die verborgen zijn in JS aan de crawl-wachtrij.

Zijn deze complicaties iets waar u zich SEO-gewijs zorgen over moet maken? Precies een jaar geleden waren ze dat.

JavaScript-weergave is zeer veeleisend en kostbaar, en tot voor kort Google zou niet meteen renderen javascript. Het zou eerst de direct beschikbare eenvoudige HTML-delen van de pagina indexeren en vervolgens zou Google tijdens de zogenaamde tweede golf van indexering de JavaScript laten verwerken. Terug in 2018, John Mueller beweerde dat het een paar dagen tot een paar weken duurde voordat de pagina werd weergegeven. Daarom konden websites die sterk afhankelijk waren van JavaScript niet verwachten dat hun pagina's snel zouden worden geïndexeerd. Bovendien kunnen ze problemen hebben met nieuwe pagina's die in de wachtrij voor crawlen terechtkomen, omdat Google interne links niet onmiddellijk kan volgen.

In een van de JavaScript SEO-spreekuur, verzekerde Martin Splitt webmasters dat de weergavewachtrij nu veel sneller verloopt en dat een pagina normaal gesproken binnen enkele minuten of zelfs seconden wordt weergegeven. Desalniettemin is het coderen van JavaScript op een zoekvriendelijke manier nog steeds nogal lastig, en wekelijks JavaScript SEO-spreekuur sessies bewijzen dit duidelijk. De cases die gebruikers delen, laten zien dat het vreselijk mis kan gaan als JavaScript niet goed is gecodeerd. Laat me mijn punt illustreren met een paar veelvoorkomende problemen.

Google heeft geen interactie met uw inhoud

Google kan verborgen inhoud zien en indexeren zolang deze in de ARREST—hier wordt de HTML-broncode verzonden voordat deze door de browser wordt weergegeven. In dit stadium kan JavaScript worden gebruikt om de inhoud aan te passen. 

Laten we nu aannemen dat uw initiële HTML de volledige inhoud van de pagina bevat en vervolgens gebruikt CSS-eigenschappen om sommige delen van de inhoud te verbergen en JS om gebruikers deze verborgen delen te laten onthullen. In dit geval zit je goed, want de inhoud is nog steeds aanwezig in de HTML-code en alleen verborgen voor gebruikers. Google kan nog steeds zien wat er verborgen is in de CSS-code. 

Als uw initiële HTML daarentegen bepaalde inhoudsstukken niet bevat en deze in de DOM worden geladen door door klikken geactiveerde JavaScript, ziet Google dit soort inhoud niet omdat Googlebot niet kan klikken. Dit probleem kan echter worden opgelost door te implementeren weergave aan de serverzijde—dit is wanneer JS aan de serverzijde wordt uitgevoerd en Google de kant-en-klare definitieve HTML-code krijgt. Dynamische weergave kan ook een uitweg zijn.

Google scrolt niet

JavaScript wordt vaak gebruikt om een ​​oneindige scroll te implementeren of om wat inhoud te verbergen omwille van de UX en om gebruikers aanvullende informatie te laten onthullen door op de knop te klikken.

Het probleem hier is dat Googlebot niet klikt of scrolt zoals gebruikers in hun browser doen.

Het heeft zeker zijn eigen tijdelijke oplossingen, maar deze kunnen werken of niet, afhankelijk van de technologie die u gebruikt. En als u dingen implementeert op een manier die Google niet kan achterhalen, zal een deel van uw door JS aangedreven inhoud niet worden geïndexeerd.

Voor oneindig scrollen, overscroll-evenementen moeten worden vermeden omdat ze Googlebot nodig hebben om daadwerkelijk door de pagina te scrollen om de JavaScript-code aan te roepen - iets wat Google niet aankan. In plaats daarvan kunt u oneindig scrollen en lui laden implementeren met behulp van Intersection Observer-API of schakel gepagineerd laden naast oneindig scrollen in.

Hoe JS en CSS samenwerken

Terwijl Javascript vooral wordt gebruikt om interactiviteit en dynamisch gedrag aan webpagina's toe te voegen, maakt CSS (wat staat voor Cascading Style Sheets) het mogelijk om websites in stijl te maken. Hiermee kunnen ontwikkelaars de lay-out, kleuren, lettertypen en andere visuele aspecten van de HTML-elementen van de site definiëren. CSS wordt altijd naast HTML gebruikt. Het is het inpakpapier dat een geschenkdoos de vrolijke uitstraling geeft. Een gewone HTML-webpagina zou er zo uitzien min de ingestelde breedte en uitlijning aan de linkerkant.

Het punt is dat CSS tegenwoordig op elke website wordt gebruikt, ook al ziet het er nogal saai uit pagina uit een RFC-serie van technische notities over hoe het internet werkt. 

In het verleden gaf Google niet zoveel om CSS en interpreteerde het alleen de HTML-opmaak van de pagina. Dit veranderde allemaal met de mobielvriendelijke update in 2015. Als reactie op de groeiende populariteit van mobiel zoeken besloot Google websites te belonen die een naadloze gebruikerservaring op mobiele apparaten boden. En om ervoor te zorgen dat de pagina is mobielvriendelijk, moest Google het weergeven zoals browsers doen, wat betekende dat CSS- en JavaScript-bestanden moesten worden geladen en geïnterpreteerd. 

Algoritme voor pagina-indeling vertrouwt ook op CSS. Het is bedoeld om te bepalen of gebruikers de inhoud op de pagina gemakkelijk kunnen vinden en CSS helpt Google te begrijpen hoe de pagina is ingedeeld, zowel op desktop als mobiel, en waar elk stuk inhoud zich precies op de pagina bevindt: vooraan en in het midden, in de zijbalk of onderaan de pagina ver onder de vouw. 

Laten we nu een eenvoudige analogie gebruiken om te begrijpen hoe CSS en Javascript samenwerken. Stel je voor dat je een indrukwekkend feest plant. In dit geval speelt CSS de rol van feestdecorateur. U kunt CSS gebruiken om alles visueel aantrekkelijk te maken en de algehele sfeer te bepalen. Van het kiezen van themakleuren en het plaatsen van meubels tot het toevoegen van decoratieve elementen zoals ballonnen en slingers, CSS bepaalt hoe de feestlocatie eruitziet en aanvoelt.

Maar als u interactieve elementen aan uw feest wilt toevoegen, zoals games of een fotohokje, moet u JavaScript gebruiken. Zie het als de feestplanner die de spellen organiseert, de fotocabine opzet en ervoor zorgt dat alles soepel verloopt.

HTML en CSS zorgen naast JavaScript voor een fantastische feestervaring. Evenzo combineren CSS en JavaScript bij webontwikkeling hun sterke punten om de gebruikerservaring op websites te verbeteren.

Beste JavaScript-praktijken voor SEO

Aangezien we de meeste basisprincipes van Javascript hebben besproken, gaan we verder met enkele praktische tips die u kunt volgen bij het optimaliseren van uw JavaScript-website.

Zorg ervoor dat Google al uw inhoud kan ontdekken

Aangezien de webcrawler van Google, Googlebot, momenteel JavaScript-inhoud kan analyseren, hoeft de toegang tot bronnen die nodig zijn voor crawlen en weergeven niet te worden geblokkeerd.

Als u er zeker van wilt zijn dat uw JS-inhoud effectief wordt geïndexeerd, houdt u zich dan aan de volgende richtlijnen:

• Maak essentiële informatie binnen uw webpagina's zichtbaar in de broncode van de pagina. Dit zorgt ervoor dat zoekmachines niet afhankelijk zijn van gebruikersinteracties om inhoud te laden (bijvoorbeeld klikken op een knop).
• Ook al raadt Google het niet aan, je kunt toch JavaScript gebruiken om een rel=”canonieke” linktag. Google Zoeken herkent de linktag wanneer uw pagina wordt geladen. Zorg ervoor dat dit de enige op de pagina is. Als dit niet het geval is, kunt u uiteindelijk meerdere rel=”canonical”-linktags maken of een bestaande rel=”canonical”-linktag wijzigen, wat tot onverwachte gevolgen kan leiden.
• Javascript-frameworks, zoals Angular en Vue, genereren gewoonlijk op hash gebaseerde URL's (bijv. www.example.com/#/about-us) voor routering aan de clientzijde. Hoewel dit soort URL's naadloze navigatie bieden, kunnen ze SEO belemmeren en gebruikers verwarren. Zorg ervoor dat Gebruik gewone URL's om de gebruikerservaring, SEO en algehele zichtbaarheid van de website te verbeteren.

Volg de algemene best practices op de pagina

Als het gaat om Javascript-inhoud, zou het volgen van algemene SEO-richtlijnen op de pagina op uw prioriteitenlijst moeten staan. Het is vooral belangrijk om inhoud, titeltags, metabeschrijvingen, alt-attributen en metarobottags te optimaliseren. Enkele belangrijke best practices voor JavaScript voor SEO omvatten, maar zijn niet beperkt tot:

Gebruik de juiste links

Wat u moet onthouden bij het implementeren van JavaScript, is dat Google alleen JS-geïnjecteerde links volgt als ze correct zijn gecodeerd. Een HTML -tag met een URL en een href attribuut dat naar de juiste URL verwijst, is de gouden regel die u moet volgen. Zolang de tag er is, zit je goed, zelfs als je wat JS toevoegt aan de linkcode.

uw ankertekst

Ondertussen zijn alle andere variaties zoals links met een ontbrekende tag of href attribuut of zonder een juiste URL werkt voor gebruikers, maar Google kan ze niet volgen.

uw ankertekst uw ankertekst uw ankertekst geen link

Zeker, als je een sitemap, zou Google nog steeds uw webpagina's moeten ontdekken, zelfs als het geen interne links kan volgen die naar deze pagina's leiden. De zoekmachine geeft echter nog steeds de voorkeur aan links naar een sitemap, omdat deze de structuur van uw website en de manier waarop pagina's met elkaar verband houden, beter begrijpen. Bovendien stelt interne koppeling u in staat om verspreid linkjuice over je hele website. Kijk hier eens naar uitgebreide gids over interne links om te leren hoe het werkt.

Gebruik betekenisvolle HTTP-statuscodes

Ervoor zorgen dat HTTP-statuscodes relevant en zinvol zijn, is een essentiële SEO-praktijk die een cruciale rol speelt bij het faciliteren van goede communicatie met Googlebot. JavaScript kan dit proces vereenvoudigen. Als er bijvoorbeeld een 404-code of een andere fout wordt aangetroffen, worden gebruikers automatisch doorverwezen naar een aparte/niet-gevonden pagina. Door JavaScript te gebruiken om HTTP-statuscodes te beheren, kunnen websites een meer intuïtieve gebruikerservaring bieden, frustratie verminderen en bezoekers helpen bij het navigeren door mogelijke fouten.

Vermijd het blokkeren van belangrijke JavaScript-bestanden in uw robots.txt-bestand

Blokkeer geen essentiële JavaScript-bestanden in het robots.txt-bestand van uw website. Als u dit doet, kan Google uw inhoud niet openen, verwerken of zelfs maar gebruiken. Dit kan het vermogen van Google om uw website effectief te begrijpen en te rangschikken drastisch belemmeren.

Stel dat u JavaScript-inhoud van hoge kwaliteit heeft gegenereerd door dynamisch geladen tekst, interactieve elementen en cruciale metadata op te nemen. Maar laten we ook zeggen dat u het om de een of andere reden niet wilt laten crawlen. Hierdoor kan uw inhoud onopgemerkt blijven of ondervertegenwoordigd zijn in de indexen van zoekmachines. Dit zou dan leiden tot minder organisch verkeer, zichtbaarheid en algehele zoekprestaties.

Implementeer paginering correct

Wanneer SEO-experts te maken hebben met een enorme hoeveelheid website-inhoud, gebruiken ze vaak on-page optimalisatietechnieken zoals paginering en oneindig scrollen. Ondanks het feit dat deze praktijken verschillende voordelen kunnen opleveren, kunnen ze ook uw SEO-inspanningen belemmeren als ze niet op de juiste manier worden toegepast.

Een veel voorkomend probleem met paginering is dat bots van zoekmachines de neiging hebben om alleen het eerste deel van de gepagineerde inhoud te bekijken, waardoor onbedoeld de volgende pagina's worden verborgen. Dit betekent dat sommige van de waardevolle inhoudsstukken die u hebt gemaakt, onopgemerkt en niet-geïndexeerd kunnen blijven.

Om dit probleem op te lossen, implementeert u paginering met correcte links, naast gebruikersacties. Met behulp van <a href>-links kunnen zoekmachines eenvoudig elke gepagineerde pagina volgen en crawlen, zodat alle inhoud wordt gevonden en geïndexeerd.

Gebruik server-side of statische weergave 

Webcrawlers hebben, zoals hierboven vermeld, vaak moeite met het uitvoeren van JavaScript. Dit is de reden waarom crawlers dit type inhoud soms helemaal negeren. Paginacrawlers kunnen eenvoudigweg weigeren te wachten tot de dynamische inhoud volledig is weergegeven voordat de pagina wordt geïndexeerd. 

Om bots van zoekmachines te helpen bij het crawlen en indexeren van Javascript-inhoud, wordt het aanbevolen om server-side rendering te gebruiken. Bij dit proces wordt de webpagina op de server weergegeven voordat deze naar de browser van de gebruiker wordt verzonden. Deze praktijk zorgt ervoor dat de crawlers van zoekmachines volledig bevolkte webpagina's ontvangen en als gevolg daarvan de verwerkingstijd en -inspanning drastisch verminderen.

JS testen voor SEO

Zoals je misschien al geraden hebt, kan de manier waarop JavaScript is gecodeerd je website maken of breken. U kunt bijvoorbeeld gebruiken Google-tools zoals de Mobiel-vriendelijke Test om te zien hoe Google uw pagina's weergeeft. 

Testen moet bij voorkeur worden gedaan in de vroege ontwikkelingsfase wanneer dingen gemakkelijker kunnen worden opgelost. Met behulp van de mobielvriendelijke test kunt u elke bug in een vroeg stadium opsporen. Vraag uw ontwikkelaars gewoon om een ​​URL naar hun lokale hostserver te maken met behulp van speciale tools (bijv. ngok). 

Laten we nu eens kijken naar andere manieren waarop u Javascript voor SEO kunt testen.

Inspecteren in Chrome

Om te onderzoeken hoe zoekmachines uw JavaScript interpreteren, kunt u de hulpprogramma's voor ontwikkelaars van de Chrome-browser gebruiken. Open uw website in Chrome, klik met de rechtermuisknop op een element en selecteer "Inspecteren". Hierdoor wordt de ontwikkelaarsconsole geopend, waar u de HTML-structuur van de pagina kunt bekijken en kunt controleren of de gewenste JavaScript-inhoud zichtbaar is. Als de inhoud verborgen is of niet correct wordt weergegeven, is deze mogelijk niet toegankelijk voor zoekmachines.

U kunt ook op Command+Option+J (Mac) of Control+Shift+J (Windows, Linux, Chrome OS) drukken om de tool uit te voeren.

Hier in de bronnen tab, kunt u uw JS-bestanden vinden en de code inspecteren die ze injecteren. Vervolgens kunt u de JS-uitvoering pauzeren op een punt waarop u denkt dat er iets mis is gegaan met behulp van een van de Breekpunten van gebeurtenislistener en inspecteer het stuk code verder. Zodra je denkt dat je een bug hebt ontdekt, kun je de code live bewerken om in realtime te zien of de oplossing die je hebt bedacht het probleem verhelpt. 

Het mooie van Chrome-ontwikkelaarstools is dat alle wijzigingen worden toegepast in de gebruikersbrowsers en geen invloed hebben op andere gebruikers. Ze zullen weg zijn zodra je de verversen knop. De tool kan worden gebruikt om elke codefout te debuggen, niet alleen die met betrekking tot JavaScript. Dus mocht u problemen hebben met de CSS van uw website, dan komt de tool ook van pas.

Google Search Console

Google Search Console is een krachtige tool waarmee u de aanwezigheid van uw website in de zoekresultaten van Google kunt controleren en optimaliseren. Het biedt waardevolle inzichten in hoe Google uw site crawlt en indexeert. Ga hiervoor naar het gedeelte 'URL-inspectie' van Search Console. Vanaf hier kunt u individuele URL's indienen en zien hoe Google ze weergeeft, inclusief eventuele JavaScript-inhoud. Dit helpt u te bepalen of Google uw JavaScript-inhoud effectief kan openen en indexeren.

Klik op de "URL-inspectie" en gebruik vervolgens de functie "Live URL testen". Klik dan op Bekijk geteste pagina > Meer info > JavaScript-consoleberichten.

Google Cache

Het controleren van de Google-cache is een andere goede manier om te controleren of Google uw JavaScript-gestuurde inhoud indexeert. De Google-cache is een momentopname van uw webpagina die is gemaakt door de crawler van Google. U kunt tools gebruiken zoals de SE Ranking's Google Cache Checker om de gecachte versie van uw pagina te bekijken. Dit helpt u te bepalen of Google uw JavaScript-inhoud correct weergeeft en indexeert.

Tekst zoeken in Google

Om te bepalen of Google de inhoud indexeert die dynamisch door uw JavaScript-code wordt gegenereerd, voert u een specifieke zoekopdracht uit naar de unieke tekstreeks die door JavaScript wordt gegenereerd. Controleer nu of Google relevante resultaten retourneert. Als uw door JavaScript gegenereerde inhoud niet in de zoekresultaten wordt weergegeven, kan dit erop duiden dat Google deze niet correct indexeert.

Voer een site-audit uit

Een eenvoudige manier om Javascript voor SEO te testen en alle JS-gerelateerde fouten op uw site te ontdekken, is door een technische SEO-audit. Als u een SE Ranking-gebruiker bent, moet u verschillende secties van het probleemrapport van de website-audit controleren: JavaScript en HTTP-statuscodes.

SE Ranking vermeldt niet alleen alle fouten die op uw site zijn gedetecteerd, maar geeft ook tips over hoe u deze kunt oplossen.

Het wijst naar de exacte bestanden die een fout hebben veroorzaakt, zodat u weet welke bestanden u moet aanpassen om het goed te maken. Een enkele klik op de kolom met het aantal pagina's waar de fout optreedt, opent een volledige lijst met URL's van bestanden.

Lees ons artikel op hoe een website-audit te doen en geef prioriteit aan fixes en test de tool zelf door een uitgebreide website-audit te starten.

En als u elk type fout in meer detail wilt bestuderen, lees dan verder.

Veelvoorkomende JavaScript SEO-problemen en hoe u ze kunt vermijden

Nu vraag je je misschien af ​​welke veelvoorkomende SEO-problemen verband houden met deze programmatische taal. En het eerste dat het vermelden waard is, is dat Javascript afzonderlijk als bestanden wordt opgeslagen en vanuit de sectie. 

Browsers en Google moeten deze bronnen ophalen om de inhoud van de pagina volledig weer te geven. Soms kunnen Google en browsers, of alleen Google, de bestanden niet laden, en de redenen hiervoor zijn gebruikelijk voor zowel CSS als JavaScript. 

In minder ingrijpende gevallen kunnen Google en browsers de bestanden ophalen, maar laden ze te langzaam, wat de gebruikerservaring negatief beïnvloedt en ook de indexering van websites kan vertragen. 

Google kan geen JS-bestanden crawlen

Om uw JavaScript-bestanden op te halen, heeft Googlebot toestemming nodig om dit te doen. In het verleden was het gebruikelijk om Google de toegang tot deze bestanden te ontzeggen met het robots.txt-bestand, aangezien Google ze toch niet zou gebruiken. Nu de zoekgigant vertrouwt op JavaScript om de inhoud van websites te begrijpen, is het moedigt webmasters aan naar "toestaan ​​dat alle site-items worden gecrawld die de weergave van pagina's aanzienlijk zouden beïnvloeden: bijvoorbeeld CSS- en JavaScript-bestanden die het begrip van de pagina's beïnvloeden.” Als u de bestanden niet deblokkeert, kan Google ze niet weergeven en door JavaScript aangestuurde inhoud niet indexeren. 

Het blokkeren van JavaScript-bestanden is op zich geen negatieve rankingfactor. Maar als het alleen wordt gebruikt voor verfraaiing of als u om de een of andere reden niet wilt dat de door JS geïnjecteerde inhoud wordt geïndexeerd, kunt u JavaScript-bestanden geblokkeerd houden. Laat in alle andere gevallen Google uw bestanden renderen.

Google en browsers kunnen geen JS-bestanden laden

Na het lezen van het robots.txt-bestand om te controleren of u crawlen toestaat, doet Googlebot een HTTP-verzoek om toegang te krijgen tot uw JavaScript-URL's. Om door te gaan met het weergeven van de bestanden, moet het de 200 OK-antwoordcode krijgen. Soms worden echter andere statuscodes zoals 4XX of 5XX geretourneerd. Als u snel wilt weten wat verschillende statuscodes betekenen Deze gids is voor jou.

JavaScript met 4XX-status

4XX-antwoordcodes betekenen dat de gevraagde bron niet bestaat. Over JavaScript-bestanden gesproken, dit betekent dat Googlebot de URL's volgde die zijn aangegeven in de gedeelte van de pagina, maar heeft uw bestanden niet gevonden op de aangewezen locaties. Wanneer een pagina een 4XX retourneert, betekent dit meestal dat de pagina is verwijderd. Bij JavaScript treedt de fout vaak op omdat het pad naar het bestand niet correct is aangegeven. Het kan ook een toestemmingsprobleem zijn.

Het vervelende van 4XX-antwoordcodes is dat Google niet de enige is die problemen ondervindt bij het weergeven van uw JavaScript-bestanden. Browsers zullen dergelijke bestanden ook niet kunnen uitvoeren, wat betekent dat uw website er niet zo goed uitziet en zijn interactiviteit verliest.

Als JS wordt gebruikt om inhoud naar de website te laden (bijvoorbeeld wisselkoersen naar een respectieve website), zal alle dynamisch weergegeven inhoud ontbreken als de code niet goed werkt. 

Om de fout te herstellen, zullen uw ontwikkelaars eerst moeten uitzoeken wat de oorzaak is, en de redenen zullen variëren afhankelijk van de gebruikte technologieën.

JavaScript met 5XX-status

5XX-antwoordcodes geven aan dat er een probleem is aan de kant van uw webserver. Het betekent dat een browser of Googlebot een HTTP-verzoek verzendt, uw JavaScript-bestand lokaliseert, maar dat uw server het bestand vervolgens niet terugstuurt. 

In het ergste geval treedt de fout op omdat uw hele website ligt eruit. Het gebeurt wanneer uw server de hoeveelheid verkeer niet aankan. De abrupte toename van het verkeer kan natuurlijk zijn, maar in de meeste gevallen wordt het veroorzaakt door agressieve parsingsoftware of een kwaadaardige bot die uw server overspoelt met het specifieke doel om het neer te zetten (DDoS). 

De server kan ook geen JavaScript-bestand leveren als de browser ze niet binnen de ingestelde tijd kan ophalen, waardoor een 504 time-outfout. Dit kan gebeuren als de bestandenbundel te groot was of als een gebruiker een trage internetverbinding had.

Om dit te voorkomen, kunt u uw websiteserver zo configureren dat deze minder ongeduldig wordt. Maar de server te lang laten wachten is ook niet aan te raden.

Het punt is dat het laden van een enorme JS-bundel veel serverbronnen kost en als al uw serverbronnen worden gebruikt voor het laden van het bestand, kan het niet aan andere verzoeken voldoen. Als gevolg hiervan wordt uw hele website in de wacht gezet totdat het bestand wordt geladen.

JavaScript-bestanden laden niet snel genoeg

Laten we in dit gedeelte dieper ingaan op de problemen waardoor uw JavaScript-bestanden lang of net iets langer dan gewenst worden geladen. Zelfs als beide browsers en Googlebot erin slagen om uw JS-bestanden te laden en weer te geven, maar het even duurt om dit te doen, zou u zich zorgen moeten maken.

Hoe sneller een browser paginabronnen kan laden, hoe beter de gebruikerservaring, en als de bestanden langzaam worden geladen, moeten gebruikers even wachten voordat de pagina in hun browser wordt weergegeven.

JavaScript met 3XX-status

De 3xx-statuscode geeft aan dat de gevraagde bron is omgeleid en is essentieel voor het omleiden van de URL's in uw websitecode naar de nieuwe locatie. Dit geldt niet alleen voor het domein en het pad, maar ook voor het HTTP/HTTPS-protocol dat wordt gebruikt om de bron op te halen.

In het onderstaande voorbeeld wordt in eerste instantie naar het JavaScript-bestand verwezen met behulp van een HTTP-URL:

<script nomodule type="text/javascript" src="http://static.files.bbci.co.uk/orbit/7c43b78b94b8ed38e941a5a5336425e5/js/polyfills.js"></script>

De juiste en actuele URL voor het bestand moet echter HTTPS gebruiken:

<script nomodule type="text/javascript" src="https://static.files.bbci.co.uk/orbit/7c43b78b94b8ed38e941a5a5336425e5/js/polyfills.js"></script>

Googlebot en browsers halen de bestanden nog steeds op, aangezien uw server ze naar het juiste adres zal omleiden. Het voorbehoud is dat ze een extra HTTP-verzoek moeten doen om de bestemmings-URL te bereiken. Dit is niet goed voor de laadtijd. Hoewel de prestatie-impact misschien niet drastisch is voor een enkele URL of een paar bestanden, kan het op grotere schaal de laadtijd van de pagina aanzienlijk vertragen.

De oplossing hier ligt voor de hand: u hoeft alleen maar elke oude JavaScript-URL in de websitecode te vervangen door actuele bestemmings-URL's.

Caching is niet ingeschakeld 

Een geweldige manier om het aantal HTTP-verzoeken naar uw server te minimaliseren, is door caching in een antwoordheader toe te staan. Je hebt vast wel eens gehoord van caching - je krijgt vaak een suggestie om je browsercache te wissen als informatie op een website niet correct wordt weergegeven.

Wat cache eigenlijk doet, is dat het een kopie van uw websitebronnen opslaat wanneer een gebruiker uw site bezoekt. De volgende keer dat deze gebruiker uw website bezoekt, hoeft de browser de bronnen niet meer op te halen, maar krijgt de gebruiker in plaats daarvan de opgeslagen kopie te zien. Caching is essentieel voor de prestaties van de website, omdat het de latentie en netwerkbelasting vermindert. 

Cache-controle HTTP-header wordt gebruikt om cacheregels te specificeren die browsers moeten volgen: het geeft aan of een bepaalde bron al dan niet in de cache kan worden opgeslagen, wie deze kan cachen en hoe lang de in de cache opgeslagen kopie kan duren. Het wordt ten zeerste aanbevolen om caching van JS-bestanden toe te staan, aangezien browsers deze bestanden uploaden elke keer dat gebruikers een website bezoeken, dus als ze in de cache worden opgeslagen, kan de laadtijd van de pagina aanzienlijk worden verlengd. 

Hier is een voorbeeld van het instellen van caching voor JS-bestanden op één dag en openbare toegang.

Header set Cache-Control "max-age=86400, openbaar"

Het is echter vermeldenswaard dat Googlebot normaal gesproken de cache-control HTTP-header negeert, omdat het volgen van de richtlijnen van de website te veel belasting zou vormen voor de crawl- en weergave-infrastructuur.

Daarom is het raadzaam om, telkens wanneer u uw JS-bestand bijwerkt en wilt dat Google er kennis van neemt, uw bestand een andere naam te geven en het te uploaden met een andere URL. Op die manier zal Google het bestand opnieuw ophalen omdat het het zal behandelen als een totaal nieuwe bron die het nog niet eerder is tegengekomen.

Het aantal bestanden is belangrijk

Het gebruik van meerdere JavaScript-bestanden kan handig zijn vanuit het perspectief van de ontwikkelaar, maar qua prestaties is het niet geweldig. Browsers sturen een afzonderlijk HTTP-verzoek om elk bestand te laden en het aantal gelijktijdige netwerkverbindingen dat een browser kan verwerken, is beperkt. Daarom worden alle JS-bronnen van een pagina één voor één geladen, waardoor de weergavesnelheid afneemt.

Om deze reden wordt het aanbevolen om uw JavaScript-bestand te bundelen om het aantal bestanden dat een browser moet laden tot een minimum te beperken.

Vanuit het perspectief van Google zijn te veel JavaScript-bestanden geen probleem, wat betekent dat ze toch worden weergegeven. Maar hoe meer bestanden u heeft, hoe meer u uw crawlbudget besteedt aan het laden van JS-bestanden. Voor grote websites met miljoenen pagina's kan het van cruciaal belang zijn, omdat het zou betekenen dat Google sommige pagina's niet tijdig zal indexeren.

Bestandsgrootte is ook belangrijk 

Het probleem met het bundelen van JavaScript-bestanden is dat naarmate uw website groeit, nieuwe regels code aan de bestanden worden toegevoegd en uiteindelijk zo groot kunnen worden dat het een prestatie probleem.

Afhankelijk van de manier waarop uw website is gestructureerd, kan het redelijk zijn om niet al uw JavaScript-bestanden samen te bundelen, maar ze in plaats daarvan te groeperen in verschillende kleinere bestanden, zoals een apart bestand voor uw blog JavaScript, een ander bestand voor het forum JavaScript, enz. 

Een andere reden om één enorme JS-bundel te splitsen is caching. Als je alles in één bestand hebt, zullen browsers en Google elke keer dat je iets in je JS-code wijzigt, de hele bundel opnieuw moeten cachen. Dit is niet geweldig, zowel voor indexering als voor de gebruikerservaring. 

In termen van indexering het kan twee kanten op gaan, afhankelijk van de gebruikte caching-technologieën: u dwingt Googlebot om uw JS-bundel voortdurend opnieuw te cachen of Google merkt mogelijk niet op tijd op dat de cache niet langer geldig is en u krijgt Google verouderde inhoud te zien.

Nu we het toch gebruikerservaring, telkens wanneer u JS-code binnen de bundel bijwerkt, kunnen browsers geen kopieën meer in de cache aan uw gebruikers aanbieden. Dus zelfs als u alleen de JS-code voor uw blog wijzigt, zullen al uw gebruikers, inclusief degenen die uw blog nog nooit hebben bezocht, moeten wachten tot de browsers de hele JS-bundel hebben geladen om toegang te krijgen tot een pagina op uw website.

CSS en JavaScript comprimeren en verkleinen

Om uw JavaScript-bestanden licht te houden, wilt u ze comprimeren en verkleinen. Beide praktijken zijn bedoeld om de omvang van uw websitebronnen te verkleinen door de broncode te bewerken, maar ze zijn duidelijk verschillend.

Samendrukking is het proces van het vervangen van herhalende tekenreeksen in de broncode door verwijzingen naar de eerste instantie van die tekenreeks. Aangezien elke code veel herhalende delen heeft (denk aan hoeveel tags your JS contains) and pointers use less space than the initial code, file compression allows to reduce the file size by % tot 70. Browsers kunnen de gecomprimeerde code niet lezen, maar zolang de browser de compressiemethode ondersteunt, kan hij het bestand decomprimeren voordat het wordt weergegeven.

Het mooie van compressie is dat ontwikkelaars dit niet handmatig hoeven te doen. Al het zware werk wordt gedaan door de server, op voorwaarde dat deze is geconfigureerd om bronnen te comprimeren. Voor Apache-servers bijvoorbeeld een paar regels code worden toegevoegd aan het .htaccess-bestand om compressie mogelijk te maken. 

minification is het proces waarbij witruimte, niet-vereiste puntkomma's, onnodige regels en opmerkingen uit de broncode worden verwijderd. Het resultaat is dat u de code krijgt die niet helemaal leesbaar is voor mensen, maar nog steeds geldig is. Browsers kunnen dergelijke codes perfect weergeven en zelfs sneller ontleden en laden dan onbewerkte code. Webontwikkelaars zullen zelf voor minificatie moeten zorgen, maar met veel speciale tools zou dat geen probleem moeten zijn. 

Over het verkleinen van de bestandsgrootte gesproken, minificatie levert u niet de verbluffende 70% op. Als u al compressie hebt ingeschakeld op uw server, kan het verder verkleinen van uw bronnen u helpen hun grootte met nog een paar tot 16% te verminderen, afhankelijk van hoe uw bronnen zijn gecodeerd. Om deze reden zijn sommige webontwikkelaars van mening dat minificatie achterhaald is. Hoe kleiner uw JS-bestanden zijn. des te beter. Het is dus een goede gewoonte om beide methoden te combineren. 

Externe JavaScript-bestanden gebruiken

Veel websites hebben de neiging om externe JavaScript-bestanden te gebruiken die worden gehost op domeinen van derden. Het hergebruiken van een open-sourcecode die uw probleem perfect oplost, lijkt misschien een geweldig idee - het heeft tenslotte geen zin om het wiel opnieuw uit te vinden. Er is echt niets mis met het gebruik van een kant-en-klare oplossing, zolang deze maar wordt gekopieerd en geüpload naar de server van de website. Tegelijkertijd brengt het gebruik van JS-bestanden van derden die extern worden gehost, tal van risico's met zich mee. 

Eerst en vooral hebben we het over veiligheidsrisico's. Als een website die de bestanden host die u gebruikt, wordt gehackt, kunt u een schadelijke code uitvoeren die in het externe JS-bestand is geïnjecteerd. Hackers kunnen privégegevens van uw gebruikers stelen, inclusief hun wachtwoorden en creditcardgegevens.

Qua prestaties, denk aan alle hierboven besproken fouten. Als u geen toegang heeft tot de server waarop de JS-bestanden worden gehost, kunt u geen caching, compressie of debuggen van 5XX-fouten instellen.

Als de website die de bestanden host op een bepaald moment het bestand verwijdert en u dit niet tijdig opmerkt, zal uw website niet goed werken en kunt u een 404 JS-bestand niet snel vervangen door een geldig bestand.

Ten slotte, als de website die JS-bestanden host een 3XX-omleiding naar een (iets) ander bestand instelt, kan uw webpagina er anders uitzien en niet precies werken zoals verwacht. 

Als je toch JS-bestanden van derden gebruikt, is mijn advies om deze goed in de gaten te houden. Toch is een veel betere oplossing om helemaal geen externe JS te gebruiken.

Svetlana is hoofd content bij SE Ranking. Haar interesses strekken zich uit over digitale marketing, SEO en vertaling. Ze deelt haar expertise regelmatig op de SE Ranking-blog en via verschillende marketingmedia. Svetlana gelooft dat complexe begrippen in gewone woorden kunnen worden uitgelegd en houdt ervan om meeslepende verhalen te creëren.
Svetlana besteedt het grootste deel van haar avonduren aan het leren van nieuwe talen, het plannen van gedenkwaardige reizen en het aaien van haar kat.

• Door SEO aangedreven content en PR-distributie. Word vandaag nog versterkt.
• PlatoData.Network Verticale generatieve AI. Versterk jezelf. Toegang hier.
• PlatoAiStream. Web3-intelligentie. Kennis versterkt. Toegang hier.
• PlatoESG. Automotive / EV's, carbon, CleanTech, Energie, Milieu, Zonne, Afvalbeheer. Toegang hier.
• BlockOffsets. Eigendom voor milieucompensatie moderniseren. Toegang hier.
• Bron: https://seranking.com/blog/css-and-javascript-seo/