Wie Google PDF-Dateien indexiert und warum man sie in WordPress durch HTML ersetzen sollte

#Wie Google PDF-Dateien bei der Indexierung in HTML umwandelt

In Folge 115 des offiziellen Podcasts Search Off the Record, veröffentlicht am 13. Oktober 2026, erklärten Martin Splitt und John Mueller vom Search Relations Team bei Google, wie Google Search mit PDF-Dokumenten umgeht. In vielen Unternehmen und Onlineshops hält sich die Annahme, ein Katalog oder technischer Leitfaden als PDF sei dasselbe wie eine normale Webseite. Die Folge zeigt, wo sich beide Formate ähneln und wo nicht.

HTML ist ein Textformat. Eine Suchmaschine liest HTML sequenziell und erkennt Überschriften, Absätze, Listen, strukturierte Daten in JSON-LD und semantische Anweisungen.

Das Portable Document Format (PDF) wurde für einen anderen Zweck entworfen: Es soll das exakte Layout eines Dokuments beim Drucken und auf jedem Bildschirm bewahren. Splitt betont, dass PDF ein binärer Container ist: Öffnet man ein PDF in einem Texteditor, erscheinen unlesbare Zeichen, während sich eine HTML oder Markdown Datei direkt lesen lässt.

Google öffnet PDFs nicht mit einem Viewer. Laut Splitt gehört zur Indexierung eine Komponente namens Konverter, die direkt nach dem Rendering und unmittelbar bevor ein Dokument in den Index gelangen kann arbeitet. Google hat Konverter für mehrere Formate (Rich Text Dateien, Dokumentdateien, Excel Tabellen und sogar Lotus Notes Dokumente), und einer davon ist der PDF-Konverter. Er erzeugt eine HTML-Version des Dokuments, so originalgetreu wie möglich, weil der Rest der Web Pipeline fast ausschließlich mit HTML arbeitet.

+-----------------------------------------------------------------------------------+
| Der Weg einer PDF Datei durch Google Search (laut Folge 115):                     |
| 1. Crawling der Datei (HTTP Content-Type: application/pdf)                        |
| 2. Rendering                                                                      |
| 3. PDF Konverter: erzeugt eine HTML Darstellung des Dokuments                     |
| 4. Links aus dieser Darstellung werden wie auf jeder HTML Seite erkannt           |
| 5. Indexierung und Ranking mit denselben Systemen wie eine HTML Seite             |
+-----------------------------------------------------------------------------------+

Deshalb laufen Indexierung und Ranking eines PDF nach Splitts Worten praktisch genauso ab wie bei jedem anderen Dokument, und ein PDF kann in AI Overviews und im AI Mode erscheinen. Google erfasst nicht, ob ein Dokument ursprünglich ein PDF war. Die offizielle Liste der indexierbaren Dateitypen führt Adobe PDF unter den unterstützten codierten Formaten.

Mueller ergänzte einen Vorbehalt zu sehr langen Dokumenten: Ein ganzes Buch in einem einzigen PDF hat dasselbe Problem wie ein ganzes Buch auf einer HTML-Seite. Die Suchmaschine kann schwer erkennen, welcher Satz der Grund ist, warum das Dokument für eine Suchanfrage erscheinen sollte.

#Welche PDF-Dateien Googlebot lesen kann und wann OCR versagt

Der Beitrag im Google Search Central Blog zu PDFs, verfasst von Gary Illyes, nennt die Grundregel: Google kann den Textinhalt eines PDF in jeder Sprache und in verschiedenen Zeichenkodierungen indexieren, solange die Datei nicht passwortgeschützt oder verschlüsselt ist. Ist der Text als Bild eingebettet, kann Google diese Bilder mit OCR Algorithmen verarbeiten.

In Folge 115 nennt Splitt gerasterte Seiten das schlimmste Problem: Dokumente, in denen jede Seite praktisch ein Bild ist. Dabei geht der gesamte Textinhalt verloren. Mueller ergänzt gescannte Bücher, die als PDF archiviert sind: Manche Systeme können OCR darauf anwenden, aber verlassen kann man sich darauf nicht.

Der Test, den beide vorschlagen, ist einfach:

1. Öffnen Sie das PDF.
2. Markieren Sie den gesamten Text mit Strg + A oder Cmd + A.
3. Fügen Sie ihn in ein Google Docs Dokument oder eine Textdatei ein.
4. Erscheint der Text, kann Google ihn nutzen. Erscheint er nicht, sieht auch Google den Inhalt nicht.

