Plik robots.txt - co w nim wpisać, a czego lepiej nie
Plik robots.txt to lista wskazówek dla robotów odwiedzających stronę: dokąd mogą wejść, a dokąd nie. Nie jest zabezpieczeniem i nie ukrywa niczego przed ludźmi. Najczęstszy problem nie polega na braku wpisu ani na złym wpisie, tylko na wpisie, którego zabrakło: reguła ogólna blokuje wszystko, po niej idzie lista wyjątków, a ktoś, kogo na tej liście nie ma, zostaje zablokowany, choć nikt tego nie planował.
Plik leży zawsze w tym samym miejscu: pod adresem domeny zakończonym ukośnikiem i nazwą pliku. Wystarczy wpisać go w przeglądarce, żeby zobaczyć własny. Wiele stron w ogóle go nie ma: w pomiarze Cloudflare z czerwca 2025 na dziesięciu tysiącach najpopularniejszych domen plik robots.txt miało tylko 37 procent.
Czym jest plik robots.txt
Robots.txt to zwykły plik tekstowy w katalogu głównym strony. Zawiera reguły mówiące robotom, których adresów nie powinny pobierać.
Najprostszy działający plik wygląda tak:
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://twojadomena.pl/wp-sitemap.xmlPierwsza linia mówi, do kogo skierowane są reguły, gwiazdka oznacza wszystkie roboty. Druga blokuje katalog administracyjny. Trzecia robi wyjątek dla pliku, który jest potrzebny do działania strony. Ostatnia wskazuje mapę witryny.
W pliku używa się kilku poleceń. User-agent wskazuje robota, do którego odnoszą się kolejne reguły. Disallow mówi, czego nie pobierać. Allow robi wyjątek od blokady. Sitemap wskazuje mapę witryny. W ścieżkach działają dwa znaki specjalne: gwiazdka zastępuje dowolny ciąg znaków, a znak dolara oznacza koniec adresu. Wielkość liter w nazwie robota nie ma znaczenia, w ścieżce adresu ma. Google czyta pierwsze 500 kibibajtów pliku, resztę pomija, co przy typowej stronie firmowej nie ma żadnego znaczenia.
Dwie rzeczy, których robots.txt nie robi. Nie chroni treści, bo plik jest publiczny i każdy może zobaczyć, co właściciel próbował ukryć. Nie usuwa stron z wyników wyszukiwania, o czym za chwilę, bo to najczęstsze nieporozumienie w całym temacie.
Która reguła naprawdę obowiązuje
Mylą się tu nawet osoby pracujące ze stronami na co dzień. Stąd bierze się błąd opisany dalej w tym tekście. Obowiązują dwie zasady i żadna z nich nie ma nic wspólnego z kolejnością linii w pliku.
Zasada pierwsza: dla danego robota liczy się dokładnie jedna grupa. Robot szuka bloku User-agent z najbardziej szczegółową nazwą, która do niego pasuje, i czyta wyłącznie ten blok. Jeśli w pliku jest blok User-agent: Googlebot, to Googlebot czyta tylko jego, a blok User-agent: * ignoruje w całości, nawet jeśli są w nim reguły ostrzejsze albo łagodniejsze. Jeśli własnego bloku nie ma, robot bierze blok ogólny i stosuje go w całości.
To ma bezpośrednią konsekwencję praktyczną. W pliku zbudowanym tak, że blok ogólny blokuje wszystko, a nazwane bloki robią wyjątki, każdy robot pominięty na liście wyjątków jest zablokowany. Nie dlatego, że ktoś go zablokował, tylko dlatego, że o nim nie pomyślał.
Zasada druga: w obrębie jednej grupy wygrywa reguła o najdłuższej ścieżce. Jeśli do adresu pasuje i Disallow, i Allow, decyduje ta, której zapis ścieżki jest dłuższy. Przy równej długości Google stosuje regułę mniej restrykcyjną, czyli Allow. Dlatego w przykładzie wyżej Allow: /wp-admin/admin-ajax.php wygrywa z Disallow: /wp-admin/: jest dłuższy, mimo że stoi niżej.
Kolejność linii nie ma znaczenia. Znaczenie ma nazwa robota i długość ścieżki.
Co się dzieje, gdy plik nie odpowiada
Brak pliku i niedziałający plik to dwie różne sytuacje o przeciwnych skutkach. Google opisuje to wprost:
| Odpowiedź serwera | Jak zachowuje się robot Google |
|---|---|
| 2xx, plik się otwiera | Czyta i stosuje reguły z pliku |
| Przekierowanie | Idzie za nim przez maksymalnie pięć skoków, potem traktuje jak brak pliku |
| 4xx, na przykład 404 | Zachowuje się tak, jakby pliku nie było: wchodzi wszędzie |
| 5xx albo 429 | Przez pierwsze 12 godzin wstrzymuje przechodzenie całej strony, przez 30 dni korzysta z ostatniej zapamiętanej wersji pliku, po 30 dniach zachowuje się tak, jak przy braku pliku, o ile strona sama działa |
Praktyczny wniosek jest taki, że 404 na robots.txt jest niegroźne, a błąd serwera groźny. Strona, której serwer przy każdym zapytaniu o robots.txt zwraca piątkę, na pół dnia przestaje być przechodzona w całości. Zdarza się to przy przeciążeniu, przy agresywnych zabezpieczeniach przed botami i przy wtyczkach ograniczających ruch.
Taki błąd jest zwykle chwilowy i właśnie dlatego trudny do zauważenia: plik nie odpowiada przez godzinę, po czym wraca, a strona przez cały ten czas wygląda normalnie. Przy sprawdzeniu raz na kwartał albo się go przegapi, albo weźmie za stan trwały i zacznie szukać przyczyny tam, gdzie jej nie ma. To jest powód, dla którego dostęp robotów mierzy się cyklicznie, a nie jednorazowo.
Robots.txt a noindex: dwie różne rzeczy
Robots.txt steruje dostępem robota do adresu. Znacznik noindex steruje obecnością adresu w wynikach wyszukiwania. To nie jest to samo i mylenie tych dwóch rzeczy prowadzi do sytuacji odwrotnej do zamierzonej.
Jeśli strona zostanie zablokowana w robots.txt, robot nie może jej pobrać. Skoro nie może jej pobrać, nie odczyta również znacznika noindex, który jest w jej kodzie. Google mówi o tym jednym zdaniem: reguły dotyczące indeksowania i wyświetlania na zablokowanej stronie nie zostaną znalezione, więc zostaną pominięte. Strona może więc pojawić się w wynikach, jeśli prowadzą do niej linki z innych miejsc, tylko bez opisu, bo wyszukiwarka nie wie, co na niej jest.
Właściwa kolejność jest odwrotna do intuicji: żeby usunąć stronę z wyników, trzeba pozwolić robotowi ją odczytać i umieścić w niej znacznik noindex. Blokada w robots.txt służy do czegoś innego: do oszczędzenia robotom czasu na adresach, które nie mają znaczenia, na przykład na wynikach wyszukiwarki wewnętrznej albo koszyku.
Co zrobić, jeśli strona jest już zablokowana i mimo to widnieje w wynikach? Zdjąć blokadę z robots.txt, dodać znacznik noindex i poczekać, aż robot odwiedzi adres ponownie. Kolejność ma znaczenie, bo przy odwrotnej strona zostanie w wynikach na dłużej.
Co wpisać na WordPressie
WordPress generuje plik robots.txt sam, wirtualnie. Nie ma go fizycznie na serwerze, dopóki ktoś go tam nie umieści. Wersja domyślna jest bardzo oszczędna: blokada katalogu administracyjnego z wyjątkiem pliku obsługującego zapytania.
Jeden szczegół oszczędza tu zbędnej pracy. Od wersji 5.5 WordPress sam dopisuje do tego pliku linię z mapą witryny, wskazującą na własną mapę pod adresem zakończonym wp-sitemap.xml. Dopisuje ją tylko wtedy, gdy strona nie jest ustawiona jako niewidoczna dla wyszukiwarek. Jeśli w serwisie działa Yoast albo Rank Math, mapa nazywa się sitemap_index.xml i wtyczka podmienia ten wpis na własny. Zanim więc doda się linię z mapą ręcznie, trzeba sprawdzić, czy już jej tam nie ma, bo przy dwóch różnych mapach w jednym pliku łatwo o pomyłkę.
Sensowny plik dla typowej strony firmowej:
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /*?s=
Disallow: /*?replytocom
Sitemap: https://twojadomena.pl/wp-sitemap.xmlDwie dodatkowe reguły blokują wyniki wyszukiwarki wewnętrznej i adresy odpowiedzi w komentarzach. Jedno i drugie potrafi wygenerować setki adresów bez własnej wartości. Gwiazdka na początku ścieżki jest tu potrzebna: sam zapis /?s= pasuje wyłącznie do adresów zaczynających się dokładnie tak, więc pominąłby na przykład drugą stronę wyników wyszukiwania.
Czego nie blokować:
- katalogów z motywem i wtyczkami, bo robot nie zobaczy strony tak, jak widzi ją użytkownik
- katalogu z plikami graficznymi, jeśli zdjęcia mają się pojawiać w wynikach
- całego katalogu wp-content, co jest częstym skrótem myślowym i odcina wszystko naraz
Jeszcze jedna rzecz specyficzna dla WordPressa. Wtyczki do optymalizacji potrafią nadpisywać zawartość pliku własnymi regułami i robią to bez ostrzeżenia. Jeśli plik wygląda inaczej, niż został ustawiony, najpierw warto sprawdzić ustawienia wtyczki, a dopiero potem szukać przyczyny na serwerze. Zdarza się też, że fizyczny plik na serwerze i wersja generowana przez WordPressa istnieją równolegle, a widoczna jest tylko jedna z nich, ta na serwerze.
Po każdej zmianie warto otworzyć plik w przeglądarce i sprawdzić, czy wygląda tak, jak powinien.
Roboty asystentów AI: trzy role, trzy różne skutki blokady
Poza robotami wyszukiwarek strony odwiedzają dziś roboty asystentów AI. Nie są jednolite: pełnią trzy różne role, a blokada każdej z nich znaczy co innego.
| Rola robota | Co robi | Co się dzieje po zablokowaniu | Ile ich sprawdzamy |
|---|---|---|---|
| Pobierający treść na bieżąco | wchodzi na stronę, gdy asystent odpowiada na pytanie użytkownika | asystent nie zacytuje strony i nie poda jej jako źródła | 8 |
| Zbierający dane do uczenia | pobiera treść, która posłuży do trenowania modelu | strona nie trafi do danych uczących, ale nadal może być cytowana w odpowiedziach | 7 |
| Reklamowy | pobiera treść na potrzeby systemów reklamowych | brak wpływu na odpowiedzi asystenta | 1 |
Właściciel strony może więc świadomie zablokować roboty uczące, jeśli nie chce, żeby jego treść posłużyła do trenowania modeli, i nadal być cytowanym w odpowiedziach. To dwie osobne decyzje, a większość poradników traktuje je jako jedną.
Wygląda to tak. Roboty uczące, które najczęściej się blokuje, to GPTBot, ClaudeBot, Google-Extended, Applebot-Extended, Amazonbot, Meta-ExternalAgent i CCBot. Roboty pobierające treść na bieżąco, których blokować nie należy, jeśli firma chce być cytowana, to OAI-SearchBot, ChatGPT-User, PerplexityBot, Perplexity-User, Claude-Web, Applebot, a także zwykłe Googlebot i Bingbot.
Plik realizujący taką decyzję wygląda następująco:
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
User-agent: GPTBot
Disallow: /
User-agent: ClaudeBot
Disallow: /
User-agent: CCBot
Disallow: /I tu wraca zasada z początku tekstu, bo w tym miejscu najłatwiej o pomyłkę kosztowną w skutkach. Robot, który dostał własny blok, przestaje czytać blok ogólny. GPTBot z powyższego przykładu nie zobaczy już reguły Disallow: /wp-admin/, bo ta jest w grupie *, której on nie czyta. Jeśli reguły z bloku ogólnego mają obowiązywać także jego, trzeba je w jego bloku powtórzyć. W tym przypadku nie ma to znaczenia, bo blokada dotyczy całej strony, ale przy bardziej rozbudowanym pliku potrafi otworzyć dostęp do rzeczy, które miały być zamknięte.
Do grupy pobierającej treść na bieżąco należą też zwykłe roboty wyszukiwarek, Googlebot i Bingbot, bo to one dostarczają treść do odpowiedzi generowanych w wynikach wyszukiwania. Blokada Googlebota odcina więc jednocześnie od wyników Google i od tego, co Google na ich podstawie generuje.
Dobra wiadomość jest taka, że reguły z pliku są w praktyce respektowane. Sieć pomiarowa Known Agents, obejmująca ponad pięć tysięcy stron, podaje, że 96,2 procent robotów stosuje się do robots.txt, a wśród robotów zbierających treść dla modeli AI jest to 96,0 procent. Plik nie jest zabezpieczeniem, ale jako wskazówka działa.
Ile stron w Polsce faktycznie blokuje roboty AI
Polskich pomiarów na ten temat jest niewiele, ale jeden istnieje i jest wart uwagi. Reuters Institute na Uniwersytecie Oksfordzkim sprawdził pod koniec 2023 roku po piętnaście najpopularniejszych serwisów informacyjnych w dziesięciu krajach. Wynik dla Polski: roboty OpenAI blokowało 20 procent serwisów, a Google-Extended 7 procent. To najniższe wartości ze wszystkich badanych krajów. Dla porównania w Stanach Zjednoczonych roboty OpenAI blokowało 79 procent serwisów, a w Niemczech Google-Extended 60 procent.
Wniosek dla polskiej firmy jest dwustronny. Z jednej strony konkurencja rzadko blokuje cokolwiek świadomie, więc blokada u siebie oznacza zwykle pomyłkę, a nie strategię. Z drugiej strony blokady przypadkowe zdarzają się wszędzie tak samo, tylko trudniej je u nas zauważyć, bo nikt ich nie szuka.
Google to osobny przypadek i łatwo się tu pomylić
Można często przeczytać, że wpis blokujący Google-Extended wyłącza firmę z odpowiedzi generowanych w wyszukiwarce Google. Tak nie jest, a pomyłka bywa kosztowna w drugą stronę: ktoś blokuje Google-Extended w przekonaniu, że chroni się przed czymś, czego ten wpis w ogóle nie dotyczy.
Google-Extended steruje wykorzystaniem treści do trenowania modeli Gemini i do ugruntowywania ich odpowiedzi. Google pisze wprost, że nie wpływa on ani na obecność strony w wynikach wyszukiwania, ani na pozycje. Nie jest też wymieniany jako sterowanie odpowiedziami generowanymi w samej wyszukiwarce.
Tym, ile treści może trafić do takiej odpowiedzi, sterują znaczniki nosnippet, data-nosnippet i max-snippet. Google podaje przy nich wprost, że dotyczą również odpowiedzi generowanych w wyszukiwarce i trybu AI. I tu wraca zasada z początku tekstu: te znaczniki są w kodzie strony, więc działają tylko wtedy, gdy Googlebot może stronę pobrać. Blokada w robots.txt nie daje kontroli nad tym, co się z treścią stanie, tylko tę kontrolę odbiera.
Przypadek z pomiaru: dwa roboty zablokowane przez pominięcie
Mechanizm z poprzedniej sekcji najlepiej widać na konkretnym pliku. W jednym z serwisów, które sprawdzaliśmy, dostęp robotów pobierających treść był przez dwa miesiące pełny: przechodziło wszystkie osiem. W kolejnym sprawdzeniu przeszło sześć. Zablokowane okazały się roboty pobierające treść dla dwóch asystentów, przy czym pozostałe sześć, w tym Googlebot i Bingbot, przechodziły dalej bez przeszkód. Zmiany nie zgłosił nikt i nie widać jej w żadnym raporcie z wyszukiwarki, bo żaden takiego raportu nie generuje. Wyszła wyłącznie z ponownego sprawdzenia pliku.
Powód widać w samej strukturze pliku. Blok ogólny blokował całą stronę, a pod nim stała lista nazwanych robotów z wyjątkami. Na liście były między innymi Googlebot, Bingbot i roboty OpenAI. Nie było na niej tych dwóch. Zgodnie z pierwszą zasadą, robot bez własnego bloku bierze blok ogólny w całości, a ten mówił, żeby nie wchodzić.
Widać przy tym różnicę między blokadą świadomą a przypadkową, i to jest jedyny sposób, żeby je odróżnić. Dwa roboty uczące miały w tym pliku własne bloki z regułą blokującą, co wygląda na decyzję. Te dwa pobierające treść nie miały żadnego wpisu, co wygląda na pominięcie. Skutek dla firmy jest taki sam, przyczyna zupełnie inna, a poprawka zajmuje dwie linijki.
Dostęp robotów to jeden z elementów, które sprawdzamy przy pozycjonowaniu w AI, bo bez niego reszta pracy nie ma znaczenia.
Najczęstsze błędy
Blok ogólny blokujący wszystko, z niekompletną listą wyjątków. Opisany wyżej. Jeśli plik jest zbudowany na zasadzie „blokuj wszystko, potem przepuść wybranych", listę wybranych trzeba przeglądać co jakiś czas, bo nowe roboty pojawiają się częściej niż aktualizacje takich plików.
Reguła z wersji testowej przeniesiona na produkcję. Podczas budowy strony blokuje się wszystko, żeby wersja robocza nie trafiła do wyników. Po uruchomieniu trzeba tę regułę zdjąć i to jest moment, o którym najłatwiej zapomnieć. Skutek: strona działa, wygląda dobrze i jest niewidoczna.
Blokowanie zasobów potrzebnych do wyświetlenia strony. Style i skrypty muszą być dostępne, inaczej robot widzi coś innego niż użytkownik.
Brak adresu mapy witryny. Jedna linijka, która pomaga odnaleźć wszystkie podstrony. Na WordPressie od wersji 5.5 zwykle jest dopisana automatycznie, ale lepiej to sprawdzić, a nie zakładać.
Blokowanie zamiast znacznika noindex. Opisane wyżej: nie usuwa strony z wyników, a uniemożliwia jej usunięcie.
Plik zwracający błąd serwera. Groźniejszy niż brak pliku, bo wstrzymuje przechodzenie całej strony na kilkanaście godzin.
Osobna sprawa, choć powiązana: uporządkowany plik robots.txt niewiele da, jeśli robot i tak sporą część czasu spędza na adresach, które zamiast treści zwracają przekierowanie. W serwisach, które przechodziliśmy, potrafi to być znaczący ułamek wszystkich napotkanych adresów. Pisaliśmy o tym przy okazji linkowania wewnętrznego.
Sprawdzenie pliku robots.txt i dostępu robotów jest częścią audytu SEO i AI.
Czy warto przy okazji dodać plik llms.txt
Llms.txt to propozycja formatu, w którym strona opisywałaby swoją treść w sposób wygodny dla modeli językowych. Powstała we wrześniu 2024 roku, ma więc za sobą dwa lata na sprawdzenie się w praktyce. Pytanie o nią pojawia się przy okazji robots.txt na tyle często, że lepiej odpowiedzieć od razu.
Od czerwca 2026 nie trzeba już zgadywać. Ahrefs sprawdził 137 210 domen z ruchem i policzył nie to, ile z nich ma ten plik, tylko coś znacznie ciekawszego: ile razy ktokolwiek go pobrał.
- 97 procent plików llms.txt nie dostało ani jednego zapytania przez cały miesiąc pomiaru.
- Z zapytań, które w ogóle padły, 96 procent pochodziło od robotów, a nie od ludzi.
- Roboty, o które w tym wszystkim chodzi, czyli te pobierające treść dla ChatuGPT i Perplexity, odpowiadały za 1,1 procent zapytań.
- Autorzy podsumowali to jednym zdaniem: sam Slackbot pobierał pliki llms.txt częściej niż PerplexityBot.
Stanowisko Google jest równie jednoznaczne. John Mueller zapytany o llms.txt odpowiedział, że na razie jest to czysta spekulacja, i dodał uwagę, że plik istnieje od lat, a żaden system AI z niego nie korzysta. Wcześniej, zapytany wprost, czy obecność takiego pliku u Google oznacza poparcie dla standardu, odpowiedział krótko: nie.
Zainteresowanie tematem ma przy tym wyraźne źródło. Fraza „llms txt" ma w polskim Google mierzalny wolumen, około 880 wyszukań miesięcznie, a co najmniej sześć polskich agencji opublikowało o tym pliku poradniki. Zapytań jest więc sporo, tylko że pochodzą one w większości od osób zajmujących się stronami zawodowo, a nie od firm, które szukają rozwiązania swojego problemu. Popyt na wiedzę o llms.txt jest realny. Dowodów na to, że sam plik cokolwiek daje, nadal nie ma.
Wniosek praktyczny: plik nie szkodzi i można go dodać, ale nie ma dowodów, że wpływa na cytowania. Asystenci opierają się na regułach z robots.txt, bo ich dostawcy zadeklarowali, że będą je respektować, i w praktyce to robią. Jeśli miałoby się zrobić tylko jedną rzecz, lepiej sprawdzić robots.txt niż dodać llms.txt.
Najczęstsze pytania
Gdzie znaleźć plik robots.txt swojej strony?
Pod adresem domeny zakończonym ukośnikiem i nazwą pliku. Wystarczy wpisać go w przeglądarce. Jeśli otwiera się pusta strona albo komunikat o błędzie, plik nie istnieje lub serwer go nie udostępnia.
Czy w robots.txt liczy się kolejność reguł?
Nie. Liczy się nazwa robota i długość ścieżki. Robot czyta wyłącznie ten blok User-agent, którego nazwa pasuje do niego najbardziej szczegółowo, a pozostałe pomija w całości. W obrębie tego bloku przy sprzecznych regułach wygrywa ta o dłuższym zapisie ścieżki, a przy równej długości mniej restrykcyjna.
Czy robots.txt ukrywa stronę przed Google?
Nie. Blokuje pobranie adresu, ale zablokowana strona może i tak pojawić się w wynikach, jeśli prowadzą do niej linki. Do usunięcia z wyników służy znacznik noindex, który wymaga, żeby robot mógł stronę odczytać.
Czy trzeba mieć plik robots.txt?
Nie jest obowiązkowy. Strona bez niego działa poprawnie, a roboty odwiedzają wszystko, do czego mają dostęp. Gorzej, gdy plik jest, ale zwraca błąd serwera, bo wtedy Google na kilkanaście godzin wstrzymuje przechodzenie całej strony.
Czy blokować roboty asystentów AI?
To zależy, które. Blokada robotów zbierających dane do uczenia modeli nie wyklucza firmy z odpowiedzi. Blokada robotów pobierających treść na bieżąco wyklucza, bo asystent nie ma wtedy skąd wziąć informacji o stronie.
Czy blokada Google-Extended wyłącza firmę z odpowiedzi generowanych przez Google?
Nie. Google-Extended dotyczy trenowania modeli Gemini i ugruntowywania ich odpowiedzi, a Google wprost pisze, że nie wpływa na obecność w wynikach wyszukiwania ani na pozycje. Ile treści trafia do odpowiedzi generowanej w wyszukiwarce, ograniczają znaczniki nosnippet i max-snippet w kodzie strony.
Co wpisać w robots.txt na WordPressie?
Blokadę katalogu administracyjnego z wyjątkiem pliku obsługującego zapytania i ewentualnie blokadę wyników wyszukiwarki wewnętrznej. Linię z mapą witryny WordPress od wersji 5.5 dopisuje sam, więc najpierw warto sprawdzić, czy już jej tam nie ma. Nie blokować katalogów motywu, bo robot nie zobaczy wtedy strony tak jak użytkownik.
Czy plik llms.txt jest potrzebny?
Nie ma dowodów, że wpływa na cytowania. W badaniu Ahrefsa na 137 tysiącach domen 97 procent plików llms.txt nie dostało przez miesiąc ani jednego zapytania, a roboty pobierające treść dla asystentów odpowiadały za 1,1 procent tych, które padły. Nie szkodzi, ale robots.txt jest ważniejszy, bo to jego reguły asystenci faktycznie stosują.
Autor
Paweł Kunaszyk, w SEO od 2005 roku, firmę prowadzę od 2008. Dostęp robotów sprawdzamy cyklicznie, osobno dla każdego z szesnastu robotów, bo blokada jednego znaczy co innego niż blokada drugiego. Zasady działania pliku podane są za dokumentacją Google dla webmasterów, dane o adopcji llms.txt za badaniem Ahrefsa z czerwca 2026, a dane o blokowaniu robotów AI w Polsce za badaniem Reuters Institute.
Zapytanie o ofertę
Ten wpis opisuje ogólną metodę. Przy konkretnej stronie odpowiedź może być dużo bardziej precyzyjna - wystarczy adres i kilka zdań o sytuacji. Odpowiadamy w jeden dzień roboczy, zwykle szybciej.
