Is It WP? WordPress-Belege prüfen

Zuerst die Belege lesen, dann das Urteil

Jedes Signal ist gefunden, nicht gefunden oder nicht verfügbar. Nicht gefunden bedeutet, dass die untersuchte Antwort dieses erkennbare Merkmal nicht enthielt. Nicht verfügbar bedeutet, dass Anfrage oder Antwort unbrauchbar waren. Liefert eine Firewall eine Fehlerseite, sagt deren fehlender Theme-Pfad wenig über die eigentliche Besucherseite aus. Die kompakte Ansicht zeigt die ersten sechs Signalzeilen und wichtige Komponentenfelder. Exportiere JSON für die vollständige Signalliste und zurückgegebene Theme-Metadaten, auch wenn diese nicht in der Kurzansicht stehen.

Die Gewichte sind offen: REST-Kern 45, WordPress-Generator 35, API-Erkennung 25, Content- und Includes-Pfade jeweils 20, erkennbare Kernskripte 15, Cookiepräfixe 12, Publishing-Erkennung 10 und Pingback 8. Die Summe ist auf 100 begrenzt. Zehn Verweise auf ein Plugin ergeben nicht zehn unabhängige Plattformsignale; Dateiverweise und Signalgewicht beantworten unterschiedliche Fragen.

Auch die Lesbarkeit der Hauptseite bestimmt das Urteil. Fehlerhafte, abgeschnittene oder nicht als HTML gelieferte Seiten bleiben trotz einzelner Belege uneindeutig. Bei nutzbarem HTML führen REST-Kern plus weiteres Signal oder mindestens drei Signale mit zusammen 55 Punkten zu starken Belegen. Ab 30 kann andernfalls wahrscheinlich gelten; kleinere positive Werte bleiben uneindeutig. Das sind Implementierungsregeln, keine Wahrscheinlichkeiten oder Backendnachweise.

Warum verschiedene Seiten verschiedene APIs zeigen

Der Checker bevorzugt eine veröffentlichte Erkennungs-URL aus Link-Header oder HTML. Andernfalls leitet er einen üblichen wp-json/-Kandidaten aus Content-Pfaden oder dem Seitenursprung ab. Er durchsucht nicht alle Verzeichnisse. Eine unter /news/ betriebene Publikation kann sich deshalb anders verhalten als eine von einem anderen System gelieferte Startseite ohne brauchbare API-Verknüpfung.

Die REST-Erkennungsdokumentation definiert die Relation https://api.w.org/. Für den Checker zählt zusätzlich, ob ihr Ziel erkennbare Kernnamensräume oder Routen liefert. API-Verweis und nutzbarer API-Index sind getrennte Belege; ein Link bestätigt nicht, dass das Ziel während der Prüfung funktionierte.

Eigene Namensräume sind nützlich, aber kein automatisches Pluginverzeichnis. Routen können aus einem Theme oder individuellem Code stammen. Ältere Publishing-Hinweise wie RSD, Windows-Live-Writer-Markup und X-Pingback erhalten geringere Gewichte. ClockTools liest Verweise, sendet aber keine Publishing-Anfragen und testet keine Zugangsdaten. Eine deaktivierte Schnittstelle kann die Belege verändern, ohne das CMS zu verändern.

Mit Dateipfaden gezielter nach dem Bestand fragen

Ein Verweis unter /wp-content/themes/atelier/ zeigt einen öffentlichen Verzeichnis-Slug. Die meisten Dateiverweise bestimmen den stärksten Theme-Kandidaten; bei Gleichstand entscheidet die alphabetische Reihenfolge. Das ist keine ausgelesene Aktivierungswahl. ClockTools kann die übliche style.css und deren Headerfelder lesen. Fehlt ein Name, bleibt der Slug ein Slug statt eines erfundenen Produktnamens.

Zwei Theme-Verzeichnisse sind zunächst eine Frage, kein Konfliktbeweis. Beim Child-Theme-Modell verweist Template auf das Elternverzeichnis. Frage im Beispiel mit atelier-child und atelier, wo Anpassungen liegen und welche Dateien vom Eltern-Theme kommen. Auch Cache oder unabhängig geladene Dateien können einen zweiten Slug erklären. Bestätige den Aufbau vor Updates in der Verwaltung.

