Aufbau der WordPress-Exportdatei (WXR)

Einführung und Grundverständnis der WXR‑Datei

Die WordPress‑Exportdatei, allgemein bekannt als WXR (WordPress eXtended RSS), ist ein XML‑basiertes Format, das WordPress‑Inhalte aus einer Website in einer strukturierten Textdarstellung speichert und ermöglicht, diese Inhalte zwischen Installationen zu übertragen oder zu archivieren. Diese Datei wird erzeugt, wenn man im WordPress‑Backend über die Exportfunktion Daten herunterlädt, und beinhaltet nicht nur Beiträge und Seiten, sondern auch Kommentare, Taxonomien, Custom Fields und Benutzerinformationen (WordPress.org¹ 2019).

Formal beginnt eine WXR‑Datei mit der XML‑Deklaration <?xml version="1.0" encoding="UTF‑8"?> und enthält ein einziges Wurzelelement <rss>, das durch Namespaces wie xmlns:content, xmlns:excerpt und xmlns:wp ergänzt wird, um verschiedene XML‑Module und WordPress‑Erweiterungen zu kennzeichnen (Liquid Web² 2025).

Struktur und semantischer Aufbau

Auf der strukturellen Ebene verwendet WXR die hierarchischen Konzepte von XML, also verschachtelte Elemente mit Tags und optionalen Attributen, um Datentypen und -werte klar abzubilden. Ein <item>‑Block steht typischerweise für einen einzelnen Inhaltseintrag und kann z. B. Informationen wie <title>, <link> und WordPress‑spezifische Felder wie <wp:post_id> und <wp:post_type> enthalten (Liquid Web 2025).

Das hierarchische Format hat zwei grundlegende Funktionen: Es organisiert Daten logisch, indem verwandte Informationen verschachtelt werden, und es erlaubt Parsing‑Werkzeugen, wie dem WordPress‑Importer, die Elemente beim Import zu interpretieren (Liquid Web 2025).

Beispiele

Erläuterte Struktur einer WXR-Datei

Hier eine verkürzte Version einer WordPress-Export-Datei:

<?xml version="1.0" encoding="UTF-8"?>
<!-- WordPress eXtended RSS (WXR) Exportdatei – enthält strukturierte Website-Inhalte -->

