So erstellen Sie mit KI ein WordPress-URL-Inventar

Ein URL-Inventar ist die faktische Grundlage der meisten WordPress-SEO- und Migrationsarbeiten. KI kann Exporte normalisieren und Muster klassifizieren, aber sie kann keine vollständige Website aus der ersten Seite einer API-Antwort oder einer Sitemap allein ableiten. Erstellen Sie das Inventar aus mehreren benannten Quellen und bewahren Sie Abweichungen.

SEO-Analysen sind nur so zuverlässig wie die bereitgestellten Nachweise. Ein Sprachmodell kennt Crawl-Status, Indexierung, Rankings, kanonische Auswahl oder Seitenleistung nicht eigenständig. Behandeln Sie es als Nachweisorganisator und Hypothesengenerator und prüfen Sie anschließend jede Feststellung im passenden Quellsystem.

In einem Satz: Erstellen Sie eine stabile Zeile je entdeckter URL, bewahren Sie jede Quelle, die sie gemeldet hat, und markieren Sie Konflikte, statt stillschweigend einen Wert zu wählen.

Was Sie mit diesem Leitfaden erreichen

Das Ergebnis sollte eine nachvollziehbare Ansicht öffentlicher, privater, weitergeleiteter und fehlender URLs liefern, einschließlich WordPress-IDs, sofern verfügbar. Es soll spätere Audits unterstützen, ohne vorzutäuschen, dass eine Datenquelle die gesamte Website repräsentiert.

Ein nützliches Ergebnis ist nicht bloß eine gut formulierte Antwort. Es muss zeigen, welche Datensätze oder Seiten untersucht wurden, welche Nachweise fehlten, was der Assistent abgeleitet hat, was ein Mensch entscheiden muss und welche Aktionen weiterhin verboten sind.

Was ein erfolgreiches Ergebnis enthalten soll

  • Einen normalisierten URL-Datensatz mit allen beobachteten Quellvarianten.
  • WordPress-Inhalts-ID, Typ, Status, Sprache und Daten, sofern verfügbar.
  • HTTP-, Canonical-, Sitemap- und Indexierungsrichtlinien-Nachweise, sofern bereitgestellt.
  • Quellpräsenz-Markierungen, die zeigen, wo jede URL entdeckt wurde.
  • Konflikt- und Felder für fehlende Daten.
  • Einen klar definierten Inventarumfang und ein Extraktionsdatum.

Vorzubereitende Nachweise und Eingaben

WordPress, Sitemaps, Crawler und Analysesysteme beantworten unterschiedliche Fragen. Führen Sie sie zusammen, ohne die Unterschiede zu löschen.

  • Vollständige paginierte Exporte von WordPress-Beiträgen, Seiten und benutzerdefinierten Inhaltstypen.
  • Alle XML-Sitemaps und Sitemap-Indizes.
  • Ein Crawl-Export mit finaler URL, Status und Canonical-Feldern.
  • Eine Weiterleitungszuordnung oder Serverdaten, sofern verfügbar.
  • Seitenexporte aus Search Console und Analysesystemen, sofern relevant.
  • Zuordnungen für Gebietsschema, Website-Bereich und Inhaltsverantwortliche.
  • Für das Projekt genehmigte URL-Normalisierungsregeln.

Dokumentieren Sie Datum, Quelle, Umfang und bekannte Auslassungen für jede Eingabe. Entfernen Sie Zugangsdaten, personenbezogene Informationen und Kundendaten, die für die Aufgabe nicht erforderlich sind.

Behalten Sie Entdeckungsquellen als getrennte Nachweise

Eine URL in WordPress, die nicht in der Sitemap steht, ist nicht automatisch ein Fehler. Eine URL in Analysedaten, die nicht in WordPress steht, kann weitergeleitet, extern, historisch oder generiert sein. Bewahren Sie Kennzeichen wie in_wordpress, in_sitemap, in_crawl und in_search_data, bevor Sie sie interpretieren.

Normalisieren Sie, ohne Unterschiede zu verbergen

Die Normalisierung von Groß- und Kleinschreibung, abschließendem Schrägstrich, Protokoll, Host und Abfrage kann Doppelzählungen verhindern. Bewahren Sie sowohl den Rohwert als auch den normalisierten Schlüssel, damit Prüfer nachvollziehen können, was geändert wurde. Entfernen Sie Parameter nicht, bevor ihre Funktion bekannt ist.

Ein sicherer Arbeitsablauf

  1. Legen Sie eingeschlossene Hosts, Protokolle, Gebietsschemata und Inhaltstypen fest.
  2. Exportieren Sie jede Quelle mit Daten und Paginierungsnachweisen.
  3. Speichern Sie Roh-URLs, bevor Sie Normalisierungsregeln anwenden.
  4. Erstellen Sie einen normalisierten URL-Schlüssel und Quellpräsenz-Markierungen.
  5. Verknüpfen Sie WordPress-IDs, Status, HTTP-Ergebnisse, Canonicals und Sitemap-Nachweise.
  6. Bitten Sie den Assistenten, Konflikte und fehlende Felder zu klassifizieren.
  7. Prüfen Sie Abweichungen mit hoher Auswirkung manuell.
  8. Frieren Sie die Inventaraufnahme für nachgelagerte Arbeiten ein.
  9. Erstellen Sie getrennte Aufgaben für Weiterleitungen, Canonicals oder Inhaltsänderungen.

Der Arbeitsablauf trennt Analyse bewusst von Umsetzung. Eine spätere Änderungsphase sollte sich auf das genehmigte Ergebnis beziehen, statt die Berechtigungen der analytischen Identität stillschweigend auszuweiten.

