Jak Google indeksuje pliki PDF i dlaczego warto zamienić je na HTML w WordPressie

#Jak Google konwertuje pliki PDF do HTML podczas indeksowania

W odcinku 115 oficjalnego podcastu Search Off the Record, opublikowanym 13 października 2026, Martin Splitt i John Mueller z zespołu Search Relations w Google wyjaśnili, jak Google Search obsługuje dokumenty PDF. W wielu firmach i sklepach internetowych wciąż panuje przekonanie, że wrzucenie katalogu albo poradnika technicznego jako PDF to to samo, co opublikowanie zwykłej strony. Odcinek pokazuje, w czym te dwa formaty są podobne, a w czym nie.

HTML to format tekstowy. Wyszukiwarka analizuje kod HTML sekwencyjnie, rozpoznając nagłówki, akapity, listy, dane strukturalne JSON-LD i dyrektywy semantyczne.

Format Portable Document Format (PDF) powstał w innym celu: ma zachować dokładny układ wizualny dokumentu przy druku i na każdym ekranie. Splitt podkreśla, że PDF to binarny kontener: po otwarciu PDF w edytorze tekstu widać nieczytelne znaki, a plik HTML albo Markdown da się przeczytać bez żadnego programu.

Google nie otwiera plików PDF przeglądarką PDF. Według Splitta indeksowanie obejmuje komponent zwany konwerterem, który działa zaraz po renderowaniu i tuż przed tym, jak dokument może trafić do indeksu. Google ma konwertery dla kilku formatów (pliki RTF, dokumenty tekstowe, arkusze Excela, a nawet dokumenty Lotus Notes), a jednym z nich jest konwerter PDF. Jego wynikiem jest wersja HTML dokumentu, możliwie wierna oryginałowi, bo reszta pipeline’u webowego pracuje prawie wyłącznie na HTML.

+-----------------------------------------------------------------------------------+
| Droga pliku PDF przez Google Search (według odcinka 115):                         |
| 1. Crawling pliku (HTTP Content-Type: application/pdf)                            |
| 2. Renderowanie                                                                   |
| 3. Konwerter PDF: tworzy reprezentację HTML dokumentu                             |
| 4. Linki z tej reprezentacji są wykrywane jak na każdej stronie HTML              |
| 5. Indeksowanie i ranking tymi samymi systemami co strona HTML                    |
+-----------------------------------------------------------------------------------+

Dlatego, jak mówi Splitt, indeksowanie i ranking PDF wyglądają praktycznie tak samo jak w przypadku każdego innego dokumentu, a PDF może pojawić się w AI Overviews i w AI Mode. Google nie śledzi, czy dokument był pierwotnie plikiem PDF. Oficjalna lista indeksowanych typów plików wymienia Adobe PDF wśród obsługiwanych formatów zakodowanych.

Mueller dodał zastrzeżenie dotyczące bardzo długich dokumentów: cała książka w jednym pliku PDF stwarza ten sam problem co cała książka na jednej stronie HTML. Wyszukiwarce trudno ustalić, które zdanie jest powodem, dla którego dokument powinien pojawić się na dane zapytanie.

#Które pliki PDF odczyta Googlebot i kiedy zawodzi OCR

Wpis na blogu Google Search Central o plikach PDF, podpisany przez Gary’ego Illyesa, podaje podstawową zasadę: Google może indeksować treść tekstową PDF w dowolnym języku i w różnych kodowaniach znaków, o ile plik nie jest chroniony hasłem ani zaszyfrowany. Jeśli tekst jest osadzony jako obrazy, Google może je przetworzyć algorytmami OCR.

W odcinku 115 Splitt nazywa najgorszym problemem zrastrowane strony: dokumenty, w których każda strona jest w praktyce obrazem. Cała treść tekstowa przepada. Mueller dodaje przypadek zeskanowanych książek archiwizowanych jako PDF: niektóre systemy potrafią przepuścić je przez OCR, ale nie można na tym polegać.

Test, który proponują obaj, jest prosty:

1. Otwórz plik PDF.
2. Zaznacz cały tekst skrótem Ctrl + A albo Cmd + A.
3. Wklej go do dokumentu Google Docs albo do pliku tekstowego.
4. Jeśli tekst się pojawi, Google może go użyć. Jeśli nie, Google również nie widzi treści.

Splitt dodaje, że zrastrowane strony to także problem dostępności: czytniki ekranu i inne technologie wspomagające ich nie odczytają, chyba że generator PDF celowo zadbał o dostępną warstwę treści.

#Jak duży plik PDF pobierze Googlebot

Dokumentacja Googlebota podaje dwa różne limity. Dla obsługiwanych typów plików Googlebot pobiera pierwsze 2 MB. Dla PDF pobiera pierwsze 64 MB. Limit liczy się od treści po dekompresji, nie od rozmiaru transferu. Po jego osiągnięciu Googlebot przerywa pobieranie i przekazuje do indeksowania tylko już pobraną część.

W odcinku Splitt przyznał, że nie pamięta dokładnej liczby dla PDF, i wyjaśnił, dlaczego Google woli jej nie betonować: limit można zmienić, a gdyby wydawcy zaczęli publikować dużo większe pliki PDF, Google mógłby go podnieść, żeby nie tracić przydatnych informacji. Aktualnym źródłem jest dokumentacja; liczba może się zmienić.

W praktyce limit dotyczy niewielu dokumentów. Katalog pełen zdjęć w wysokiej rozdzielczości może się do niego zbliżyć, a wtedy tekst z ostatnich stron może zostać poza indeksem.

#Dlaczego linki w PDF przekazują PageRank, a obrazy nie rankują

#Jak zachowują się linki tekstowe

Ponieważ konwerter tworzy wersję HTML, linki z PDF zostają zachowane. Blog Google Search Central to potwierdza: linki w plikach PDF są traktowane podobnie jak linki w HTML, mogą przekazywać PageRank i inne sygnały indeksowania, a Google może za nimi podążać po zaindeksowaniu PDF.

• Przekazywanie autorytetu: linki w PDF mogą przekazywać PageRank do stron docelowych.
• Odkrywanie nowych adresów: Googlebot może odwiedzić wykryte adresy po pobraniu pliku.
• Brak nofollow: według tego samego wpisu nie da się użyć linków nofollow wewnątrz dokumentu PDF.

Te linki mają wadę dla każdego, kto mierzy wyniki. Na stronie internetowej kliknięcia przechwytuje Google Tag Manager albo skrypt analityki strony. Ten skrypt nie działa w PDF otwartym w przeglądarce, więc to, co czytelnik robi w dokumencie, zostaje poza analityką.

#Problem z obrazami osadzonymi w PDF

Na stronie zbudowanej na WordPressie albo Astro każde zdjęcie jest osobnym zasobem z własnym adresem URL, atrybutem alt, jawnymi wymiarami i nowoczesnymi formatami, takimi jak AVIF czy WebP. Dzięki temu Google Grafika może oceniać każdy obraz osobno.

W pliku PDF obrazy są częścią samego pliku. Splitt wyjaśnił, że Google zwykle przekazuje adresy URL obrazów do pipeline’u wyszukiwarki grafiki, a obraz w PDF nie ma adresu URL. Jego zdaniem Google wie, że obraz tam jest, ale nie może go przetworzyć jak zwykłego obrazu dla Google Grafika, choć to może się zmienić. Wpis z 2011 roku był bardziej stanowczy: obrazy z plików PDF nie są indeksowane, a żeby zostały zaindeksowane, trzeba dla nich stworzyć strony HTML.

Jeśli firma publikuje infografiki, diagramy architektury albo porównania wizualne tylko w PDF, nie powinna liczyć na ruch z Google Grafika.

#Dlaczego Google późno zauważa zmiany w zaktualizowanym PDF