Splitt fügt hinzu, dass gerasterte Seiten auch ein Barrierefreiheitsproblem sind: Screenreader und andere Hilfstechnologien können sie nicht lesen, es sei denn, der PDF-Generator hat die Inhalte bewusst barrierefrei hinterlegt.

#Wie groß eine PDF-Datei sein darf, die Googlebot herunterlädt

Die Googlebot Dokumentation nennt zwei verschiedene Grenzen. Bei unterstützten Dateitypen crawlt Googlebot die ersten 2 MB. Bei einem PDF ruft er die ersten 64 MB ab. Die Grenze gilt für den dekomprimierten Inhalt, nicht für die Übertragungsgröße. Ist sie erreicht, bricht Googlebot den Abruf ab und gibt nur den bereits geladenen Teil zur Indexierung weiter.

In der Folge räumte Splitt ein, dass er die genaue Zahl für PDFs nicht im Kopf hatte, und erklärte, warum Google sie nicht festschreiben möchte: Die Grenze lässt sich ändern, und würden Herausgeber deutlich größere PDFs veröffentlichen, könnte Google sie anheben, um keine nützlichen Informationen zu verlieren. Maßgeblich ist die Dokumentation; die Zahl kann sich ändern.

In der Praxis betrifft die Grenze nur wenige Dokumente. Ein Katalog voller hochaufgelöster Fotos kann sich ihr nähern, und dann kann der Text der letzten Seiten außerhalb des Index bleiben.

#Warum Links in PDFs PageRank weitergeben, Bilder aber nicht ranken

#Wie sich Textlinks verhalten

Weil der Konverter eine HTML-Version erzeugt, bleiben die Links im PDF erhalten. Der Google Search Central Blog bestätigt das: Links in PDF-Dateien werden ähnlich behandelt wie Links in HTML, sie können PageRank und andere Indexierungssignale weitergeben, und Google kann ihnen nach dem Crawlen des PDF folgen.

• Weitergabe von Autorität: Links in einem PDF können PageRank an die Zielseiten weitergeben.
• Entdeckung neuer Pfade: Googlebot kann den erkannten Zielen nach dem Crawlen der Datei folgen.
• Kein nofollow: Laut demselben Beitrag lassen sich in einem PDF-Dokument keine nofollow Links verwenden.

Diese Links haben einen Nachteil für alle, die Ergebnisse messen. Auf einer Webseite erfassen Google Tag Manager oder das Analyseskript der Seite die Klicks. Dieses Skript läuft nicht in einem PDF, das im Viewer des Browsers geöffnet ist. Was der Leser im Dokument tut, bleibt außerhalb Ihrer Analyse.

#Das Problem mit eingebetteten Bildern im PDF

Auf einer Webseite mit WordPress oder Astro wird jedes Foto als eigene Ressource mit eigener URL, alt Attribut, festen Abmessungen und modernen Formaten wie AVIF oder WebP ausgeliefert. So kann die Google Bildersuche jedes Bild einzeln einordnen.

In einem PDF sind die Bilder Teil der Datei selbst. Splitt erklärte, dass Google Bild URLs normalerweise an die Pipeline der Bildersuche übergibt, und ein Bild in einem PDF hat keine URL. Seiner Einschätzung nach weiß Google, dass dort ein Bild ist, kann es aber nicht wie ein normales Bild für die Bildersuche verarbeiten, wobei sich das ändern könnte. Der Beitrag von 2011 war deutlicher: Bilder in PDF-Dateien werden nicht indexiert, und wer sie indexiert haben möchte, sollte HTML-Seiten für sie erstellen.

Wenn Ihr Unternehmen Infografiken, Architekturdiagramme oder visuelle Vergleiche nur im PDF veröffentlicht, sollten Sie keinen Traffic aus der Google Bildersuche erwarten.

#Warum Google Änderungen an einem aktualisierten PDF spät bemerkt

Mueller erklärte in Folge 115, dass die Crawl Frequenz bei PDFs der bei Bildern ähnelt. Googles Systeme rufen ein PDF nicht alle paar Minuten neu ab, weil sie davon ausgehen, dass sich die Datei wahrscheinlich lange nicht ändert, und weil sie nicht viele große Dateien von einem Server laden wollen, was Probleme verursachen könnte.

