Belangrijke inhoud mag niet afhangen van een klik, een bepaalde scrolling of een te ontdekken verbinding. Controleer wat het eerste antwoord bevat en wat er verschijnt na het renderen. De technische keuze moet zowel bezoekers, onderhoud als motortoegang bedienen.
Onderscheid initiële HTML en gerenderde pagina
De code die door de browser wordt ontvangen, kan slechts één skelet bevatten en vervolgens ingevuld door JavaScript. Google beschrijft een behandeling inclusief exploratie, rendering en indexering. Het feit dat een engine JavaScript kan uitvoeren, garandeert niet dat elke afhankelijkheid of interactie zal werken. Vergelijk dus de eerste reactie met de inhoud die wordt weergegeven op de pagina's die uw aanbiedingen en uw redactionele reacties bevatten.
Gewone omstandigheden testen
Open een pagina in een openbare sessie, met een langzaam netwerk, en controleer wat er beschikbaar blijft als een resource mislukt. Zijn de titel, beslissende tekst en links naar nuttige pagina's aanwezig? API-fouten mogen een bestaand bestand niet in een lege pagina veranderen. Controleer ook of de laadstatussen niet voor onbepaalde tijd worden weergegeven.
Een acceptatietest in drie staten op dezelfde pagina
Test de pagina vanaf de directe URL en vervolgens na het intern browsen, en vervolgens met een niet-beschikbare afhankelijkheid in uw acceptatietestomgeving. U wilt weten wat de bezoeker in elke staat kan lezen en doen. De mogelijkheid om JavaScript te maken, haakt niet af van serveerfouten, links en consistente inhoud. De volgende checkpoints zijn zowel van toepassing op een gids als op een productblad.
| Element | vraag in de initiële HTML | vraag na rendering |
|---|---|---|
| Titel en beslissende tekst | Zijn het onderwerp en het antwoord aanwezig? | Is de tekst volledig en altijd consistent? |
| Links tussen pagina's | Kunnen echte bestemmingen worden geëxtraheerd? | Produceert navigatie goede URL's? |
| Productgegevens | Komen de waarden overeen met het gevraagde product? | Verandert een interactie de variant correct? |
| Fout of gebrek aan middelen | Zijn de status en het bericht geschikt? | Kan een laadfout worden begrepen? |
| metadata | Heeft de pagina zijn eigen identiteit? | Creëert een update aan de clientzijde een contradictie? |
De JavaScript SEO-principes gedocumenteerd door Google Maak onderscheid tussen verkenning, rendering en indexering. Uw acceptatietest moet deze stappen gescheiden houden. Een zichtbare tekst in uw browser is een weergave van de weergave onder deze voorwaarden, geen bewijs dat alle zoekervaringen het kunnen of zullen gebruiken.
Navigatie expliciet maken
Gebruik HTML-links met een echte bestemming voor cross-page routes. Een knop die alleen de status van een applicatie wijzigt, vervangt niet altijd een deelbare URL. Voor een catalogus moet elk belangrijk product direct kunnen worden geopend. Controleer omleidingen en statussen die worden geretourneerd tijdens directe toegang, niet alleen tijdens het browsen vanuit huis.
Fictief voorbeeld: kenmerken in een tabblad
Een vel laadt zijn afmetingen pas na het openen van een tab. Het team plaatst de beslissende informatie op de openbaar beschikbare pagina en gebruikt vervolgens het tabblad om de lezing te organiseren. Het regelt het resultaat op mobiel en in de pagina-inspectie. Het doel is niet om JavaScript te verbieden, maar om te voorkomen dat kwetsbare actie de toegang tot de kenmerken die nodig zijn voor de beslissing conditioneert.
Beslis wat u beschikbaar maakt zonder interactie
Voor een artikel kunnen het belangrijkste antwoord en nuttige links meestal bij de pagina komen. Voor een catalogus kan de interface interactief blijven en tegelijkertijd een directe URL bieden die het product en de essentiële informatie identificeert. Secundaire functies, zoals een aanpassingstool, vereisen een schone analyse: het interactief maken betekent niet dat de rest van de kaart aan het begin leeg moet zijn.
- Kies een representatieve sjabloon en pak de openbare inhoud. Maak een leesbare vergelijking tussen de ontvangen code en de uiteindelijke inhoud, met de datum- en testvoorwaarden.
- Inspecteer belangrijke links. Een HTML-link met href en echte bestemming is directer bruikbaar dan een actie die alleen een interne status zonder URL verandert.
- Zorg ervoor dat een noodzakelijke resource in de testomgeving mislukt. Controleer het bericht, de mogelijkheid om het opnieuw te proberen en wat toegankelijk blijft. Veroorzaak niet vrijwillig een storing in de productie voor deze demonstratie.
- Corrigeer eerst het defect dat op deze sjabloon is waargenomen en controleer vervolgens de andere pagina's die het gebruiken. Meet ook het effect op snelheid en onderhoud voordat u een nieuwe architectuur generaliseert.
Google's document op Verkenbare links Geeft voorbeelden van interpreteerbare links. Voor een herstelproject kan dit acceptatietest worden geïntegreerd in de specificaties: we verwachten een verifieerbare reactie, navigatie en foutstatus, niet alleen een succesvolle screenshot. De diagnose van CDN-sloten blijft extra als de inhoud niet de browser of de robot bereikt.
Kies een evenredige correctie
Een server-side rendering of het genereren van pagina's kan relevant zijn, maar volledige migratie is niet altijd vereist. Begin met een representatief sjabloon, meet toegang, prestaties en eenvoudig bijwerken. Controleer vervolgens metadata en links in beide versies. De Reduction of unnecessary javascript kan dit werk voltooien zonder snelheid en indexeerbaarheid te verwarren.