Mueller wyjaśnił w odcinku 115, że częstotliwość ponownego pobierania plików PDF przypomina tę dla obrazów. Systemy Google nie pobierają PDF co kilka minut, bo zakładają, że plik raczej długo się nie zmieni, i nie chcą ściągać z serwera wielu dużych plików, co mogłoby powodować problemy.

Splitt dodał inną różnicę: dokument HTML łatwo edytować w CMS, a wygenerowanego PDF nie da się zmienić bez narzędzia takiego jak Adobe Acrobat Pro; zwykle trzeba trzymać plik źródłowy i generować PDF od nowa.

Jeśli zmieniasz cennik, instrukcję techniczną albo regulamin, wgrywając nową wersję pod tą samą nazwą i adresem, fragment pokazywany przez Google i odpowiedzi AI Overviews mogą jeszcze długo opierać się na starej wersji. Google nie podaje terminu, więc nie ma wiarygodnej liczby, którą można by tu wpisać.

#Jak przyspieszyć indeksowanie zaktualizowanego pliku PDF

Mueller zaleca nową nazwę pliku. Gdy Google znajdzie link do nowego adresu, rozpozna go jako nowy dokument i pobierze go oraz zaindeksuje. Do tego dodajemy, jako własną praktykę, a nie wytyczną Google, przekierowanie 301 ze starej ścieżki:

Strategia wersjonowania przeciw nieaktualnej treści w indeksie:
Stara wersja:  https://twojadomena.pl/katalogi/specyfikacja-techniczna-2025.pdf
Nowa wersja:   https://twojadomena.pl/katalogi/specyfikacja-techniczna-2026-v2.pdf

Konfiguracja serwera:
Stała odpowiedź HTTP 301 ze starej ścieżki na nową wersję.
Linki wewnętrzne zaktualizowane do nowego adresu.

Splitt uzupełnił radę o cache HTTP: jeśli wiesz, że katalog zmienia się co kwartał, możesz trzymać go w cache przez kilka miesięcy; jeśli plik zmienia się często, długi cache traci sens.

#Jak kontrolować tytuł i metadane pliku PDF w Google

PDF nie ma znacznika HTML title. Według bloga Google Search Central Google używa dwóch głównych elementów do wyboru tytułu w wynikach: tytułu zapisanego w metadanych pliku i tekstu kotwicy linków prowadzących do PDF. Żeby dać wyraźny sygnał, Google zaleca zadbać o oba.

Splitt dodał w odcinku 115, że warto wypełnić metadane PDF: autora, opis zawartości i, jeśli to możliwe, link do miejsca, z którego dokument pochodzi. Mueller zaproponował krok bardziej praktyczny: umieścić w nagłówku samego PDF zwykły link do strony głównej serwisu. Gdy Google konwertuje PDF do HTML, ten link zostaje, a osoba, która trafi na PDF z wyszukiwarki, ma drogę powrotną do strony.

W procesie pracy z WordPressem oznacza to:

1. Przed wgraniem PDF sprawdź w programie, który go generuje, pola tytułu dokumentu, autora i opisu.
2. Linkuj do PDF ze strony HTML opisowym tekstem kotwicy, a nie słowami “pobierz” czy “tutaj”.
3. Na pierwszej stronie PDF umieść widoczny link do strony HTML, do której dokument należy.

#Jak ustawić nagłówek HTTP Link rel canonical dla dokumentów PDF

Gdy organizacja udostępnia raport zarówno jako artykuł, jak i PDF do pobrania, pojawia się ryzyko duplikacji. Mueller opisał w odcinku dodatkowy problem: PDF to binarny blob. Jeśli inny serwis pobierze twój PDF i go opublikuje, wyszukiwarka widzi dwa pliki identyczne co do bajta, a kanonikalizacja jest trudniejsza niż przy podobnych stronach HTML.

Na stronie HTML preferowaną wersję deklaruje się znacznikiem link rel="canonical" w sekcji head. PDF takiej sekcji nie ma. Dokumentacja Google o zduplikowanych adresach URL mówi, że jeśli możesz zmienić konfigurację serwera, możesz użyć nagłówka odpowiedzi HTTP Link z rel="canonical", zdefiniowanego w RFC 5988, także dla dokumentów innych niż HTML, takich jak pliki PDF. Google zaznacza, że ta metoda działa tylko dla wyników wyszukiwania w sieci.

