Examinez les métadonnées publiques et des aperçus statiques du HTML, du CSS et des images, sans JavaScript, aux tailles ordinateur, tablette et mobile.
Examinez les métadonnées publiques et des aperçus statiques du HTML, du CSS et des images, sans JavaScript, aux tailles ordinateur, tablette et mobile.
https://clocktools.app/Utilisez une page HTTPS publique pour un aperçu statique ; HTTP fournit uniquement des métadonnées. N’incluez ni identifiants, ni ports personnalisés, ni liens signés, ni données personnelles.
1440×900 · 820×1180 · 390×844Ce sont des zones d’affichage en pixels CSS, pas des appareils précis ni un comparatif de navigateurs.
PNG · JSONLisez d’abord l’état de capture. Téléchargez un PNG uniquement si la capture réussit ; exportez séparément les métadonnées.
Avant de publier un modèle d’article, sélectionnez ordinateur et mobile, puis tablette si la largeur intermédiaire importe. Comparez titres, navigation, images et contenu visible aux dimensions exactes. Gardez PNG réussis et JSON dans le ticket. Testez séparément menus, formulaires et contenu JavaScript dans un navigateur normal.
Pendant une migration, lisez titre extrait, premier H1, canonical et robots avec URL finale et statut. Exportez les métadonnées même sans aperçu. Une canonical différente est un indice de configuration, pas le choix confirmé d’un moteur. Vérifiez balisage prévu et déploiement plutôt que de juger le référencement sur une capture.
Si l’aperçu paraît vide ou sans styles, commencez par les messages de capture et ressources omises. Comparez localement sans puis avec JavaScript. Cela aide à distinguer une coquille dynamique de CSS ou images manquants. Échec de capture et capture réussie de contenu pauvre sont différents et demandent des signalements différents.
Les media queries CSS adaptent les styles aux conditions d’affichage. Leurs pixels sont des pixels CSS, pas le nombre physique annoncé pour un téléphone. Une largeur de 390 pixels ne certifie donc pas un modèle de smartphone.
Une page peut fonctionner aux largeurs choisies et déborder entre elles. Vérifiez textes longs, orientation, zoom et interaction séparément. La première zone visible ne valide ni la suite de la page ni un parcours d’achat complet. Spécification W3C des media queries.
Un aperçu statique affiche le HTML, le CSS et les images pris en charge sans JavaScript. Les métadonnées sont extraites séparément du HTML source limité ; aucun résultat n’établit le DOM produit par JavaScript.
Seules les ressources HTTPS publiques validées sont admissibles. Scripts, polices externes, cadres, médias et connexions sont désactivés. Les ressources absentes modifient l’apparence ; un PNG valide peut montrer un site dynamique incomplet ou vide. Restrictions des requêtes du navigateur.
Exemple fictif : une page renvoie HTTP 200 et un titre, mais aucun aperçu. Cela établit une réponse source, pas une interface affichée. Consultez l’erreur précise ; HTTP, contenus non pris en charge et limites peuvent ne laisser que des métadonnées.
Les choix sont ordinateur 1440 × 900, tablette 820 × 1180 et mobile 390 × 844. Ordinateur et mobile sont cochés par défaut ; ajoutez tablette pour l’entre-deux. Au moins une taille reste sélectionnée. Ce sont des viewports fixes, pas un catalogue d’appareils. Largeur personnalisée, orientation, famille de navigateur et émulation tactile ne sont pas réglables ici.
Testez un chemin HTTPS public précis, pas seulement l’accueil. Article long, liste de produits et traduction peuvent solliciter le modèle autrement. Comparez le même chemin aux tailles pertinentes et notez ce qui apparaît dans la zone initiale. La spécification W3C des media queries décrit des conditions CSS dépendant de la largeur ; ici, la question pratique est la lisibilité du layout statique à ces tailles.
Dans l’exemple fixe, le titre passe d’une ligne sur ordinateur à trois sur mobile. Cela n’est pas forcément un défaut. Cherchez mots coupés, chevauchements ou action principale repoussée sans suite utile. Vérifiez aussi largeurs intermédiaires, zoom du texte et orientation localement. Trois échantillons réussis ne valident pas chaque breakpoint ou appareil.
| Viewport | Revue utile | Non établi |
|---|---|---|
| 1440 × 900 | Navigation large, colonnes, titres | Tous les écrans, navigateurs et niveaux de zoom |
| 820 × 1180 | Transitions intermédiaires | Tablette précise ou comportement tactile |
| 390 × 844 | Texte étroit, images et première zone | Téléphone précis, clavier ou toutes les largeurs mobiles |
L’aperçu dessine HTML récupéré, CSS et images pris en charge avec JavaScript désactivé. Un titre produit côté serveur peut apparaître tandis qu’un graphique client manque. Seul le premier viewport est capturé, pas toute la page. Une PNG valide prouve une capture statique aux dimensions choisies, pas le chargement complet de l’application interactive.
Polices externes, cadres et médias sont exclus. Une police de repli change parfois largeur des mots, retours à la ligne et hauteur ; des icônes de police peuvent disparaître. Si des ressources sont omises, traitez l’image comme partielle. Cherchez quelles différences peuvent venir de ces omissions avant de modifier l’espacement du site.
La limite est utile pour observer l’HTML initial. Dans un exemple fixe, un article serveur garde ses textes sans JavaScript, une application envoyant seulement un conteneur racine peut sembler pauvre malgré 200 et un titre. Cela n’évalue pas seul amélioration progressive ou disponibilité générale. Comparez votre source et navigateur normal pour décider si l’absence est prévue.
Les métadonnées sont extraites séparément du HTML reçu, et non d’un DOM modifié par JavaScript ou des pixels de l’aperçu. Les lignes visibles du panneau de résultats présentent le statut de la réponse, le titre, le premier H1, canonical, robots, le type de contenu, la taille du HTML inspecté et le temps de réponse approximatif. L’export JSON conserve aussi la description et la valeur viewport extraites, l’URL finale et les redirections ; description et viewport n’ont pas de lignes visibles distinctes. Utilisez ces informations complémentaires pour distinguer configuration de la page et problème de capture, sans y voir un verdict de moteur de recherche.
Un champ absent ou vide ne prouve pas que le balisage correspondant manque dans la page complète. L’analyseur HTML lit les attributs par leur nom : changer leur ordre n’empêche pas l’extraction, et les attributs usuels avec ou sans guillemets sont pris en charge. L’inspection reste toutefois limitée ; une troncature peut laisser des balises ultérieures hors du texte examiné. Seul le premier H1 est rapporté, pas le plan complet des titres, et le contenu produit par JavaScript n’est pas examiné. Si l’analyse échoue, le résultat indique des métadonnées indisponibles et une capture en échec, sans confirmer l’absence de balises. Comparez le code source de la réponse anonyme au DOM modifié de votre navigateur avant d’ajouter des balises en double comme remède supposé.
La relation canonical HTML indique une URL préférée. Vérifiez qu’elle correspond à la page voulue et non à un ancien environnement ; l’outil ne prouve pas le choix d’un moteur. La documentation robots de Google explique les directives, mais une valeur meta n’est pas un verdict de crawl ou d’indexation. Les directives d’en-tête et d’autres conditions doivent être inspectées séparément.
Un titre familier accompagné d’une page de connexion ou contrôle demande de comparer la réponse anonyme, pas de conclure à un rendu authentifié. Métadonnées et aperçu proviennent de requêtes séparées ; contenu, cache et instant du déploiement peuvent varier. Gardez les statuts ensemble sans utiliser l’un pour combler les preuves manquantes de l’autre.
Lisez séparément chaque taille. Une capture réussie ne valide pas celle qui a échoué sur mobile. Les métadonnées seules restent utiles, mais sans preuve visuelle de ce viewport. HTTP ne fournit que des métadonnées : utilisez l’adresse HTTPS publique réelle pour une capture, sans supposer qu’une redirection HTTP change cette capacité.
Si la récupération des métadonnées échoue, résolvez d’abord ce point. Pour la capture, lisez l’erreur précise : statut source, contenu non pris en charge, redirection ou limite de requêtes, octets et temps peuvent empêcher l’acceptation. PDF et JSON ne sont pas un test de layout HTML. Ne pas obtenir de capture acceptée n’est pas la même chose qu’obtenir une capture acceptée qui semble vide.
Pour une image partielle acceptée, comparez les éléments omis et les symptômes visibles. Si le texte apparaît sans mise en forme, vérifiez les feuilles de style CSS et leur type de contenu. Si des images manquent, vérifiez qu’elles sont bien accessibles. Si une application affiche très peu de contenu, examinez sa dépendance à JavaScript. Ce sont des pistes de recherche, pas des diagnostics établis. Modifiez votre site seulement après avoir reproduit le problème avec ses véritables fichiers sources et requêtes.
| Résultat | Ce que vous pouvez dire | À conserver |
|---|---|---|
| Métadonnées seules | Source disponible, pas d’aperçu accepté pour cette taille | Statut, URL, champs et erreur de capture |
| PNG statique acceptée | Premier viewport statique capturé | Dimensions, heure, PNG et omissions |
| PNG acceptée pauvre ou vide | Peu de contenu visible dans le document statique | Comparaison source et test local sans JavaScript |
| Une taille échouée | Couverture incomplète | Résultats par taille, pas seulement la réussite |
Conservez chemin, tailles, heure, métadonnées et résultats par viewport dans JSON. Téléchargez PNG uniquement en cas de capture réussie. L’image documente l’apparence, JSON le contexte et les erreurs perdus après recadrage. Un nom de fichier ne suffit pas à prouver page, instant et conditions.
Décrivez élément, largeur et conséquence : un long nom produit tronqué à 390 pixels, lisible à 820, par exemple. Joignez chemin public et éventuelle influence des ressources omises ou de JavaScript absent. C’est plus utile que « mobile échoué », surtout si l’opération de capture a réussi.
Terminez localement : clavier, menus, formulaires autorisés, états de chargement et erreur. Contrôlez les navigateurs et appareils réellement pris en charge. Cet outil statique ne mesure pas accessibilité, Core Web Vitals ou latence d’interaction. Annulez ou réinitialisez au changement d’entrée ; partager ne fige ni page ni résultat.
Nous vérifions séparément les métadonnées et l’apparence statique de la page, sans connexion à un compte ni identifiants privés. Chaque aperçu accepté respecte les dimensions choisies. Si un aperçu ou une ressource manque, nous le signalons : les métadonnées ne prouvent pas à elles seules que toute la page a été affichée.
Il s’agit de la zone initialement visible, pas d’un rendu JavaScript complet, d’une capture de toute la page, d’un score de performance ou d’un audit d’accessibilité. Les polices externes, contenus intégrés, médias et éléments chargés dynamiquement peuvent manquer. Le résultat peut donc différer de votre navigateur. Utilisez uniquement des pages publiques et vérifiez les interactions sur vos appareils. Une fois le test annulé, son résultat tardif ne remplace pas la vue actuelle.
Signalez un problème reproductible via la page Contact en indiquant l’URL de l’outil, une entrée non confidentielle, l’heure de vérification, le résultat attendu et la preuve source. Joignez si possible la réponse publique, sans données de compte ni lien secret. Une modification de la source n’est pas forcément une erreur de calcul. Comparez le même nom, la même page et le même instant.
HTTP, contenu non pris en charge, erreur source ou limite peuvent laisser des métadonnées sans image acceptée. Lisez l’avis propre à chaque taille. Titre et réponse ne prouvent pas une page dessinée, et une capture absente ne diagnostique pas un site vide.
Non. Il dessine HTML, CSS et images pris en charge sans script de page. Widgets, routes et contenus client peuvent manquer. Comparez navigateur normal et vue locale sans JavaScript ; une image statique réussie ne constitue pas un test réussi de l’application interactive.
Non. Ils fixent 1440 × 900, 820 × 1180 et 390 × 844. Ils ne prouvent ni tactile, ni densité de pixels, ni système ou famille de navigateur. Faites vos propres essais responsive et sur appareils pour ces conditions.
Les polices externes sont exclues ; le repli peut modifier retours et espacement, voire supprimer des icônes. Cadres, médias et ressources dynamiques peuvent aussi manquer. Lisez les omissions avant de qualifier la différence de défaut CSS.
Non. C’est une réponse HTTP, pas la réussite de chaque ressource ou interaction. Une coquille JavaScript peut renvoyer 200 tout en montrant peu de contenu statique. Lisez les captures et avis par taille puis testez le comportement réel localement.
Ils peuvent être ajoutés par JavaScript, absents de la source anonyme ou non reconnus par l’extracteur limité. La troncature peut aussi supprimer du balisage tardif. Comparez la source, pas seulement le DOM, avant de modifier ou dupliquer les tags.
Non. Elle montre le viewport initial choisi. Contenu inférieur, défilement, chargement différé et éléments fixes après défilement nécessitent une revue distincte. Le téléchargement est une vue visible, pas une preuve que toutes les sections ont été examinées.
Non. Utilisez des pages publiques sans identifiants, tokens secrets ou données de compte. Votre connexion n’est pas transmise. Examinez le privé localement avec vos outils autorisés plutôt que d’envoyer son lien d’accès à un vérificateur public.
Non. Elles n’établissent ni indexation, ni canonical choisie, ni accessibilité. Pour le référencement, consultez les outils de crawl, source et directives d’en-tête. Pour l’accessibilité, faites une évaluation distincte au clavier et avec technologies d’assistance. Une image propre ne suffit pas.