Website-Darstellung prüfen

Öffentliche Seitenmetadaten und statische Vorschauen aus HTML, CSS und Bildern ohne JavaScript in Desktop-, Tablet- und Smartphone-Größen prüfen.

So funktioniert es

Öffentliche Seitenmetadaten und statische Vorschauen aus HTML, CSS und Bildern ohne JavaScript in Desktop-, Tablet- und Smartphone-Größen prüfen.

Schritt 1

Öffentliche Seite eingeben

Beispiel, kein Live-Ergebnishttps://clocktools.app/

Nutze eine öffentliche HTTPS-Seite für eine statische Vorschau; HTTP liefert nur Metadaten. Keine Zugangsdaten, eigenen Ports, signierten Links oder personenbezogenen Kennungen eingeben.

Schritt 2

Ansichtsgrößen wählen

Beispiel, kein Live-Ergebnis1440×900 · 820×1180 · 390×844

Die Größen sind CSS-Viewports, keine bestimmten Geräte und kein Browservergleich.

Schritt 3

Belege prüfen

Beispiel, kein Live-ErgebnisPNG · JSON

Lies zuerst den Aufnahmestatus. Lade PNG nur bei erfolgreicher Aufnahme herunter; Metadaten lassen sich getrennt exportieren.

Praktische Anwendungen

Responsive Änderung prüfen

Wähle vor der Freigabe einer öffentlichen Artikelvorlage Desktop und Smartphone, bei Bedarf zusätzlich Tablet. Vergleiche Titelumbrüche, Navigation, Bilder und sichtbare Inhalte bei den genauen Breiten. Bewahre erfolgreiche PNGs und JSON im Freigabeticket auf. Menüs, Formulare und JavaScript-Inhalte brauchen anschließend normale Browsertests.

Metadaten übergeben

Prüfe bei einem Seitenumzug abgerufenen Titel, erstes H1, Canonical und Robots zusammen mit Ziel-URL und Status. Exportiere Metadaten auch ohne Vorschau. Ein abweichendes Canonical ist ein Konfigurationshinweis, keine bestätigte Suchmaschinenwahl. Kontrolliere vorgesehenes Quell-Markup und Bereitstellung, statt SEO anhand eines Bildes zu beurteilen.

Fehler eingrenzen

Wirkt die Vorschau leer oder ungestaltet, lies Aufnahme- und Ressourcenhinweise zuerst. Vergleiche die Seite lokal ohne und dann mit JavaScript. Das kann eine dynamische Hülle von fehlenden Stylesheets oder Bildern unterscheiden. Gescheiterte Aufnahme und erfolgreiche Aufnahme spärlicher Inhalte sind unterschiedliche Ergebnisse und benötigen andere Fehlermeldungen.

Hintergrund und Technik

Abgeschlossene statische Desktop-Vorschau von example.com
Die Desktop-Aufnahme von example.com zeigt die abgerufene Seite ohne JavaScript sowie Antwortdaten und Metadaten. Sie ist eine statische Ansicht, kein Test der Interaktion oder verschiedener Browser.

Layouts reagieren auf Viewports

CSS-Media-Queries passen Styles an Viewport-Bedingungen an. Ihre Pixelangaben beziehen sich auf CSS-Pixel, nicht die physische Pixelzahl eines Telefons. 390 Pixel Breite zertifizieren daher kein bestimmtes Smartphone.

Eine Seite kann an den gewählten Breiten funktionieren und dazwischen überlaufen. Prüfe lange Texte, Drehung, Zoom und Bedienung separat. Der erste Bildausschnitt bestätigt weder den Bereich darunter noch einen vollständigen Bestellvorgang. W3C-Spezifikation zu Media Queries.

Bild und HTML beantworten andere Fragen

Eine statische Vorschau stellt abgerufenes HTML, CSS und unterstützte Bilder ohne JavaScript dar. Metadaten werden separat aus begrenztem Quell-HTML gewonnen; kein Ergebnis belegt einen durch JavaScript erzeugten DOM.