Ta sama strona zawiera dwa ostrzeżenia ważne dla PDF. Google nie zaleca używania noindex, żeby zapobiec wyborowi strony kanonicznej w obrębie jednego serwisu, bo całkowicie blokuje to stronę w wyszukiwarce. Nie należy też wskazywać różnych adresów kanonicznych dla tej samej strony różnymi technikami. Dla PDF wybiera się więc jedną z dwóch opcji:

• Canonical: PDF pozostaje dostępny, a sygnały konsolidują się na stronie HTML.
• Noindex: PDF znika z wyników (zob. następną sekcję).

#Konfiguracja na serwerach Nginx

location ~* \.pdf$ {
    # Link kanoniczny do głównej wersji HTML
    add_header Link '<https://twojadomena.pl/dokumentacja-techniczna/>; rel="canonical"';
}

#Konfiguracja na serwerach Apache (.htaccess)

Przy włączonym module mod_headers:

<FilesMatch "\.pdf$">
    Header set Link '<https://twojadomena.pl/dokumentacja-techniczna/>; rel="canonical"'
</FilesMatch>

#Konfiguracja w Cloudflare Pages i sieciach CDN

W Cloudflare Pages i podobnych platformach hostingu statycznego regułę wpisuje się do pliku _headers:

/dokumenty/*.pdf
  Link: <https://twojadomena.pl/dokumentacja-techniczna/>; rel="canonical"

Reguła dla wzorca plików kieruje wszystkie PDF na tę samą stronę. Jeśli każdy PDF ma własną stronę HTML, potrzebna jest reguła na plik albo na katalog.

#Jak usunąć plik PDF z wyników Google

Według bloga Google Search Central najprostszy sposób, żeby PDF nie pojawiał się w wynikach, to wysyłanie z plikiem nagłówka HTTP X-Robots-Tag: noindex. Jeśli PDF jest już zaindeksowany, z czasem wypadnie z wyników; do szybszego usunięcia ten sam wpis odsyła do narzędzia do usuwania adresów URL w Search Console.

Dokumentacja metatagu robots pokazuje ten przypadek dla wszystkich PDF w serwisie, z noindex, nofollow:

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

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

Jeśli Google ma dalej korzystać z linków w PDF do odkrywania stron, wystarczy samo noindex: ta sama dokumentacja wyjaśnia, że bez reguły nofollow Google może używać linków na stronie do odkrywania podlinkowanych stron.

Są jeszcze dwie drogi, o innych skutkach:

• Hasło: Splitt przypomina, że wyszukiwarki nie odczytają PDF chronionego hasłem. To rozwiązanie dla dokumentów, które nie mają być publiczne.
• robots.txt: blokuje pobranie PDF przez Google. Dokumentacja o zduplikowanych adresach ostrzega jednak, że Google może zaindeksować adresy zablokowane w robots.txt bez ich treści. Jeśli celem jest usunięcie pliku z wyników, właściwym narzędziem jest nagłówek noindex, a Google zobaczy go tylko wtedy, gdy może pobrać plik.

#Jak WordPress obsługuje pliki PDF wgrane do biblioteki mediów

Po wgraniu PDF do biblioteki mediów WordPress zapisuje plik w wp-content/uploads i tworzy załącznik w bazie danych. Sam plik serwuje bezpośrednio serwer WWW (Nginx, Apache) albo CDN, bez ładowania WordPressa. Ten szczegół decyduje o tym, gdzie konfiguruje się nagłówki.

Hook send_headers uruchamia się w WP::send_headers(), gdy WordPress obsługuje żądanie. Bezpośrednie żądanie /wp-content/uploads/2026/10/katalog.pdf nigdy nie trafia do WordPressa, więc kod w functions.php, który próbuje dodać nagłówek canonical do tego PDF, się nie wykona. Nagłówek da się dodać z PHP tylko wtedy, gdy wtyczka wydaje plik przez WordPressa, a taki układ ma własny koszt. Dla plików statycznych nagłówek ustawia się na serwerze albo w CDN, jak w poprzedniej sekcji.

Załącznik dostaje też własny adres w WordPressie: stronę załącznika. Notatka deweloperska do WordPressa 6.4 zmieniła jej działanie:

• W nowych instalacjach strony załączników są wyłączone i przekierowują na adres pliku.
• Opcja wp_attachment_pages_enabled steruje tym zachowaniem: ma wartość 0 w nowych instalacjach i jest ustawiana na 1 przy aktualizacji istniejącego serwisu, żeby strony załączników działały jak wcześniej.

W serwisie zaktualizowanym z wersji starszej niż 6.4 każdy wgrany PDF może mieć, oprócz samego pliku, cienką, indeksowalną stronę załącznika. Sprawdź wartość opcji przez WP-CLI (wp option get wp_attachment_pages_enabled), zanim zdecydujesz, czy ją zmienić.

#Ryzyka wtyczek do automatycznego eksportu PDF w WordPressie

W ekosystemie WordPressa popularne są wtyczki, które dodają do każdego wpisu przycisk pobierania PDF. Korzystają z bibliotek PHP takich jak Dompdf, TCPDF albo mPDF, które w chwili żądania zamieniają HTML artykułu na plik PDF.

Mueller przypomniał w odcinku 115 przypadek z wczesnych CMS-ów, prawdopodobnie Joomli, która pozwalała wyświetlić każdą stronę jako PDF. Ponieważ Google nie pobiera takich plików często, serwis mógł skończyć ze starą treścią zaindeksowaną jako PDF i nową jako stroną HTML: obie wersje konkurowały ze sobą i do tego się rozjeżdżały. Jego wniosek: jeśli treść jest świeża i dynamiczna, a musisz udostępnić PDF, nie pozwól go indeksować.

Z perspektywy inżynierii i SEO ta praktyka tworzy trzy problemy:

1. Duplikaty w crawlingu: każdy wpis dostaje drugi adres z tym samym tekstem. Roboty poświęcają czas na kopie zamiast na nowe treści.
2. Obciążenie serwera: generowanie PDF z ostylowanego HTML w PHP to kosztowna operacja, a gdy robot zażąda wielu pobrań naraz, obciążenie spada na PHP-FPM.
3. Utrata doświadczenia użytkownika i konwersji: jeśli wersja PDF wyprzedzi stronę HTML w wynikach, odwiedzający trafia na statyczny dokument bez formularzy kontaktowych, nawigacji i wezwań do działania.

Splitt dodał, że większość przeglądarek na telefonach i komputerach pozwala już zapisać stronę jako PDF, więc właściciel serwisu zwykle nie musi tego oferować. Wystarczy arkusz stylów do druku:

@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) ")";
  }
}

Dzięki tej regule użytkownik, który chce zapisać artykuł, używa funkcji drukowania w przeglądarce (Ctrl + P albo Cmd + P) i dostaje czysty PDF wygenerowany na własnym urządzeniu, bez zużywania procesora twojego serwera.

#Dlaczego pliku llms.txt nie należy publikować jako PDF

Propozycja llms.txt, opublikowana przez Jeremy’ego Howarda we wrześniu 2024, definiuje plik Markdown pod ścieżką /llms.txt z krótkim opisem, wskazówkami i linkami do bardziej szczegółowych plików Markdown, żeby udostępnić treść łatwą do przetworzenia dla modeli językowych.

Odcinek 115 zaczyna się właśnie od tego pytania. Mueller pyta, czy ma sens zapisanie llms.txt jako PDF, a Splitt odpowiada, że nie: idea llms.txt polegała na udostępnieniu treści modelom językowym w najprostszej możliwej formie, a PDF nie jest najprostszą formą treści w sieci. To, że Google potrafi przetwarzać PDF, nie znaczy, że inni potrafią albo chcą.

Plik llms.txt powinien pozostać plikiem tekstowym w Markdown w katalogu głównym serwisu (https://twojadomena.pl/llms.txt), z linkami do stron albo plików Markdown czytelnych bez konwersji.

#Kiedy publikowanie PDF na stronie ma sens

Odcinek 115 nie jest wystąpieniem przeciw PDF. Splitt wymienia przypadki, w których go poleca: gdy treść ma szczególne wymagania co do formatowania, gdy musi wyglądać bardzo konkretnie w druku albo gdy potrzebne są interaktywne formularze. Jego przykład to pensjonat, który publikuje formularz meldunkowy gości jako PDF, bo tak łatwiej go przetwarzać.

W sprawie menu restauracji Mueller był pragmatyczny: menu w PDF jest lepsze niż brak menu na stronie; między PDF a zwykłą stroną woli stronę, bo lepiej się powiększa, dopasowuje się do telefonu i ładuje trochę szybciej. Jeśli tekst z PDF da się zaznaczyć i skopiować, Google może go użyć w wyszukiwarce.

O systemach AI Mueller dodał, że w Google pliki PDF działają, że widział je cytowane także w innych systemach AI i że publikowanie PDF nie niszczy widoczności w tych systemach. Ale jeśli ta sama treść może być w HTML, wszystko staje się trochę prostsze.

Splitt wskazał też dwa problemy z używaniem PDF na telefonie: PDF musi pobrać się w całości, zanim się wyświetli, podczas gdy strona HTML zaczyna pokazywać treść jak najszybciej, a wiele PDF nie przelewa tekstu przy powiększaniu.

#Porównanie techniczne semantycznego HTML i statycznych plików PDF

Poza dokumentami, których głównym celem jest druk, formularz albo stały układ, treść, która ma rankować i być aktualna, sprawdza się lepiej jako strona HTML.

#Plan migracji dokumentów PDF do HTML w WordPressie

Jeśli firma ma dziesiątki albo setki plików PDF z informacjami technicznymi, kartami produktów czy instrukcjami, uporządkowana migracja do stron HTML przenosi tę treść do formatu, który Google odwiedza częściej, a użytkownicy lepiej czytają na telefonie.

1. Inwentaryzacja techniczna: przeskanuj serwis crawlerem, wypisz wszystkie pliki .pdf na serwerze i sprawdź ich obecny ruch organiczny w Google Search Console.
2. Test tekstu: przepuść każdy PDF przez test kopiowania i wklejania. Dokumenty zrastrowane to pierwsi kandydaci do przeniesienia do HTML, bo dziś Google nie widzi ich treści.
3. Reorganizacja treści:
   • Przenieś najcenniejsze informacje na nowe strony w WordPressie albo Astro, zbudowane z bloków semantycznych.
   • Ustaw stałe przekierowania 301 ze starych adresów PDF na nowe strony HTML.
4. Kanoniczne adresy dla plików, które muszą zostać: dla dokumentów, które mają pozostać do pobrania (formularze, szablony do wypełnienia), dodaj nagłówek HTTP Link: <url>; rel="canonical" wskazujący stronę, która opisuje dokument, albo X-Robots-Tag: noindex, jeśli nie mają pojawiać się w Google. Nigdy obu naraz.
5. Metadane i link powrotny: uzupełnij tytuł, autora i opis w plikach PDF, które zostają, i dodaj na pierwszej stronie link do serwisu.
6. Strony załączników: sprawdź wp_attachment_pages_enabled, jeśli serwis zainstalowano przed WordPressem 6.4.
7. Usunięcie automatycznych generatorów: wyłącz wtyczki masowo tworzące PDF i zaproponuj zamiast nich arkusz stylów do druku.
8. Spójne linkowanie wewnętrzne: połącz nowe strony z głównymi filarami serwisu, korzystając z zaleceń z naszych publikacji o audycie bezpieczeństwa WordPress oraz integracjach WooCommerce z ERP.