Splitt nannte einen weiteren Unterschied: Ein HTML-Dokument lässt sich im CMS leicht bearbeiten, ein erzeugtes PDF dagegen nicht ohne ein Werkzeug wie Adobe Acrobat Pro; üblicherweise behält man die Quelldatei und erzeugt das PDF neu.

Wenn Sie eine Preisliste, ein technisches Handbuch oder eine Richtlinie ändern und die neue Version unter demselben Namen und derselben URL hochladen, können das Snippet bei Google und die Antworten in AI Overviews noch längere Zeit auf der alten Version beruhen. Google nennt keinen Zeitraum, deshalb gibt es keine verlässliche Zahl dafür.

#Wie ein aktualisiertes PDF-Dokument schneller indexiert wird

Mueller empfiehlt einen neuen Dateinamen. Findet Google einen Link auf diese neue URL, erkennt es sie als neues Dokument und crawlt und indexiert sie. Zusätzlich setzen wir, als eigene Praxis und nicht als Google Vorgabe, eine 301 Weiterleitung vom alten Pfad:

Versionierungsstrategie gegen veraltete Inhalte im Index:
Alte Version:  https://ihredomain.de/kataloge/technische-spezifikation-2025.pdf
Neue Version:  https://ihredomain.de/kataloge/technische-spezifikation-2026-v2.pdf

Serverkonfiguration:
Dauerhafte HTTP 301 Antwort vom alten Pfad auf die neue Version.
Interne Links auf die neue URL aktualisiert.

Splitt ergänzte den Rat um HTTP Caching: Wenn Sie wissen, dass sich ein Katalog jedes Quartal ändert, können Sie ihn ein paar Monate im Cache halten; ändert sich eine Datei häufig, verliert langes Caching seinen Sinn.

#Wie man Titel und Metadaten eines PDF in Google steuert

Ein PDF hat kein HTML title Element. Laut Google Search Central Blog nutzt Google zwei Hauptelemente, um den Titel in den Suchergebnissen zu bestimmen: den in den Metadaten der Datei gespeicherten Titel und den Ankertext der Links, die auf das PDF verweisen. Für ein klares Signal empfiehlt Google, beides zu pflegen.

Splitt ergänzte in Folge 115, dass man die PDF-Metadaten ausfüllen sollte: Autor, eine Beschreibung des Inhalts und nach Möglichkeit einen Link zur Herkunft des Dokuments. Mueller schlug einen praktischeren Schritt vor: im Kopfbereich des PDF selbst einen normalen Link zur Startseite der Website setzen. Wenn Google das PDF in HTML umwandelt, bleibt dieser Link erhalten, und wer über die Suche auf dem PDF landet, findet einen Weg zurück zu Ihrer Website.

In einem WordPress-Arbeitsablauf heißt das:

1. Prüfen Sie vor dem Hochladen im erzeugenden Programm die Felder für Dokumenttitel, Autor und Beschreibung.
2. Verlinken Sie das PDF von einer HTML-Seite mit beschreibendem Ankertext, nicht mit “Download” oder “hier”.
3. Setzen Sie auf die erste Seite des PDF einen sichtbaren Link zur HTML-Seite, zu der es gehört.

#Wie man den HTTP Link Header rel canonical für PDF-Dokumente einrichtet

Bietet eine Organisation einen Bericht sowohl als Webartikel als auch als PDF zum Download an, entsteht ein Duplikatrisiko. Mueller beschrieb in der Folge ein zusätzliches Problem: Ein PDF ist ein binärer Blob. Lädt eine andere Website Ihr PDF herunter und veröffentlicht es, sieht die Suchmaschine zwei byteweise identische Dateien, und die Kanonisierung wird schwieriger als bei ähnlichen HTML-Seiten.

Auf einer HTML-Seite wird die bevorzugte Version mit dem Element link rel="canonical" im head angegeben. Ein PDF hat diesen Bereich nicht. Die Google Dokumentation zu doppelten URLs erklärt: Wenn Sie die Serverkonfiguration ändern können, können Sie einen HTTP Antwortheader Link mit rel="canonical" nach RFC 5988 verwenden, auch für Nicht HTML-Dokumente wie PDF-Dateien. Google weist darauf hin, dass diese Methode nur für die Websuche gilt.