Nur geprüfte öffentliche HTTPS-Ressourcen kommen für die Vorschau infrage. Skripte, externe Schriften, Frames, Medien und Verbindungen sind deaktiviert. Fehlende Ressourcen verändern die Darstellung; selbst eine gültige PNG kann eine unvollständige oder leere dynamische Seite zeigen. Zugriffsbeschränkungen für Browseranfragen.

Beispiel: HTTP 200 ohne Screenshot

Beispiel: Eine Seite liefert HTTP 200 und einen Titel, aber keine Vorschau. Das belegt eine Quellantwort, keine dargestellte Oberfläche. Prüfe den konkreten Fehler; HTTP-Seiten, nicht unterstützte Inhalte und Aufnahmegrenzen können nur Metadaten liefern.

HTTP-Antwort
200
Vorhandener Beleg
Quell-Metadaten
Nicht belegt
Darstellung und erfolgreiche Bedienung

Breiten nach der konkreten Layoutfrage wählen

Verfügbar sind Desktop 1440 × 900, Tablet 820 × 1180 und Smartphone 390 × 844. Desktop und Smartphone sind voreingestellt; ergänze Tablet für die Zwischenbreite. Mindestens eine Auswahl bleibt bestehen. Die Größen sind feste Viewports, kein Gerätekatalog. Eigene Breite, Ausrichtung, Browserfamilie oder Touch-Emulation sind hier nicht einstellbar.

Prüfe einen konkreten öffentlichen HTTPS-Pfad, nicht nur die Startseite. Lange Artikel, Produktlisten und übersetzte Texte beanspruchen Vorlagen unterschiedlich. Vergleiche denselben Pfad in den relevanten Größen und notiere Inhalte im ersten sichtbaren Bereich. Die W3C-Media-Query-Spezifikation beschreibt breitenabhängige CSS-Bedingungen; hier zählt praktisch, ob das statische Layout bei jeder gewählten Breite brauchbar bleibt.

Im festen Beispiel steht ein Titel am Desktop in einer, mobil in drei Zeilen. Das allein ist kein Fehler. Achte auf abgeschnittene Wörter, überdeckte Elemente oder eine Hauptaktion, die ohne sinnvolle Fortsetzung verschwindet. Zwischenbreiten, Textzoom und Ausrichtung prüfst du lokal. Drei gelungene Stichproben bestätigen weder jeden Breakpoint noch ein bestimmtes Gerät.

Größen und ihre sinnvollen Prüfziele
ViewportNützliche PrüfungNicht bestätigt
1440 × 900Breite Navigation, Spalten und TitelumbrücheAlle Desktopmonitore, Browser und Zoomstufen
820 × 1180Übergang von Navigation und SpaltenBestimmtes Tablet oder Touchverhalten
390 × 844Schmale Texte, Bildgrößen und ErstansichtBestimmtes Telefon, Tastaturverhalten oder alle Mobilbreiten

Verstehen, was tatsächlich dargestellt wird

Die Vorschau zeichnet abgerufenes HTML, unterstütztes CSS und Bilder mit deaktiviertem JavaScript. Ein serverseitiger Titel kann erscheinen, ein clientseitiges Diagramm fehlen. Aufgenommen wird der erste Viewport, nicht die ganze Seite. Inhalte darunter wurden nicht visuell geprüft. Eine gültige PNG bestätigt eine statische Aufnahme in der gewählten Größe, nicht das vollständige Laden der interaktiven Website.

Externe Schriften, Frames und Medien sind ausgeschlossen. Ersatzschriften können Wortbreiten, Umbrüche und Höhen ändern; schriftbasierte Icons können fehlen, während normale Bilder erscheinen. Meldet der Bericht ausgelassene Ressourcen, behandle das Bild als unvollständig. Überlege vor Layoutänderungen, welche sichtbaren Abweichungen daraus folgen könnten.