Verweise unter /wp-content/plugins/ und /wp-content/mu-plugins/ werden nach Slug und Anzahl gruppiert. Die Dokumentation zu Must-use-Plugins erläutert deren besonderes Laden, doch öffentliche Pfade zeigen nicht den gesamten Bestand. Eine Kontaktseite kann Formulardateien laden, die auf der Startseite fehlen. Prüfe sie bei einer Migration separat und gleiche die Ergebnisse mit aktivem und Must-use-Bestand ab.

Rein serverseitige Plugins, Bündeldateien, eigene Pfade und CDN-Umschreibungen können unsichtbar bleiben. Alte Cacheverweise können wiederum entfernte Komponenten zeigen. Eine Theme-Version betrifft dieses Theme; beliebige ?ver=-Dateiparameter sind keine verlässliche WordPress-Kernversion. Der Versionshinweis wird nur aus ausdrücklich identifizierenden Generatorangaben gelesen. Ein leeres Feld kann daher richtig sein.

Theme Name ist der veröffentlichte Anzeigename, Author und Theme URI sind angegebene Urheberinformationen. Text Domain benennt einen Übersetzungsbereich, keinen Website-Host. Diese Angaben helfen, vorgesehene Dokumentation zu finden, bleiben aber bearbeitbarer Text. Sie bestätigen weder Inhaberschaft noch Lizenzberechtigung oder ein verfügbares Update für die tatsächlich ausgelieferten Dateien.

Inhaltserstellung von Seitenauslieferung trennen

Eine klassische Website liefert WordPress-HTML direkt, ein Cache eine frühere Kopie. Ein statischer Export kann Markup und Dateipfade bewahren, ohne für jeden Besucher WordPress auszuführen. Ein Headless-Frontend kann Inhalte aus einem getrennten oder privaten WordPress-Dienst beziehen, ohne bekannte Pfade zu veröffentlichen. Der Checker beobachtet Auslieferung, nicht sämtliche Systeme der Inhaltserstellung.

Das erklärt überraschende Ergebnisse in beide Richtungen. Eine hohe Punktzahl kann die öffentlichen Exportmerkmale korrekt beschreiben, während die Behauptung eines laufenden Backends falsch wäre. Keine Signale auf einem Headless-Frontend können ebenfalls korrekt sein, obwohl die Redaktion WordPress nutzt. Frage nach Autorenoberfläche, Build und öffentlichem Auslieferungssystem; diese Antworten helfen einem Projekt mehr als ein Streit über die Erkennungsbezeichnung.

Im festen Exportbeispiel sind Generator und wp-content sichtbar, aber kein brauchbarer REST-Kern. Zusammen sind das 55 Punkte; zwei Merkmale erfüllen jedoch nicht die Regel für mindestens drei starke Belege. Bei nutzbarem HTML kann wahrscheinlich angezeigt werden, bei blockierter oder abgeschnittener Hauptseite bleibt es uneindeutig. Kopierte Publishing-Merkmale können weitere Punkte hinzufügen, ohne ein laufendes Backend zu beweisen.

Überraschende Ergebnisse ohne private Abfragen klären

Beginne mit Eingabe und endgültiger URL. Eine Weiterleitung kann zu anderem Host, Sprachseite oder Schutzseite führen. Prüfe Status und gelesene Datenmenge vor Komponentennamen. Bei abgeschnittenem HTML fehlen möglicherweise spätere Hinweise; eine daraus gewonnene Liste ist nicht vollständig. Vergleiche die tatsächliche öffentliche Antwort mit der erwarteten Seite.

Die Prüfung ist anonym und begrenzt: öffentliche Seite, ein REST-Kandidat und gegebenenfalls ein Theme-Stylesheet. JavaScript wird nicht ausgeführt. Die ursprüngliche Query wird entfernt; eine queryabhängige Seite kann deshalb von deiner Browseransicht abweichen. Verwende als Ersatz keine signierten Vorschau- oder Anmeldelinks. Prüfe normale öffentliche Pfade hier und angemeldete Seiten lokal.

Bewahre bei gesperrter API oder Anfragelimit den Nicht-verfügbar-Hinweis, versuche es später und prüfe gegebenenfalls eigene Zugriffsregeln. Deaktiviere Schutz nicht für eine höhere Punktzahl. Kontrolliere veröffentlichte Versionen und Updates im angemeldeten System; ein Schwachstellenabgleich findet hier nicht statt. Eine Korrekturmeldung braucht sichere URL, Zeit, erwartetes Merkmal und öffentliche Antwort, nicht nur eine beanstandete Zahl.