<rss version="2.0"
  xmlns:excerpt="http://wordpress.org/export/1.1/excerpt/"
  xmlns:content="http://purl.org/rss/1.0/modules/content/"
  xmlns:wfw="http://wellformedweb.org/CommentAPI/"
  xmlns:dc="http://purl.org/dc/elements/1.1/"
  xmlns:wp="http://wordpress.org/export/1.1/">
  
  <channel>
    <title>Omnivore</title> <!-- Titel der exportierten Website -->
    <link>https://omnivore.de.cool</link> <!-- Basis-URL der Website -->
    <pubDate>Tue, 16 Dec 2025 14:35:43 +0000</pubDate> <!-- Exportzeitpunkt -->
    <wp:wxr_version>1.1</wp:wxr_version> <!-- Version des WXR-Formats -->
    <wp:base_site_url>https://omnivore.de.cool</wp:base_site_url> <!-- Root-Domain -->
    <wp:base_blog_url>https://omnivore.de.cool</wp:base_blog_url> <!-- Blog-URL -->

    <item>
      <title>Beispielseite</title> <!-- Seitentitel -->
      <link>https://omnivore.de.cool/beispiel</link> <!-- Permalink -->
      <pubDate>Sat, 22 Nov 2025 10:42:00 +0000</pubDate> <!-- Veröffentlichungsdatum -->
      <dc:creator>omnivore</dc:creator> <!-- Benutzername des Autors -->
      <guid isPermaLink="false">https://omnivore.de.cool/?page_id=0</guid> <!-- Globally Unique Identifier -->
      <description></description> <!-- Kurzbeschreibung (oft leer) -->

      <content:encoded><![CDATA[
        <!-- HTML-Inhalt des Beitrags oder der Seite -->
        <p>Dies ist ein Beispielinhalt einer exportierten WordPress-Seite.</p>
      ]]></content:encoded>

      <excerpt:encoded><![CDATA[]></excerpt:encoded> <!-- Zusammenfassung / Teaser (oft leer) -->
      
      <wp:post_id>13346</wp:post_id> <!-- Interne ID der Seite -->
      <wp:post_date>2025-11-22 11:42:00</wp:post_date> <!-- Lokale Zeit -->
      <wp:post_date_gmt>2025-11-22 10:42:00</wp:post_date_gmt> <!-- UTC-Zeit -->
      <wp:comment_status>closed</wp:comment_status> <!-- Kommentaroptionen -->
      <wp:ping_status>closed</wp:ping_status> <!-- Pingback-/Trackback-Optionen -->
      <wp:post_name>beispielseite</wp:post_name> <!-- URL-Slug -->
      <wp:status>publish</wp:status> <!-- Veröffentlichungsstatus -->
      <wp:post_parent>0</wp:post_parent> <!-- ID der übergeordneten Seite (0 = keine) -->
      <wp:menu_order>0</wp:menu_order> <!-- Position im Menü -->
      <wp:post_type>page</wp:post_type> <!-- Typ: z. B. "post", "page", "attachment" -->
      <wp:post_password></wp:post_password> <!-- Passwortschutz -->
      <wp:is_sticky>0</wp:is_sticky> <!-- Sticky Post (nur für Beiträge relevant) -->

      <!-- Taxonomie-Zuordnungen (Tags, Kategorien etc.) -->
      <category domain="post_tag" nicename="ethik"><![CDATA[Ethik]]></category>
      <category domain="category" nicename="thementext"><![CDATA[Thementext]]></category>
    </item>
  </channel>
</rss>

Erläuterte Struktur eines <content:decoded>-Blocks

Dieser Block enthäht den HTML/WordPress-Inhalt der Seite. Es folgt eine Verkürzte kommentiertes Beispiel:

<content:encoded><![CDATA[
<!--
content:encoded enthält den vollständigen HTML-Inhalt eines WordPress-Beitrags
inklusive Gutenberg-Block-Markern. Der Inhalt wird beim Import direkt in den
post_content übernommen (WordPress.org).
-->

<!-- wp:luckywp/tableofcontents /-->
<!--
Gutenberg-Block eines Plugins (LuckyWP TOC).
Block-Kommentare steuern blockbasierte Darstellung,
werden von WordPress beim Rendern interpretiert.
-->

<!-- wp:heading -->
<h2 class="wp-block-heading">
Einleitung: Bernard Gerts Ansatz einer rationalen Moralphilosophie
</h2>
<!--
HTML-Element <h2>: strukturelle Überschrift.
Gutenberg ergänzt Klassen zur Block-Identifikation.
-->
<!-- /wp:heading -->

<!-- wp:paragraph -->
<p>
Bernard Gert entwickelt eine Moralphilosophie, die auf einer
<strong>common morality</strong> beruht.
<a href="#fn2" id="fnref2"><sup>2</sup></a>
</p>
<!--
<p> = Absatz.
<strong> = semantische Hervorhebung (wichtig, nicht nur visuell).
<a> + <sup> = interne Verlinkung / Fußnotenstruktur.
-->
<!-- /wp:paragraph -->

<!-- wp:heading -->
<h3 class="wp-block-heading">
1. Töte nicht (Do not kill)
</h3>
<!--
<h3>: untergeordnete Überschrift innerhalb der Seitenhierarchie.
-->
<!-- /wp:heading -->

<!-- wp:paragraph -->
<p>
<strong>Definition:</strong>
Verursache keine absichtliche Tötung ohne Rechtfertigung.
<br>
<strong>Grenzfälle:</strong> Notwehr, Krieg.
</p>
<!--
<br> = expliziter Zeilenumbruch innerhalb eines Absatzes.
Wird häufig in redaktionellen Texten genutzt.
-->
<!-- /wp:paragraph -->

<!-- wp:details -->
<details class="wp-block-details">
<summary>Prüfprotokoll</summary>
<p>
Details-Block zur ausklappbaren Darstellung.
</p>
</details>
<!--
<details>/<summary> = semantisches HTML5-Element
für ein- und ausklappbare Inhalte (Disclosure Widget).
-->
<!-- /wp:details -->

<!-- wp:html -->
<figure class="wp-block-table">
<table border="1">
<thead>
<tr>
<th>Quelle</th>
<th>Bewertung</th>
</tr>
</thead>
<tbody>
<tr>
<td>Gert 2004</td>
<td>Bestätigt</td>
</tr>
</tbody>
</table>
</figure>
<!--
HTML-Block (wp:html) erlaubt rohes HTML.
<figure> kapselt semantisch Tabellen oder Medien.
<table> mit thead/tbody = strukturierte tabellarische Daten.
-->
<!-- /wp:html -->

<!-- wp:group -->
<div class="wp-block-group">
<p>#Moralphilosophie #Ethik</p>
</div>
<!--
<div> als Gruppierungselement.
wp:block-group dient der Layout- und Stilzusammenfassung.
-->
<!-- /wp:group -->

]]></content:encoded>

Der Inhalt des <content:encoded>-Block wird in einen CDATA-Block gepackt, so dass die enthaltenen HTML-Sonderzeichen nicht escaped werden müssen. Dies verbessert die Lesbarkeit des HTML-Codes deutlich.

Technische Perspektiven und Einsatzbereiche

Aus Entwickler‑ und Infrastrukturperspektive dient das WXR‑Format als Standardformat für Migrationen und Backups, wobei WordPress selbst über das Backend‑Interface unter „Tools → Export“ eine XML‑Datei erzeugt, die die ausgewählten Inhalte enthält (WordPress.org 2019).

Ein Vorteil der XML‑Basis ist die weite Kompatibilität: XML kann von zahlreichen Werkzeugen und Parsern gelesen werden, was die Übertragbarkeit zwischen Systemen erleichtert. Dadurch können nicht nur WordPress‑Installationen, sondern auch verschiedene Import‑Werkzeuge die exportierten Dateien verarbeiten (Liquid Web 2025).

Inhaltliche Grenzen und Herausforderungen

Trotz seiner umfangreichen Datenabdeckung hat ein WordPress‑Export im WXR‑Format beschränkte Aussagekraft bezüglich der gesamten Website‑Struktur. Elemente wie Plugins, Themes und serverseitige Konfigurationen werden nicht exportiert, da sie nicht Teil des Inhalts‑Exports sind (WordPress.org 2019). Auch Mediendateien werden in der Regel nicht als Binärdaten eingebettet, sondern nur als Verweise auf die Ursprungsadresse im Dateisystem angegeben (WordPress.org 2019).

Pluralistische Sichtweisen und Praxisimplikationen

Die offizielle WordPress‑Dokumentation beschreibt WXR vor allem als ein Werkzeug zur Nutzer‑Migration und Datensicherung, während technische Beiträge zusätzlich die strukturellen Details der XML‑Elemente hervorheben und deren Bedeutung in Import‑ und Analyseprozessen erklären (WordPress.org 2019; Liquid Web 2025).

Kritische Würdigung und Ausblick

Die kritische Bewertung des WXR‑Formats ergibt ein differenziertes Bild: Einerseits bietet das Format eine standardisierte, XML‑basierte Methode zur Übertragung von vielfältigen Inhaltsdaten, einschließlich Beiträgen, Kommentaren, Taxonomien und Metadaten. Andererseits zeigt sich, dass der Einsatz von XML mit zunehmender Komplexität der Inhalte und externen Abhängigkeiten an Grenzen stößt, insbesondere wenn es um nicht‑Content‑bezogene Daten geht, die nicht exportiert werden.

Zukunftsorientierte Diskussionen in Entwickler‑Communities schlagen vor, WXR weiter auszubauen oder alternative Formate zu erwägen, um zusätzliche Metadaten mit einschließen zu können. Diese Perspektiven deuten an, dass das klassische WXR‑Format zwar robust bleibt, jedoch in modernen Entwicklungs‑ und Migrationsszenarien weiterentwickelt werden könnte.