Diese Grenze hilft beim Prüfen des anfänglichen HTML. Im festen Vergleich behält ein serverseitiger Artikel seine Texte ohne JavaScript, während eine Anwendung mit nur einem Wurzelcontainer trotz HTTP 200 und Titel spärlich wirken kann. Kein Befund bewertet allein progressive Verbesserung oder allgemeine Verfügbarkeit. Vergleiche eigene Quellantwort und normale Browseransicht, um beabsichtigte von unerwarteten Lücken zu unterscheiden.

Quellmetadaten ohne Bewertungspunktzahl lesen

Metadaten werden getrennt aus dem abgerufenen HTML extrahiert, nicht aus einem durch JavaScript veränderten DOM oder aus Bildpixeln. Die sichtbaren Ergebniszeilen zeigen Antwortstatus, Titel, erstes H1, Canonical, Robots, Inhaltstyp, untersuchte HTML-Datenmenge und ungefähre Antwortzeit. Der JSON-Export enthält zusätzlich die extrahierte Beschreibung und den Viewport-Wert sowie die endgültige URL und Weiterleitungen; Beschreibung und Viewport haben keine eigenen sichtbaren Zeilen. Nutze diese zusätzlichen Angaben, um Seitenkonfiguration und Aufnahmeproblem auseinanderzuhalten. Weder Metadaten noch Aufnahme bestätigen eine Suchmaschinenbewertung.

Ein fehlendes oder leeres Feld beweist nicht, dass entsprechendes Markup auf der vollständigen Seite fehlt. Der HTML-Parser liest Attribute anhand ihres Namens; eine andere Reihenfolge verhindert die Extraktion nicht. Übliche Attribute mit oder ohne Anführungszeichen werden unterstützt. Die Untersuchung ist jedoch begrenzt: Wird der Quelltext abgeschnitten, können spätere Tags außerhalb des untersuchten Abschnitts liegen. Gemeldet wird das erste H1, nicht die gesamte Überschriftenstruktur; durch JavaScript erzeugte Inhalte werden nicht untersucht. Scheitert die Verarbeitung, meldet das Ergebnis nicht verfügbare Metadaten und eine fehlgeschlagene Aufnahme, statt fehlende Tags zu bestätigen. Vergleiche den anonym abgerufenen Quelltext mit dem veränderten DOM deines Browsers, bevor du vorsorglich doppelte Tags hinzufügst.

Die HTML-Canonical-Relation bezeichnet eine bevorzugte Dokument-URL. Prüfe auf alte Umgebungen oder falsche Pfade; der Checker bestätigt keine Suchmaschinenwahl. Googles Robots-Dokumentation erläutert Crawleranweisungen, doch ein angezeigter Meta-Wert ist kein Crawl- oder Indexierungsurteil. Headeranweisungen und weitere Bedingungen sind gesondert zu prüfen.

Ein vertrauter Titel neben Anmelde- oder Schutzseite verlangt einen Vergleich der anonymen Antwort, nicht die Annahme gelungener Anmeldung. Metadaten und Aufnahme sind separate Anfragen; Inhalte, Cachezustand oder Bereitstellungszeit können abweichen. Bewahre die Zustände gemeinsam auf, ohne mit einem Ergebnis fehlende Belege des anderen zu ersetzen.

Reine Metadaten, Teilansicht und Aufnahme unterscheiden

Lies das Ergebnis jeder Größe einzeln. Ein erfolgreiches Desktopbild bestätigt keine gescheiterte Mobilaufnahme. Reine Metadaten können nützlich sein, enthalten aber keinen visuellen Beleg für die fehlende Größe. HTTP liefert nur Metadaten. Verwende für eine statische Vorschau die tatsächliche öffentliche HTTPS-Adresse; eine HTTP-Weiterleitung erweitert diese Fähigkeit nicht automatisch.