Dieselbe Seite enthält zwei Warnungen, die PDFs betreffen. Google empfiehlt nicht, noindex zu verwenden, um die Auswahl einer kanonischen Seite innerhalb einer Website zu verhindern, weil das die Seite vollständig aus der Suche ausschließt. Und man sollte für dieselbe Seite keine unterschiedlichen kanonischen URLs mit verschiedenen Techniken angeben. Für ein PDF wählen Sie deshalb eine von zwei Optionen:

• Canonical: Das PDF bleibt erreichbar, und die Signale werden auf der HTML-Seite gebündelt.
• Noindex: Das PDF verschwindet aus den Ergebnissen (siehe nächster Abschnitt).

#Konfiguration auf Nginx Servern

location ~* \.pdf$ {
    # Kanonischer Link zur HTML Hauptversion
    add_header Link '<https://ihredomain.de/technische-dokumentation/>; rel="canonical"';
}

#Konfiguration auf Apache Servern (.htaccess)

Mit aktiviertem Modul mod_headers:

<FilesMatch "\.pdf$">
    Header set Link '<https://ihredomain.de/technische-dokumentation/>; rel="canonical"'
</FilesMatch>

#Konfiguration in Cloudflare Pages und CDNs

In Cloudflare Pages und ähnlichen statischen Hosting Plattformen gehört die Regel in die Datei _headers:

/dokumente/*.pdf
  Link: <https://ihredomain.de/technische-dokumentation/>; rel="canonical"

Eine Regel pro Dateimuster verweist alle PDFs auf dieselbe Seite. Hat jedes PDF eine eigene HTML-Seite, brauchen Sie eine Regel pro Datei oder pro Ordner.

#Wie man ein PDF aus den Google Suchergebnissen entfernt

Laut Google Search Central Blog ist der einfachste Weg, ein PDF aus den Suchergebnissen herauszuhalten, der HTTP Header X-Robots-Tag: noindex beim Ausliefern der Datei. Ist das PDF bereits indexiert, fällt es mit der Zeit heraus; für eine schnellere Entfernung verweist derselbe Beitrag auf das Tool zum Entfernen von URLs in der Search Console.

Die Dokumentation zum Robots Meta Tag zeigt diesen Fall für alle PDFs einer Website, mit noindex, nofollow:

<Files ~ "\.pdf$">
  Header set X-Robots-Tag "noindex, nofollow"
</Files>

location ~* \.pdf$ {
  add_header X-Robots-Tag "noindex, nofollow";
}

Soll Google die Links im PDF weiter zur Entdeckung von Seiten nutzen, reicht noindex allein: Laut derselben Dokumentation kann Google ohne die Regel nofollow die Links auf der Seite verwenden, um die verlinkten Seiten zu finden.

Es gibt zwei weitere Wege mit anderer Wirkung:

• Passwort: Splitt erinnert daran, dass Suchmaschinen ein passwortgeschütztes PDF nicht lesen können. Das passt für Dokumente, die nicht öffentlich sein sollen.
• robots.txt: Sie verhindert, dass Google das PDF abruft. Die Dokumentation zu doppelten URLs warnt jedoch, dass Google per robots.txt gesperrte URLs auch ohne deren Inhalt indexieren kann. Soll die Datei aus den Ergebnissen verschwinden, ist der noindex Header das richtige Werkzeug, und Google sieht ihn nur, wenn es die Datei abrufen kann.

#Wie WordPress hochgeladene PDFs in der Mediathek verwaltet

Wenn Sie ein PDF in die Mediathek hochladen, speichert WordPress die Datei in wp-content/uploads und legt einen Anhang in der Datenbank an. Die Datei selbst liefert der Webserver (Nginx, Apache) oder das CDN direkt aus, ohne WordPress zu laden. Dieses Detail entscheidet, wo Header konfiguriert werden.

Der Hook send_headers wird in WP::send_headers() ausgelöst, wenn WordPress eine Anfrage verarbeitet. Eine direkte Anfrage an /wp-content/uploads/2026/10/katalog.pdf erreicht WordPress nie. Code in der functions.php, der diesem PDF einen Canonical Header hinzufügen soll, wird daher nicht ausgeführt. Per PHP lässt sich der Header nur setzen, wenn ein Plugin die Datei über WordPress ausliefert, und dieser Aufbau hat eigene Kosten. Für statische Dateien wird der Header auf dem Server oder im CDN konfiguriert, wie im Abschnitt oben.

Der Anhang erhält in WordPress außerdem eine eigene URL: die Anhangseite. Der Entwicklerhinweis zu WordPress 6.4 hat ihr Verhalten geändert:

• Bei neuen Installationen sind Anhangseiten deaktiviert und leiten auf die Datei URL weiter.
• Die Option wp_attachment_pages_enabled steuert dieses Verhalten: Sie steht bei neuen Installationen auf 0 und wird beim Update einer bestehenden Website auf 1 gesetzt, damit Anhangseiten wie bisher funktionieren.

Auf einer Website, die von einer Version vor 6.4 aktualisiert wurde, kann jedes hochgeladene PDF neben der Datei selbst eine dünne, indexierbare Anhangseite haben. Prüfen Sie den Wert der Option mit WP-CLI (wp option get wp_attachment_pages_enabled), bevor Sie entscheiden, ob Sie ihn ändern.

#Risiken automatischer PDF-Export Plugins in WordPress

Im WordPress-Ökosystem sind Plugins verbreitet, die jedem Beitrag einen PDF-Download Button hinzufügen. Sie nutzen PHP-Bibliotheken wie Dompdf, TCPDF oder mPDF, um das HTML des Artikels bei Bedarf in eine PDF-Datei umzuwandeln.

Mueller erinnerte in Folge 115 an einen Fall aus frühen CMS, möglicherweise Joomla, das jede Seite auch als PDF anzeigen konnte. Weil Google solche Dateien nicht oft neu crawlt, konnte eine Website mit dem alten Inhalt als indexiertem PDF und dem neuen als HTML-Seite dastehen: Beide Versionen konkurrierten miteinander und waren zudem nicht synchron. Sein Fazit: Ist der Inhalt aktuell und dynamisch und Sie müssen ein PDF anbieten, verhindern Sie die Indexierung dieses PDF.

Aus Sicht von Technik und SEO entstehen dadurch drei Probleme:

1. Duplikate im Crawling: Jeder Beitrag erhält eine zweite URL mit demselben Text. Crawler verbringen Zeit mit Kopien statt mit neuen Inhalten.
2. Serverlast: Ein PDF aus gestyltem HTML in PHP zu erzeugen ist aufwendig, und wenn ein Crawler viele Downloads gleichzeitig anfordert, landet die Last bei PHP-FPM.
3. Verlust von Nutzererlebnis und Conversions: Rankt die PDF-Version vor der HTML-Seite, landet der Besucher in einem statischen Dokument ohne Kontaktformulare, Navigation und Handlungsaufforderungen.

Splitt fügte hinzu, dass die meisten Browser auf Mobilgeräten und Desktop bereits erlauben, eine Seite als PDF zu speichern. Websitebetreiber müssen diese Funktion daher normalerweise nicht selbst anbieten. Ein Druck Stylesheet genügt:

@media print {
  header, footer, nav, aside, .sidebar, .comments, .cookie-banner {
    display: none !important;
  }
  body {
    font-size: 12pt;
    color: #000;
    background: #fff;
  }
  a[href^="http"]:after {
    content: " (" attr(href) ")";
  }
}

Mit dieser Regel nutzt ein Leser, der den Artikel speichern möchte, die Druckfunktion des Browsers (Strg + P oder Cmd + P) und erhält ein sauberes PDF, das auf dem eigenen Gerät entsteht, ohne die CPU Ihres Servers zu belasten.

#Warum die Datei llms.txt nicht als PDF veröffentlicht werden sollte

Der Vorschlag llms.txt, im September 2024 von Jeremy Howard veröffentlicht, definiert eine Markdown Datei unter dem Pfad /llms.txt mit kurzen Hintergrundinformationen, Hinweisen und Links zu ausführlicheren Markdown Dateien, um Inhalte bereitzustellen, die Sprachmodelle leicht verarbeiten können.

Folge 115 beginnt genau mit dieser Frage. Mueller fragt, ob es sinnvoll ist, die llms.txt als PDF zu speichern, und Splitt verneint: Die Idee von llms.txt war, Inhalte für Sprachmodelle in der einfachsten möglichen Form bereitzustellen, und PDF ist nicht die einfachste Form von Inhalten im Web. Dass Google PDFs verarbeiten kann, heißt nicht, dass andere es können oder wollen.

Die Datei llms.txt sollte eine Markdown Textdatei im Stammverzeichnis der Website bleiben (https://ihredomain.de/llms.txt) und auf Seiten oder Markdown Dateien verlinken, die sich ohne Konvertierung lesen lassen.

#Wann es sinnvoll ist, ein PDF auf der Website zu veröffentlichen

Folge 115 ist kein Plädoyer gegen PDF. Splitt nennt die Fälle, in denen er es empfiehlt: wenn Inhalte besondere Formatierungsanforderungen haben, wenn sie im Druck ganz bestimmt aussehen müssen oder wenn interaktive Formulare nötig sind. Sein Beispiel ist eine Ferienunterkunft, die ihr Gästeanmeldeformular als PDF veröffentlicht, weil sich die Anmeldungen so leichter bearbeiten lassen.

Bei Speisekarten von Restaurants blieb Mueller pragmatisch: Eine Speisekarte als PDF ist besser als gar keine auf der Website; zwischen PDF und normaler Seite bevorzugt er die Seite, weil sie sich besser zoomen lässt, sich auf dem Smartphone anpasst und etwas schneller lädt. Lässt sich der PDF-Text markieren und kopieren, kann Google ihn für die Suche nutzen.

Zu KI Systemen sagte Mueller, dass PDFs bei Google funktionieren, dass er sie auch in anderen KI Systemen zitiert gesehen hat und dass PDFs die Sichtbarkeit in diesen Systemen nicht zerstören. Wenn derselbe Inhalt aber in HTML vorliegen kann, wird alles etwas einfacher.

Splitt nannte zudem zwei Nutzungsprobleme auf Mobilgeräten: Ein PDF muss vollständig heruntergeladen sein, bevor es angezeigt wird, während eine HTML-Seite so schnell wie möglich Inhalte zeigt, und viele PDFs brechen den Text beim Zoomen nicht neu um.

#Technischer Vergleich von semantischem HTML und statischen PDF-Dokumenten

Außer bei Dokumenten, deren Hauptzweck der Druck, ein Formular oder ein festes Layout ist, funktionieren Inhalte, die ranken und aktuell bleiben sollen, als HTML-Seite besser.

#Migrationsplan für PDF-Dokumente zu HTML in WordPress

Wenn Ihr Unternehmen Dutzende oder Hunderte PDF-Dateien mit technischen Informationen, Produktdatenblättern oder Handbüchern hat, bringt eine geordnete Migration zu HTML-Seiten diese Inhalte in das Format, das Google häufiger crawlt und das Nutzer auf dem Smartphone besser lesen.

1. Technische Bestandsaufnahme: Listen Sie mit einem Crawler alle .pdf Dateien auf dem Server auf und prüfen Sie ihren aktuellen organischen Traffic in der Google Search Console.
2. Texttest: Wenden Sie den Kopier Test auf jedes PDF an. Gerasterte Dokumente sind die ersten Kandidaten für HTML, weil Google ihren Inhalt heute nicht sieht.
3. Neuordnung der Inhalte:
   • Übertragen Sie die wertvollsten Informationen auf neue Seiten in WordPress oder Astro mit semantischen Blöcken.
   • Richten Sie dauerhafte 301 Weiterleitungen von den alten PDF URLs auf die neuen HTML-Seiten ein.
4. Canonicals für unverzichtbare Dateien: Für Dokumente, die als Download bleiben müssen (Formulare, ausfüllbare Vorlagen), setzen Sie den HTTP Header Link: <url>; rel="canonical" auf die Webseite, die das Dokument erklärt, oder X-Robots-Tag: noindex, wenn sie nicht in Google erscheinen sollen. Nie beides zugleich.
5. Metadaten und Rücklink: Füllen Sie Titel, Autor und Beschreibung der verbleibenden PDFs aus und setzen Sie auf die erste Seite einen Link zu Ihrer Website.
6. Anhangseiten: Prüfen Sie wp_attachment_pages_enabled, wenn die Website vor WordPress 6.4 installiert wurde.
7. Automatische Generatoren entfernen: Deaktivieren Sie Plugins zur massenhaften PDF-Erzeugung und bieten Sie stattdessen ein Druck Stylesheet an.
8. Konsistente interne Verlinkung: Verbinden Sie die neuen Seiten mit den zentralen Säulen Ihrer Website Architektur, nach den Empfehlungen aus unserem Sicherheitsaudit für WordPress und unseren Projekten zur WooCommerce ERP-Integration.