Un vérificateur JavaScript SEO compare le HTML livré par une page au DOM capturé après l'exécution des scripts. Screpy utilise la réponse initiale de navigation principale et une véritable capture dans un navigateur isolé, puis extrait les mêmes champs SEO des deux documents. Le rapport présente les différences observées plutôt qu'un score de visibilité supposé.
Analysez la page publique exacte
Saisissez une URL publique HTTP ou HTTPS complète. Un nom d'hôte seul utilise HTTPS. Choisissez l'article, le produit ou la page de destination concerné sans supposer que l'accueil représente tous les modèles. Le résultat conserve les adresses demandée et finale et l'état HTTP.
Le navigateur utilise un contexte de bureau propre et anonyme à 1365 × 768. Il attend DOMContentLoaded, observe deux secondes puis capture le document. Aucun clic, défilement, connexion ou capture d'écran. Le contenu après consentement, interaction ou délai plus long peut manquer. Le guide JavaScript SEO de Google distingue rendu et indexation ; cette capture n'est pas le contenu indexé choisi par Google.
Comparez les valeurs avant d'interpréter
Le tableau compare titre dans head, meta description, canonical déclarées, valeurs robots et texte H1 conservé. Les titres SVG sont exclus. Les lignes robots contiennent le HTTP X-Robots-Tag initial avec les directives HTML ; un en-tête inchangé n'est pas attribué à JavaScript. Les détails montrent le total de H1 même si la liste affichée est limitée.
Le tableau indique aussi le nombre de mots du texte principal et de liens internes dans les deux versions. Ce sont des volumes observés, pas des scores de qualité ; les mesures absentes restent inconnues. Pour la hiérarchie, utilisez Heading Structure Analyzer.
Un nouveau titre peut être volontaire. Vérifiez si contenu et directives changent à l'encontre de vos objectifs de publication. Un noindex ou none nouvellement observé reçoit un signal plus fort, mais son périmètre par agent compte toujours. Utilisez Canonical Tag Checker pour déclaration et cible, ou Noindex Checker pour les directives source.
Gardez le rendu partiel visible
Le contrôle admet 75 récupérations de ressources et 20 MiB chacun pour le total transféré et décodé. Chaque réponse et le DOM capturé sont limités à 2 MiB. Les lectures ont six secondes, la navigation quinze et le rendu vingt-cinq dans un délai API de trente-cinq secondes. Il n'attend pas indéfiniment l'inactivité réseau.
Seules les ressources GET publiques passent par le lecteur limité. Destinations privées, requêtes modifiant des données, sous-cadres, téléchargements, service workers et WebSockets sont bloqués. Les requêtes bloquées ou inachevées donnent une couverture partielle car elles peuvent modifier scripts et contenu. Au plus vingt valeurs canonical, robots et H1 sont conservées, avec des limites de longueur et de texte principal. Lorsque ces limites s'appliquent, les conclusions textuelles potentiellement trompeuses sont omises.
Choisissez la suite d'après les preuves
Aucune modification observée signifie seulement que les champs capturés concordaient dans le périmètre couvert. Cela ne prouve pas l'absence de problèmes SEO. Les valeurs absentes des deux documents sont étiquetées absentes, pas comme métadonnées réussies. Si le rendu échoue, l'outil signale l'indisponibilité au lieu de remplacer la comparaison par la seule source.
Téléchargez JSON pour conserver valeurs, fenêtre d'observation et couverture ensemble. Revérifiez l'adresse exacte après modification. Pour une analyse source plus large, utilisez On-Page SEO Checker ; parité de rendu, accès réel des robots et indexation sont des questions distinctes.