Tabbladen op productpagina's en vindbare inhoud

Een tabblad is gewoon een interface-keuze. Het wordt pas een vindbaarheidsvraag als de tekst erachter niet in de eerste HTML-respons zit. Google beschrijft in zijn uitleg over JavaScript en SEO (https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics) dat pagina's in drie fasen worden verwerkt: crawlen, renderen en indexeren. Bij klassieke of server-side gerenderde pagina's staat alle inhoud al in de HTML-respons. Bij sites die de inhoud pas met JavaScript opbouwen, moet Google eerst renderen om de echte inhoud te zien. Dat renderen gebeurt in een wachtrij, en de bron geeft aan dat die wachttijd kort of langer kan zijn. De bron stelt bovendien dat niet alle bots JavaScript uitvoeren.

Voor jouw productpagina betekent dit: tekst die al in de HTML staat, is het minst afhankelijk van die tussenstap. Tekst die pas verschijnt na een klik, een scroll of een aparte netwerkaanvraag, is dat wel. Dit artikel gaat over het onderzoeken van dat verschil. Het bewijst niet dat de ene aanpak beter rankt, en het belooft geen indexeringsuitkomst.

Er zijn grofweg vier technische varianten, en ze vragen een verschillende aanpak.

1. Verborgen in de HTML: alle tabpanelen staan in de bron, CSS of een attribuut verbergt ze tot de klik. De tekst is aanwezig in de respons.
2. Door JavaScript toegevoegd bij het laden: de HTML is bijna leeg, het script bouwt de panelen op. De tekst verschijnt pas na renderen.
3. Opgehaald na een klik: een klik op het tabblad start een aanvraag naar een eindpunt. Zonder klik bestaat de tekst niet in de pagina.
4. In een iframe of extern widget: de tekst hoort technisch bij een andere URL.

De eerste variant is meestal het eenvoudigst te beoordelen. De tweede en derde vragen extra controle, omdat je moet vaststellen wat een crawler zonder interactie te zien krijgt. Noteer per tabblad welke variant je aantreft. Twijfel je, dan is de vraag simpel: staat een unieke zin uit het tabblad in de ruwe bron?

1. Kies een testpagina met een duidelijk tabblad, bijvoorbeeld specificaties, en kopieer één unieke zin uit dat tabblad. Kies geen zin die ook elders op de pagina staat.
2. Bekijk de ruwe bron. Open de paginabron van je browser (de bron zoals de server hem aflevert, niet het geïnspecteerde DOM) en zoek op die zin. Staat hij erin, dan zit de tekst in de eerste HTML.
3. Vergelijk met het gerenderde DOM. Open de ontwikkelaarstools, zoek dezelfde zin in de elementen en kijk of hij pas zichtbaar is na een klik.
4. Volg het netwerkverkeer. Open het tabblad netwerk, ververs de pagina en klik daarna op het tabblad. Verschijnt er een nieuwe aanvraag op het moment van de klik, dan wordt de tekst bij interactie opgehaald (variant drie).
5. Controleer de blokkades. Google beschrijft dat Googlebot eerst robots.txt raadpleegt en geblokkeerde bestanden of pagina's niet rendert. Controleer daarom of scripts en eindpunten die de tabtekst leveren niet geblokkeerd zijn. Je browser negeert robots.txt, dus een geslaagde browsertest bewijst niet dat Googlebot erbij kan.
6. Vraag Google zelf. Gebruik de URL-inspectie in Search Console voor die pagina en bekijk de gerenderde HTML en de geïndexeerde versie. De live test toont wat Google nu kan ophalen, maar geeft niet de door Google gekozen canonical; die vind je alleen in de geïndexeerde inspectiedata. Waar precies je dat in je account vindt, kan wijzigen, dus controleer dat in je eigen omgeving.

Niet elk tabblad hoeft dezelfde behandeling. Gebruik onderstaande matrix als vertrekpunt en pas hem aan op je assortiment.

De regel hierachter: wat bezoekers nodig hebben om een aankoopbeslissing te nemen, hoort niet afhankelijk te zijn van een klik of een script. Bij twijfel kies je de eenvoudigste technische route, namelijk de tekst gewoon in de HTML.

Stel dat je een productpagina onderzoekt met vier tabbladen: Beschrijving, Specificaties, Levering en Reviews. De pagina is fictief en de uitkomsten zijn illustratief, ze tonen de werkwijze en voorspellen geen resultaat.

Invoer: je kiest per tabblad één unieke zin, zoek in de ruwe bron, volg het netwerkverkeer bij het klikken en noteer de bevindingen.

• Beschrijving: de zin staat in de ruwe bron. Variant één, geen actie.
• Specificaties: de zin staat niet in de ruwe bron maar wel in het DOM na het laden. Variant twee, actie: laten verplaatsen naar de eerste HTML.
• Levering: de zin ontbreekt in de bron en er verschijnt een netwerkaanvraag bij de klik. Variant drie, actie: tekst in de HTML plaatsen.
• Reviews: komen uit een extern widget in een iframe. Variant vier, beslissing aan de eigenaar.

Verwachte technische controles na de wijziging: de zinnen van Specificaties en Levering staan nu in de ruwe bron, er is geen netwerkaanvraag meer nodig voor die tekst, de URL-inspectie toont de tekst in de gerenderde HTML. Een 200-statuscode of een correcte weergave in je browser bewijst op zich niet dat Googlebot de pagina en de bijbehorende scripts mag crawlen, dus controleer ook robots.txt. Hoe lang het duurt voor Google dit overneemt, en of de pagina dan anders presteert, kan ik niet voorspellen.

Geef je ontwikkelaar een korte, controleerbare opdracht in plaats van een algemene wens. Een bruikbare overdracht bevat:

• de lijst met pagina's en tabbladen die je onderzocht hebt;
• per tabblad de variant (één tot vier) en de testzin;
• de gewenste uitkomst: de testzin staat in de ruwe bron, zonder klik en zonder extra aanvraag;
• de controlemethode: ruwe bron, DOM, netwerkverkeer en URL-inspectie.

Let daarnaast op de URL-structuur van de tabs en varianten. Google waarschuwt in zijn richtlijnen voor e-commerce (https://developers.google.com/search/docs/specialty/ecommerce/designing-a-url-structure-for-ecommerce-sites) dat Google fragmentidentifiers (zoals #tab) niet meeneemt bij het indexeren. Twee tabs die alleen via een fragment verschillen, tellen dus als dezelfde pagina. Wil je dat een tabblad een eigen vindbare pagina krijgt, dan heeft het een eigen URL nodig. Dat is een inhoudelijke keuze, geen verplichting.

Wil je zien welke zichtbare signalen je website nu geeft, bekijk ze dan via Marketing Scan. Een publieke scan meet zichtbare signalen en bewijst geen volledige technische implementatie, dus de bovenstaande controles blijven nodig.