Scheitert der Metadatenabruf, kläre diesen Fehler zuerst. Bei Aufnahmeproblemen lies die genaue Meldung: Quellstatus, nicht unterstützter Inhalt, Weiterleitung oder Anfrage-, Größen- und Zeitgrenzen können die Annahme verhindern. PDF und JSON sind keine HTML-Layouttests. Beschreibe solche Fälle nicht pauschal als leere Seite; keine akzeptierte Aufnahme ist etwas anderes als ein Bild ohne sichtbaren Inhalt.

Bei einer akzeptierten Teilansicht vergleiche Ressourcenhinweise mit Symptomen. Ungestalteter Text legt eine Prüfung des CSS-Pfads und Inhaltstyps nahe, fehlende Bilder eine Prüfung ihrer Auslieferung, eine spärliche Anwendung ihre JavaScript-Abhängigkeit. Das sind Ermittlungsansätze, keine fertigen Diagnosen. Ändere die eigene Seite erst nach Reproduktion mit echten Quellen und Anfragen.

Belege für ein Rendering-Ticket
ErgebnisBelastbare AussageAufbewahren
Nur MetadatenQuellinformationen vorhanden, keine akzeptierte Ansicht dieser GrößeStatus, Ziel-URL, Quellfelder und Aufnahmefehler
Akzeptierte statische PNGErster statischer Viewport aufgenommenGröße, Zeit, PNG und Ressourcenhinweise
Spärliche oder leere akzeptierte PNGStatisches Dokument zeigte wenig InhaltQuellvergleich und lokaler Test ohne JavaScript
Eine Größe gescheitertPrüfabdeckung unvollständigAlle Größenbefunde, nicht nur das gelungene Bild

Ein brauchbares Prüfpaket zusammenstellen

Bewahre Pfad, Größen, Prüfzeit, Metadaten und Einzelbefunde in JSON auf. Lade PNG nur bei erfolgreicher Aufnahme herunter. Das Bild hält Aussehen fest, JSON Kontext und Fehler, die beim Zuschneiden verloren gehen. Ein Dateiname allein belegt weder Seite noch Zeitpunkt oder Prüfbedingungen.

Beschreibe bei Layoutfehlern Element, Breite und sichtbare Folge: etwa ein bei 390 Pixeln abgeschnittener Produktname, der bei 820 lesbar bleibt. Nenne öffentlichen Pfad und mögliche Einflüsse ausgelassener Ressourcen oder fehlenden JavaScripts. Das ist handlungsfähiger als „mobil fehlgeschlagen“, gerade wenn die Aufnahme selbst erfolgreich war.

Schließe lokal mit Tastaturnavigation, Menüs, autorisierten Formularversuchen und Lade- oder Fehlerzuständen ab. Prüfe die tatsächlich unterstützten Browser und Geräte. Dieses Werkzeug bewertet weder Barrierefreiheit noch Core Web Vitals, Interaktionslatenz oder Gerätematrix. Abbrechen oder Zurücksetzen unterstützt Zielwechsel; Teilen friert weder Seite noch Ergebnis ein.

Methodik

Wir prüfen die Seitenmetadaten und die statische Darstellung getrennt, ohne Anmeldung oder vertrauliche Zugangsdaten. Jede akzeptierte Vorschau entspricht den gewählten Ansichtsmaßen. Fehlen eine Vorschau oder einzelne Dateien, weisen wir darauf hin; Metadaten allein belegen keine vollständige Seitendarstellung.

Grenzen

Gezeigt wird der erste sichtbare Bereich, keine vollständige JavaScript-Darstellung, ganze Seitenaufnahme, Leistungsbewertung oder Barrierefreiheitsprüfung. Externe Schriften, eingebettete Inhalte, Medien und dynamisch geladene Elemente können fehlen. Die Ansicht kann deshalb von deinem Browser abweichen. Verwende nur öffentliche Seiten und prüfe Interaktionen auf deinen eigenen Geräten. Nach dem Abbrechen ersetzt ein verspätetes Ergebnis nicht mehr die aktuelle Ansicht.

Korrekturen