Prompt-Vorlage

Ersetzen Sie vor der Nutzung dieses Prompts jeden Wert in eckigen Klammern. Fügen Sie keine Passwörter, API-Schlüssel, privaten Kundendatensätze oder irrelevanten personenbezogenen Informationen in die Anweisung ein.

Erstellen Sie aus den bereitgestellten Quelldateien ein normalisiertes WordPress-URL-Inventar.

Geben Sie eine Zeile je normalisierter URL zurück mit:
- Normalisierte URL und alle Rohvarianten
- Host, Pfad, Abfrage und Gebietsschema
- WordPress-ID, Inhaltstyp und Status
- Veröffentlichungs- und Änderungsdaten
- Vorhanden in WordPress, Sitemap, Crawl, Search Console, Analysedaten und Weiterleitungszuordnung
- HTTP-Status und finale URL, sofern bereitgestellt
- Deklarierte Canonical, sofern bereitgestellt
- Konfliktklasse und fehlende Nachweise
- Prüfpriorität und Begründung

Regeln:
1. Nehmen Sie nicht an, dass eine Quelle vollständig ist.
2. Bewahren Sie Rohwerte und Quelldaten.
3. Entfernen Sie Parameter nicht ohne genehmigte Regel.
4. Erfinden Sie keine HTTP-, Canonical- oder Indexierungsdaten.
5. Ändern Sie WordPress, Weiterleitungen oder Sitemaps nicht.

Warum dieser Prompt so strukturiert ist

Das Quellpräsenzmodell erzeugt eine auditierbare Verknüpfung statt einer flachen Tabelle, die Widersprüche verbirgt. Rohvarianten und normalisierte Schlüssel ermöglichen es, die Deduplizierung infrage zu stellen.

Empfohlene Zugriffsgrenze

Verwenden Sie eine Read Only-Identität. Der Assistent darf die im Umfang enthaltenen WordPress-Datensätze untersuchen, aber Versuche, Inhalte zu erstellen, zu bearbeiten, zu löschen oder zu veröffentlichen, müssen abgelehnt werden.

Der empfohlene Arbeitsablauf hat ein geringes Risiko, wenn die Quelldaten abgegrenzt sind und keine Schreibberechtigung erteilt wird. Geringes Risiko bedeutet nicht keine Prüfung.

Was außerhalb dieser Aufgabe bleiben muss

  • Keine Weiterleitungen, Canonicals, noindex-Änderungen oder Löschungen.
  • Keine Behauptung, dass das Fehlen in einer Sitemap Deindexierung bedeutet.
  • Keine Annahme, dass die API-Paginierung ohne Nachweis vollständig ist.
  • Keine Entfernung von Abfrageparametern, bevor ihre Rolle bekannt ist.
  • Kein abgeleiteter HTTP-Status oder finale URL.

Die Zugriffsstufe ist eine Ausgangsempfehlung, keine universelle Berechtigung. Die genauen einer Identität verfügbaren Fähigkeiten müssen aus der installierten Produktversion und ihrer veröffentlichten Abdeckung stammen.

Wie WP Agent Control passt

Dies ist ein allgemeiner WordPress-Arbeitsablauf. Er verspricht nicht, dass Agent Control alle beschriebenen Objekte oder Integrationen bearbeiten kann. Beginnen Sie im geführten Ablauf mit öffentlichen Seiten. Aktionen für Plugins, Themes, Benutzer, Einstellungen, Dateien, Löschungen, WooCommerce, ACF und Page Builder sind keine nativen geführten Aufgaben. Prüfen Sie dafür gesondert geeignete Werkzeuge und Berechtigungen.

Rufen Sie nach der Verbindung strukturierte Websiteinformationen ab und untersuchen Sie ausgewählte veröffentlichte Seiten. Dafür ist keine temporäre Aufgabe nötig. Öffentliche Seiten lassen sich auch ohne das Plugin besuchen; Agent Control ergänzt strukturierten Zugriff und den Übergang zu autorisierten WordPress-Arbeiten.

Ihre KI verbinden: docs first profile · Funktionen und Kompatibilität ansehen: coverage

Prüfliste

  • Jede Quelle hat ein Datum und einen Umfang.
  • Der Abschluss der Paginierung ist dokumentiert.
  • Rohe und normalisierte URL-Werte werden beide bewahrt.
  • Quellkonflikte bleiben sichtbar.
  • WordPress-IDs werden bewahrt, sofern verfügbar.
  • Während der Inventarerstellung hat sich kein URL-Status geändert.

Häufige Fehlermodi

  • Sitemap gleich Website: Das Inventar schließt gültige URLs aus, die nicht in der Sitemap stehen.
  • API-Export der ersten Seite: Die Paginierung wird übersehen und das Ergebnis fälschlich als vollständig bezeichnet.
  • Destruktive Normalisierung: Parameter oder Pfadunterschiede werden vor der Prüfung verworfen.
  • Konfliktlöschung: Eine Quelle überschreibt eine andere stillschweigend.

Erweiterter Hinweis

Verwenden Sie unveränderliche Inventaraufnahmen mit stabilen URL-IDs. Spätere Crawls und Migrationszuordnungen können auf dieselbe Identität verweisen, sodass das Team Zustandsübergänge beobachten kann, ohne historische Nachweise umzuschreiben.

Verwandte Leitfäden

Nächster Schritt

Verwenden Sie das eingefrorene Inventar für die Analyse verwaister Seiten, die Überschneidungsprüfung und das umfassendere SEO-Audit.

Quellen und Überprüfung

Diese Seite wurde anhand der folgenden Primärquellen überprüft. Letzte Quellenprüfung: .