Melde ein reproduzierbares Problem über die Kontaktseite mit Seiten-URL, unbedenklicher Eingabe, Prüfzeit, erwartetem Ergebnis und Quellenbeleg. Füge nach Möglichkeit die öffentliche Antwort bei, aber keine Kontodaten oder geheimen Links. Eine geänderte Quelle ist nicht automatisch ein Rechenfehler. Vergleiche zunächst denselben Namen, dieselbe Seite und denselben Prüfzeitpunkt.

MethodikKorrekturen

Häufige Fragen

Warum gibt es Metadaten, aber keine Vorschau?

HTTP, nicht unterstützte Inhalte, Quellfehler oder Aufnahmegrenzen können Metadaten ohne akzeptiertes Bild liefern. Lies den Hinweis pro Größe. Titel und HTTP-Antwort beweisen keine Darstellung; eine fehlende Aufnahme diagnostiziert keine leere Website.

Führt der Test JavaScript aus?

Nein. Abgerufenes HTML, unterstütztes CSS und Bilder werden ohne Seiten-JavaScript dargestellt. Clientseitige Widgets, Routen und Inhalte können fehlen. Vergleiche normale und lokal deaktivierte Ausführung. Eine gelungene statische Aufnahme ist kein bestandener Anwendungstest.

Sind die Größen echte Telefon- und Tabletemulationen?

Nein. Sie setzen feste Viewports von 1440 × 900, 820 × 1180 und 390 × 844. Touch, Pixeldichte, Betriebssystem und Browserfamilien sind damit nicht bestätigt. Nutze eigene responsive und physische Gerätetests für diese Bedingungen.

Warum sehen Schriften oder Icons anders aus?

Externe Schriften fehlen; Ersatzschriftmaße ändern Umbrüche und Abstände, Schrifticons können verschwinden. Frames, Medien und dynamisch nachgeladene Ressourcen fehlen ebenfalls möglicherweise. Lies Ressourcenhinweise, bevor du die Abweichung als CSS-Fehler behandelst.

Bedeutet HTTP 200, dass die ganze Seite bestanden hat?

Nein. Es betrifft die HTTP-Antwort, nicht sämtliche Ressourcen und Interaktionen. Eine Anwendungshülle kann 200 liefern und statisch wenig zeigen. Prüfe Größenbefunde und Ressourcenhinweise und anschließend echtes Browserverhalten.

Warum fehlen Titel oder Canonical, die mein Browser zeigt?

Sie können durch JavaScript entstehen, in der anonymen Quelle fehlen oder vom begrenzten Extraktor nicht erkannt werden. Abgeschnittenes HTML kann spätere Tags auslassen. Vergleiche den Quelltext, nicht nur das DOM, bevor du die Seite änderst oder Tags verdoppelst.

Enthält die PNG die ganze Seite?

Nein. Sie zeigt den ersten sichtbaren Bereich der ausgewählten Größe. Darunterliegende Inhalte, Scrollen, verzögertes Laden und fixierte Elemente nach dem Scrollen brauchen eigene Prüfungen. Der Download ist ein Ausschnitt, kein Beleg vollständiger Seitenkontrolle.

Kann ich private Dashboards oder signierte Vorschaulinks testen?

Nein. Verwende normale öffentliche Seiten ohne Zugangsdaten, Kennungen oder geheime Tokens. Deine Browseranmeldung wird nicht übernommen. Prüfe private Seiten lokal mit autorisierten Organisationswerkzeugen statt ihre Zugangslinks öffentlich einzutragen.

Belegen Metadaten Indexierung oder Barrierefreiheit?

Nein. Quellfelder bestätigen weder Indexierung noch Canonical-Auswahl oder Zugänglichkeit. Für Indexierung sind Crawlerwerkzeuge sowie Quell- und Headeranweisungen relevant; für Barrierefreiheit eine eigene Prüfung mit Tastatur und assistiven Technologien. Ein ordentliches Bild beantwortet diese Fragen nicht.