Responsywne projektowanie stron internetowych

TL;DR — Responsive design oznacza jedną stronę internetową, która dopasowuje się do ekranu, na którym jest wyświetlana — telefonu, tabletu czy laptopa — używając tej samej strony i tego samego adresu dla wszystkich. To rozwiązanie zalecane przez Google, ponieważ jest najprostsze do zbudowania i utrzymania. Wymaga jednej małej linijki kodu (znacznika viewport meta), aby działać, i nie sprawia magicznie, że zajmujesz wyższą pozycję.

Czym jest responsive design

Responsywna strona internetowa to jedna strona, która dostosowuje swój układ do rozmiaru ekranu. Ta sama strona, ten sam adres internetowy, niezależnie od tego, czy otwierasz ją na telefonie, tablecie, czy dużym monitorze desktopowym — kolumny się przestawiają, obrazy zmieniają rozmiar, menu się zwija, więc zawsze wygląda dobrze.

Alternatywne, starsze podejścia dzielą Twoją witrynę na dwie części: osobną mobilną stronę pod własnym adresem (np. m.example.com) lub serwer, który po cichu podaje telefonom oraz komputerom różne strony z tego samego adresu. Responsive design pomija to wszystko. Jest tylko jedna wersja wszystkiego.

Dlaczego to zalecane rozwiązanie

Google zaleca responsive design, a jego powód jest odświeżająco prosty: to najłatwiejsze do zbudowania i utrzymania. Ponieważ jest tylko jedna strona, masz tylko jedną rzecz do utrzymania w poprawności. Nic nie może się rozjechać między “wersją mobilną” a “wersją desktopową”, ponieważ nie ma dwóch wersji.

To ma teraz większe znaczenie niż kiedyś, ponieważ Google czyta teraz mobilną wersję Twojej strony, aby zdecydować o Twojej pozycji (to indeksowanie mobile-first). Dzięki responsywnej stronie Twoja wersja mobilna i wersja desktopowa to to samo — więc nie ma czego zepsuć.

Ta jedna linijka, która sprawia, że to działa

Responsive design nie działa samodzielnie. Potrzebujesz tego w <head> swojej strony:

<meta name="viewport" content="width=device-width, initial-scale=1">

Bez tego telefony udają monitory desktopowe i zmniejszają całą stronę do tekstu tak małego, że nieczytelnego — a responsywny układ nigdy się nie uruchamia. To nie jest opcjonalne; to przełącznik, który włącza responsive design. (Jest całe szczegółowe omówienie znacznika viewport meta, jeśli chcesz poznać szczegóły.)

Rzecz, którą ludzie rozumieją źle

Responsive design to nie zastrzyk na pozycję w rankingu. Google wprost powiedziało, że nie rankuje responsywnych stron wyżej niż stron zbudowanych w inny sposób. Korzyść polega na tym, że jest to prostsze i trudniejsze do zepsucia — a nie na tym, że zdobywasz pozycje.

A “wygląda dobrze na moim telefonie” to nie to samo co “jest responsywne”. Responsywne oznacza, że układ naprawdę dostosowuje się za pomocą CSS na jednej stronie — a nie że przypadkiem da się go przeczytać.

Chcesz pełną wersję — dokładne cytaty z Google, porównanie z dynamicznym serwowaniem i osobnymi URL-ami, dlaczego znacznik viewport jest twardym wymogiem i dlaczego responsywna strona może być nadal wolna? Przełącz się na zakładkę Zaawansowane.

TL;DR — Responsywne projektowanie serwuje ten sam HTML pod tym samym adresem URL każdemu urządzeniu i używa zapytań o media CSS, aby dostosować układ do viewportu. Google opisuje je jako “the easiest design pattern to implement and maintain” (tłumaczenie) „najłatwiejszy wzorzec projektowy do wdrożenia i utrzymania”, ale wyraźnie nie rankuje go wyżej niż dynamiczne serwowanie czy osobne URL-e. Jego prawdziwa przewaga jest operacyjna: jeden URL, jeden zestaw HTML, więc parytet treści jest automatyczny, a oficjalna lista kontrolna indeksowania mobile-first Google dotyczy dynamicznego serwowania i osobnych konfiguracji adresów URL. Wymaga poprawnego znacznika viewport meta, aby działać — bez niego telefony zakładają viewport o szerokości desktopowej (980px iOS / 800px stary Android), a Twoje zapytania o media nigdy się nie uruchamiają. Kontrast: dynamiczne serwowanie (ten sam URL, inny HTML przez Vary: User-Agent) i osobne URL-e (m-dot). Responsywność kontroluje układ, nie prędkość — responsywna strona może nadal nie spełniać wymagań Core Web Vitals.

Definicja, precyzyjnie

Słowa Google: responsywne projektowanie “serwuje ten sam kod HTML pod tym samym adresem URL niezależnie od urządzenia użytkownika (na przykład komputera stacjonarnego, tabletu, telefonu komórkowego, przeglądarki niewizualnej), ale może wyświetlać treść inaczej w zależności od rozmiaru ekranu.” To zdanie zawiera całą ideę:

• Ten sam HTML — jeden plik znaczników, a nie wersja zależna od urządzenia.
• Ten sam URL — bez przekierowania do m.example.com, bez rozgałęzienia na podstawie user-agenta.
• Wyświetlany inaczej w zależności od rozmiaru ekranu — za pomocą zapytań o media w CSS.

To jest linia, która oddziela go od dwóch innych konfiguracji udokumentowanych przez Google. Dynamiczne serwowanie “używa tego samego adresu URL niezależnie od urządzenia… opiera się na wykrywaniu user-agenta i nagłówku odpowiedzi HTTP Vary: user-agent, aby serwować różne wersje HTML różnym urządzeniom.” Osobne adresy URL “serwują różny HTML każdemu urządzeniu, na osobnych adresach URL,” przekierowując użytkowników do wersji odpowiedniej dla urządzenia. Responsywne projektowanie jest jedyną z tych trzech konfiguracji z pojedynczym źródłem HTML.

Dlaczego Google to zaleca — prostota, a nie przewaga w rankingu

Google jest bezpośrednie: “zaleca responsywne projektowanie stron internetowych, ponieważ jest to najłatwiejszy wzorzec projektowy do wdrożenia i utrzymania.” Zwróć uwagę, czym ten powód jest, a czym nie jest — to argument operacyjny (jeden kod, mniej ruchomych części), a nie argument rankingowy.

Najbardziej przydatna — i najbardziej niedoceniana — linia w dokumencie Google o najlepszych praktykach mobile-first to uwaga o zakresie: “The contents of this guide only apply to dynamic serving and separate URL configurations. In case of responsive design, the content and the metadata are the same on the mobile and desktop version of the pages.” (tłumaczenie) „Treść tego przewodnika dotyczy tylko dynamicznego serwowania i konfiguracji z osobnymi adresami URL. W przypadku responsywnego projektowania treść i metadane są takie same w mobilnej i desktopowej wersji stron.” Przeczytaj to jeszcze raz. Google mówi ci, że większość jego długiej listy kontrolnej mobile-first — dopasowywanie danych strukturalnych między wersjami, dopasowywanie tagów meta robots, dopasowywanie tekstu alternatywnego, ustawianie nagłówków Vary, konfigurowanie adnotacji rel=alternate/canonical — po prostu nie dotyczy ciebie, jeśli używasz responsywnego projektowania, ponieważ istnieje tylko jedna wersja, którą trzeba dopracować. To najsilniejszy praktyczny argument za RWD, a prawie nikt nie ujmuje tego w ten sposób.

Korzyści wtórne wynikają wszystkie z “jednego adresu URL, jednego HTML”:

• Brak ryzyka zduplikowanych treści lub braku parytetu między example.com/page a m.example.com/page — nie ma nic, co mogłoby się rozjechać.
• Brak kruchości Vary: User-Agent, którą niesie dynamiczne serwowanie (pamięć podręczna, która ignoruje nagłówek, może serwować zły HTML złemu urządzeniu — lub Googlebotowi).
• Brak łańcuchów przekierowań lub dzielenia link equity między adresami URL dla komputerów i urządzeń mobilnych.
• Brak mechanizmu adnotacji (rel=alternate na komputerze, rel=canonical na urządzeniu mobilnym) do utrzymania i do popełnienia w nim błędu.

To jest dokładnie powód, dla którego w moim przewodniku Ahrefs na temat indeksowania mobile-first “użyj responsywnego projektowania” jest pierwszą z dziesięciu wskazówek dotyczących budowy przyjaznej dla urządzeń mobilnych witryny — eliminuje całe kategorie problemów, zanim się zaczną.

Czy responsywne projektowanie bezpośrednio poprawia rankingi? Nie.

To mit, który warto obalić na początku. Zineb Ait Bahajji z Google ujęła to jasno: Google nie plasuje witryn z responsywnym projektowaniem wyżej niż witryn używających innych konfiguracji (osobnych witryn mobilnych lub dynamicznego serwowania). Google nadal preferuje RWD — ponieważ jest łatwiejsze w utrzymaniu, przyjazne dla przyszłości i widzą mniej błędów konfiguracji z nim — ale “mniej błędów” to nie to samo co “bonus rankingowy.” Dobrze wdrożone dynamiczne serwowanie lub witryna m-dot, która utrzymuje parytet, może zajmować identyczną pozycję; ryzyko z nimi polega na tym, że dryfują, a dryf to coś, co ci szkodzi.

Więc uczciwe ujęcie: responsywne projektowanie nie wygrywa dla ciebie rankingów. Chroni cię przed utratą ich z powodu błędu parytetu i oszczędza czas na utrzymanie. Oba są warte dużo — żadne nie jest wzmocnieniem algorytmu.

Jak to działa: tag meta viewport to warunek wstępny, a nie dodatek

Większość przewodników wymienia meta tag viewport jako jeden z wielu punktów wśród wskazówek CSS. To nie jest wskazówka — to rzecz, która sprawia, że responsywny design w ogóle działa. Wpis Google z 2012 roku na Search Central, wyjaśniający, dlaczego samo Google przeszło na responsywność, jest w tej kwestii bezpośredni: domyślnie przeglądarki smartfonowe udają wysokorozdzielcze przeglądarki desktopowe i układają stronę jak na monitorze; domyślny viewport ma 800px w starszym Androidzie i 980px w iOS, niezależnie od fizycznej liczby pikseli.

To jest tryb awarii: bez tagu viewport telefon renderuje Twoją stronę na płótnie o szerokości 980px, a następnie zmniejsza całość, aby się zmieściła — mały tekst, „tryb przeglądu” i Twoja starannie napisana media query max-width: 479px nigdy się nie uruchamia, ponieważ przeglądarka myśli, że ma 980px szerokości. Rozwiązaniem jest jedna linia: użyj opisanego wyżej elementu meta viewport, aby przeglądarka renderowała stronę w czytelnej skali. Ustawienie width=device-width oznacza również, że układ aktualizuje się, gdy użytkownik obraca urządzenie, co pozwala media queries reagować na orientację. Głębsze mechanizmy — initial-scale, pułapki dostępności user-scalable/maximum-scale — znajdują się w dedykowanym artykule o meta tagu viewport.

Jak to działa: media queries CSS

Przy poprawnie ustawionym viewporcie układ dostosowuje się za pomocą media queries CSS — reguł, które stosują się tylko przy określonych szerokościach viewportu:

<style>
/* Base styles apply everywhere */
@media screen and (max-width: 479px) {
  /* Portrait smartphones: stack columns, hide the sidebar, grow tap targets */
}
@media screen and (min-width: 480px) and (max-width: 1024px) {
  /* Tablets */
}
</style>

Traktuj powyższe wartości pikseli jako ilustracyjne, a nie listę do skopiowania. Trwała praktyka — powtórzona w referencji media queries MDN i kursie responsywnego designu web.dev — to traktowanie breakpointów jako decyzji projektowej, a nie listy urządzeń: ustaw je tam, gdzie Twoje własne treści faktycznie się łamią (nawigacja źle się zawija, kolumny stają się zbyt wąskie, tekst ma zbyt krótkie linie) i testuj również zakresy między breakpointami, nie tylko garść nazwanych rozmiarów ekranów. Szerokości viewportów urządzeń zmieniają się co cykl produktowy; breakpointy oparte na treści nie wymagają aktualizacji, gdy to się dzieje.

Wpis Google z 2012 roku wskazał również dyscyplinę CSS, która zapobiega łamaniu się responsywnego układu: “Instead of specifying width for container elements, we started using max-width instead. In place of height we used min-height, so larger fonts or multi-line text don’t break the container’s boundaries.” (tłumaczenie) «Zamiast określać width dla elementów kontenerowych, zaczęliśmy używać max-width. Zamiast height używaliśmy min-height, aby większe czcionki lub tekst wieloliniowy nie łamały granic kontenera.» Ich trzy zasady przewodnie były równie proste: strony powinny być czytelnie renderowane przy każdej rozdzielczości, jeden zestaw treści powinien być widoczny na każdym urządzeniu, a Ty powinieneś “never show a horizontal scrollbar, whatever the window size.” (tłumaczenie) «nigdy nie pokazywać poziomego paska przewijania, niezależnie od rozmiaru okna.» Nowoczesne udoskonalenia (clamp() dla płynnej typografii, zapytania o kontener, srcset/<picture> dla obrazów dopasowanych do urządzenia) leżą na tym fundamencie — nie są wymagane, aby być „naprawdę” responsywnym. Jeśli chodzi o głębię implementacji wykraczającą poza ramy SEO, własny kurs Learn Responsive Design od web.dev Google jest miejscem, do którego warto się udać.

Responsywny design vs. dynamiczne serwowanie vs. osobne URL-e

Trzy konfiguracje udokumentowane przez Google, obok siebie:

Dynamiczne serwowanie nadal ma sens w niektórych przypadkach (np. przy radykalnie różnych doświadczeniach na urządzeniach, których pojedynczy szablon nie może rozsądnie wyrazić); osobne adresy URL są obecnie w większości przestarzałe. Jeśli korzystasz z jednego z tych rozwiązań, pełne szczegółowe omówienia — w tym mechanika nagłówka Vary dla dynamicznego serwowania — znajdują się w artykule o dynamicznym serwowaniu. Ale przy budowie od zera, responsywność jest domyślną odpowiedzią, a ciężar dowodu spoczywa na wyborze czegokolwiek innego.

Podejście Binga: kryteria, nie architektura

Bing zgadza się z wynikiem, ale ujmuje to inaczej. Nie promuje responsywnego projektowania po nazwie tak jak Google; jego test przyjazności mobilnej ocenia mierzalne kryteria — konfigurację viewportu i kontroli powiększenia, szerokość treści strony, czytelność tekstu, odstępy między elementami dotykowymi oraz użycie niekompatybilnych wtyczek. Jego zasada brzmi: “the content width should not exceed the screen width” (tłumaczenie) „szerokość treści nie powinna przekraczać szerokości ekranu”, a przepełnienie oznacza komunikatem “Page content does not fit device width.” (tłumaczenie) „Treść strony nie mieści się w szerokości urządzenia”. Można więc bezpiecznie stwierdzić, że zarówno Bing, jak i Google nagradzają przyjazne dla urządzeń mobilnych renderowanie; tylko przypisz język zalecanej konfiguracji konkretnie do Google.

Responsywne projektowanie a indeksowanie mobile-first (po lipcu 2024)

Indeksowanie mobile-first jest zakończone — Google dokończyło wdrażanie i obecnie domyślnie używa wersji Twojej strony przeszukiwanej przez mobilnego crawlera do indeksowania i rankingu. Prawie każdy przewodnik wciąż pisze o responsywnym projektowaniu jako o przyszłym kroku “przygotuj się na indeksowanie mobile-first”. To ujęcie jest nieaktualne. Wdrożenie jest zakończone, a dla już responsywnej strony nie zmienia niczego — Twoje treści i metadane są już identyczne na mobile i desktopie, ponieważ istnieje jedna wersja. To nie przypadek; to cały sens. Artykuł o indeksowaniu mobile-first na tej stronie szczegółowo omawia harmonogram i zasady parytetu.

Responsywność ≠ automatyczna szybkość

Największa pułapka. Responsywne projektowanie kontroluje układ, a nie wydajność. Responsywna strona może nadal wysyłać 3 MB obraz hero na desktopie, który telefony po prostu skalowują w CSS, lub wysyłać desktopowy JavaScript na urządzenie mobilne — i poważnie oblać LCP lub CLS. “Responsywność” to nie przepustka do Core Web Vitals. Prawdziwa optymalizacja oznacza serwowanie odpowiednio dobranych zasobów dla każdego breakpointu (do tego służą srcset/<picture> i responsywne obrazy), a nie tylko pozwalanie CSS na zmniejszanie zbyt dużych. Napraw wydajność osobno — zobacz treści o Core Web Vitals i materiały o responsywnych obrazach, aby dowiedzieć się jak.

Wydajność to nie jedyne założenie, które nie musi się automatycznie spełniać. Jedna baza kodu nie gwarantuje również identycznego renderowania, dostępności ani prezentacji w wynikach wyszukiwania — przeglądarki i urządzenia wciąż różnią się na tyle w obsłudze CSS, czcionek i układu zależnego od JavaScriptu, że testowanie na różnych urządzeniach i przeglądarkach pozostaje częścią pracy, tak samo jak przy każdej innej konfiguracji. “Responsywność” opisuje architekturę, a nie zweryfikowany wynik; testuj ją tak, jak testowałbyś wszystko inne.

Trochę historii

Warto poświęcić temu jeden akapit, ponieważ zmienia to perspektywę na całą “najlepszą praktykę”. Google nie zaleciło responsywnego projektowania najpierw, a potem go nie przyjęło — najpierw przeszło na responsywność we własnych właściwościach, z powodów inżynieryjnych, a zalecenie pojawiło się później. Jak wyjaśnia wpis z 2012 roku, Google “faced a stark choice between creating mobile specific websites, or adapting existing sites… Creating two sites would allow us to better target specific hardware, but maintaining a single shared site preserves a canonical URL, avoiding any complicated redirects, and simplifies the sharing of web addresses.” (tłumaczenie) «stanęło przed ostrym wyborem między tworzeniem stron mobilnych a dostosowaniem istniejących… Stworzenie dwóch stron pozwoliłoby nam lepiej celować w konkretny sprzęt, ale utrzymanie jednej wspólnej strony zachowuje kanoniczny URL, unikając skomplikowanych przekierowań i upraszcza udostępnianie adresów internetowych.» Zachowanie kanonicznego URL, brak skomplikowanych przekierowań, prostsze udostępnianie — to były powody zanim ktokolwiek nazwał to najlepszą praktyką SEO, i nadal są to powody.

Gdzie to się mieści w szerszym obrazie: responsywny design to jeden z elementów szerszej historii mobilnego SEO, obok użyteczności mobilnej, natrętnych interstitialów, historii AMP oraz listy kontrolnej mobilnego SEO, która je łączy. Ten artykuł odpowiada na pytanie „jak powinienem serwować treści na urządzenia mobilne?”; pozostałe omawiają resztę.

Podsumowanie AI

Skrócona wersja wersji zaawansowanej:

• Responsywny design = ten sam HTML, ten sam URL, zapytania o media CSS dopasowują układ do viewportu. To jedna z trzech udokumentowanych konfiguracji mobilnych Google, obok dynamicznego serwowania i osobnych URL-i.
• Google go zaleca jako “the easiest design pattern to implement and maintain” (tłumaczenie) „najłatwiejszy wzorzec projektowy do wdrożenia i utrzymania” — ale nie jest to wzmocnienie pozycji w rankingu. Google (Zineb Ait Bahajji) stwierdziło, że nie rankuje stron responsywnych wyżej niż pozostałe konfiguracje.
• Prawdziwa przewaga ma charakter operacyjny. Nota zakresowa Google: “only applies to dynamic serving and separate URL configurations… In case of responsive design, the content and the metadata are the same” (tłumaczenie) „dotyczy tylko dynamicznego serwowania i konfiguracji z osobnymi adresami URL… W przypadku responsywnego projektowania treść i metadane są takie same” — więc parytet, nagłówki Vary i adnotacje alternate/canonical w większości nie mają zastosowania.
• Znacznik viewport to twardy warunek wstępny, a nie wskazówka: bez <meta name="viewport" content="width=device-width, initial-scale=1"> telefony zakładają viewport o szerokości desktopowej (980px iOS / 800px stary Android) i zapytania o media nigdy nie są wyzwalane.
• Kontrast: dynamiczne serwowanie (ten sam URL, inny HTML przez Vary: User-Agent) i osobne URL-e (m-dot, wymaga rel=alternate/canonical). Obie konfiguracje są bardziej ryzykowne, ponieważ dwie wersje mogą się rozjechać.
• Bing nagradza przyjazność mobilną za pomocą testowalnych kryteriów (viewport, szerokość treści, czytelność, odstępy między elementami dotykowymi), zamiast popierać RWD z nazwy.
• Indeksowanie mobile-first jest zakończone; dla już responsywnej strony nic się nie zmienia, ponieważ treść i metadane są już identyczne.
• Responsywny ≠ szybki. Kontroluje układ, a nie wydajność — responsywna strona może nadal nie spełniać wymagań Core Web Vitals, jeśli zasoby i JS nie są zoptymalizowane pod kątem każdego breakpointu.
• Breakpointy to decyzja dotycząca układu, a nie lista urządzeń. Ustaw je tam, gdzie treść faktycznie się łamie, i testuj zakresy między nimi, a nie tylko kilka nazwanych rozmiarów ekranu.
• Responsywny ≠ identyczny wszędzie. Jeden kod nie gwarantuje identycznego renderowania, dostępności ani prezentacji w różnych przeglądarkach i na różnych urządzeniach — testowanie na różnych urządzeniach nadal ma znaczenie.

Oficjalna dokumentacja

Dokumentacja źródłowa od wyszukiwarek.

Google

• Dobre praktyki indeksowania mobile-first — dokument kanoniczny: definicja responsywnego designu, trzy konfiguracje, zalecenie „najłatwiejszy do wdrożenia i utrzymania” oraz nota zakresowa, że większość listy kontrolnej nie dotyczy stron responsywnych. Zacznij tutaj.
• Responsywne projektowanie — wykorzystanie możliwości zapytań o media (2012) — Google wyjaśnia, dlaczego samo przeszło na responsywność: wymóg znacznika viewport, problem domyślnego viewportu 980px/800px oraz dyscyplina CSS max-width/min-height.
• Nauka responsywnego projektowania (web.dev) — kurs deweloperski należący do Google po stronie implementacji (zapytania o media, responsywne obrazy, tryb ciemny). Stary URL developers.google.com/search/mobile-sites/mobile-seo/responsive-design przekierowuje teraz tutaj.
• Jak rozumieć jakość strony w Google — gdzie przyjazność mobilna i Core Web Vitals pasują jako sygnały (istotne dla punktu „responsywny ≠ szybki”).

Bing / Microsoft

• Wytyczne Bing dla webmasterów — ogólne wytyczne Bing; przyjazność dla urządzeń mobilnych jest traktowana jako kryteria testowalne, a nie nazwana preferowana architektura.
• Ogłoszenie narzędzia Bing do testowania przyjazności mobilnej (listopad 2015) — pięć kryteriów sprawdzanych przez Bing: konfiguracja viewport/zoom, szerokość treści, czytelność, odstępy między elementami dotykowymi i niekompatybilne wtyczki.

Cytaty ze źródła

Oficjalne wypowiedzi Google i Bing. Każdy link to link bezpośredni, który przenosi do cytowanego fragmentu na stronie źródłowej.

Google — definicja i zalecenie

• “Serves the same HTML code on the same URL regardless of the users’ device (for example, desktop, tablet, mobile, non-visual browser), but can display the content differently based on the screen size.” (tłumaczenie) „Serwuje ten sam kod HTML pod tym samym adresem URL niezależnie od urządzenia użytkownika (np. komputer stacjonarny, tablet, telefon, przeglądarka niewizualna), ale może wyświetlać treść inaczej w zależności od rozmiaru ekranu.” — dokumentacja Google Search Central. Przejdź do cytatu
• “Google recommends Responsive Web Design because it’s the easiest design pattern to implement and maintain.” (tłumaczenie) „Google zaleca Responsive Web Design, ponieważ jest to najłatwiejszy wzorzec projektowy do wdrożenia i utrzymania.” Przejdź do cytatu
• “The contents of this guide only apply to dynamic serving and separate URL configurations. In case of responsive design, the content and the metadata are the same on the mobile and desktop version of the pages.” (tłumaczenie) „Treść tego przewodnika dotyczy tylko dynamicznego serwowania i konfiguracji z oddzielnymi adresami URL. W przypadku responsywnego projektu treść i metadane są takie same w wersji mobilnej i desktopowej stron.” Przejdź do cytatu

Google — dynamiczne serwowanie i oddzielne adresy URL (dla porównania)

• “Uses the same URL regardless of device. This configuration relies on user-agent sniffing and the Vary: user-agent HTTP response header to serve a different version of the HTML to different devices.” (tłumaczenie) „Używa tego samego adresu URL niezależnie od urządzenia. Ta konfiguracja opiera się na wykrywaniu user-agenta i nagłówku odpowiedzi HTTP Vary: user-agent, aby serwować różne wersje HTML różnym urządzeniom.” — dynamiczne serwowanie. Przejdź do cytatu
• “Serves different HTML to each device, and on separate URLs. Like dynamic serving, this configuration relies on the user-agent and Vary HTTP headers to redirect users to the device-appropriate version of the site.” (tłumaczenie) „Serwuje różny HTML dla każdego urządzenia i na oddzielnych adresach URL. Podobnie jak dynamiczne serwowanie, ta konfiguracja opiera się na nagłówkach HTTP user-agent i Vary, aby przekierowywać użytkowników do wersji strony odpowiedniej dla urządzenia.” — osobne adresy URL. Przejdź do cytatu

Google — dlaczego tag viewport jest wymagany (blog Search Central z 2012 r.)

• “By default, smartphone browsers pretend to be high-resolution desktop browsers, and lay out a page as if you were viewing it on a desktop monitor… The default viewport width for the default Android browser is 800px, and 980px for iOS, regardless of the number of actual physical pixels on the screen.” (tłumaczenie) «Domyślnie przeglądarki smartfonowe udają, że są przeglądarkami desktopowymi o wysokiej rozdzielczości, i układają stronę tak, jakbyś oglądał ją na monitorze desktopowym… Domyślna szerokość viewportu dla domyślnej przeglądarki Android to 800px, a dla iOS 980px, niezależnie od liczby rzeczywistych pikseli fizycznych na ekranie.» Przejdź do cytatu
• “In order to trigger the browser to render your page at a more readable scale, you need to use the viewport meta element.” (tłumaczenie) «Aby skłonić przeglądarkę do wyrenderowania strony w bardziej czytelnej skali, musisz użyć elementu meta viewport.» Przejdź do cytatu
• “We faced a stark choice between creating mobile specific websites, or adapting existing sites and new launches to render well on both desktop and mobile… maintaining a single shared site preserves a canonical URL, avoiding any complicated redirects, and simplifies the sharing of web addresses.” (tłumaczenie) «Stanęliśmy przed trudnym wyborem między tworzeniem stron dedykowanych na urządzenia mobilne a dostosowaniem istniejących witryn i nowych wdrożeń tak, aby dobrze renderowały się zarówno na desktopie, jak i na urządzeniach mobilnych… utrzymanie jednej wspólnej witryny zachowuje kanoniczny URL, unika skomplikowanych przekierowań i upraszcza udostępnianie adresów internetowych.» Przejdź do cytatu
• “Instead of specifying width for container elements, we started using max-width instead. In place of height we used min-height, so larger fonts or multi-line text don’t break the container’s boundaries.” (tłumaczenie) «Zamiast określać width dla elementów kontenera, zaczęliśmy używać max-width. Zamiast height używaliśmy min-height, aby większe czcionki lub tekst wieloliniowy nie przekraczały granic kontenera.» Przejdź do cytatu

Google — brak wzmocnienia pozycji (Zineb Ait Bahajji, za relacją Search Engine Roundtable)

• Google “nie rankuje witryn responsywnych wyżej niż witryn używających innych konfiguracji (osobna witryna mobilna lub dynamiczne serwowanie).” Podany przez Google powód, dla którego nadal je preferuje: “łatwiej je utrzymać, są przyszłościowe i widzimy mniej błędów konfiguracji w RWD.” (tłumaczenie) «nie rankuje witryn responsywnych wyżej niż witryn używających innych konfiguracji (osobna witryna mobilna lub dynamiczne serwowanie).» oraz «łatwiej je utrzymać, są przyszłościowe i widzimy mniej błędów konfiguracji w RWD.» Przeczytaj relację

Google (listopad 2016), przekazane za pośrednictwem mojej prezentacji SMX Advanced 2017

• “If you have a responsive site or a dynamic serving site where the primary content and markup is equivalent across mobile and desktop, you shouldn’t have to change anything.” (tłumaczenie) «Jeśli masz witrynę responsywną lub witrynę z dynamicznym serwowaniem, gdzie główna treść i znaczniki są równoważne na urządzeniach mobilnych i desktopie, nie musisz niczego zmieniać.» Zobacz prezentację

Jakiej konfiguracji mobilnej powinienem użyć?

Dla prawie każdej nowej strony odpowiedź brzmi: responsywna — ale istnieją uzasadnione powody, dla których pozostałe dwie wciąż istnieją. Kliknij, aby przejść dalej.

Responsywne projektowanie — ściąga

Definicja: ten sam HTML, ten sam URL, zapytania medialne CSS dostosowują układ do viewportu. Jedna wersja wszystkiego.

Wymagany tag (bez niego nic nie działa):

<meta name="viewport" content="width=device-width, initial-scale=1">

Porównanie konfiguracji

Dlaczego responsywność, w jednym zdaniu każdy powód

• Jeden URL, jeden HTML → parytet treści jest automatyczny.
• Lista kontrolna Google “dotyczy tylko dynamicznego serwowania i oddzielnych konfiguracji URL.”
• Brak ryzyka nagłówka Vary, brak łańcuchów przekierowań, brak adnotacji alternate/canonical.
• Najłatwiejsze do wdrożenia i utrzymania — podany przez Google powód.

Czym to NIE jest

• Nie jest to wzmocnienie pozycji (Google: nie ocenia responsywności wyżej niż innych konfiguracji).
• Nie jest automatycznie szybkie — układ ≠ wydajność; CWV nadal wymaga pracy.
• Nie to samo co “wygląda dobrze na moim telefonie” — to adaptacja sterowana zapytaniami o media.

Tryb awarii viewportu: brak tagu → telefon zakłada viewport 980px (iOS) / 800px (stary Android), zmniejsza stronę, zapytania o media nigdy nie są wyzwalane.

Bing: nagradza przyjazność dla urządzeń mobilnych według testowalnych kryteriów (viewport, szerokość treści, czytelność, odstępy celów dotykowych) — nie popiera “RWD” z nazwy.

Indeksowanie mobile-first: zakończone; dla responsywnej strony niczego nie zmienia — treść/metadane są już identyczne.

Lista kontrolna QA dla responsywnego designu

Uruchom to, aby potwierdzić, że strona jest naprawdę responsywna, a nie tylko “płynny desktop”:

• Tag viewport obecny i poprawny — <meta name="viewport" content="width=device-width, initial-scale=1"> w <head> każdej strony.
• Brak blokowania zoomu — unikaj user-scalable=no / maximum-scale=1 w tagu viewport (regresja dostępności, a Bing może to oznaczyć).
• Ten sam URL, ten sam HTML na różnych urządzeniach — brak rozwidlenia user-agent, brak przekierowania na osobny mobilny URL.
• Brak poziomego przewijania przy typowych szerokościach (360, 390, 414, 768, 1024, 1280).
• Zapytania o media faktycznie działają — układ naprawdę się restrukturyzuje w punktach przerwania, a nie tylko się zmniejsza.
• Cele dotykowe wystarczająco duże i rozmieszczone (~48px) na małych punktach przerwania.
• Czytelny tekst bez zoomowania (~16px jako podstawa).
• Obrazy skalowane per punkt przerwania — używając srcset/<picture>, a nie ogromnego obrazu desktopowego skalowanego w CSS.
• CSS/JS nie zablokowane w robots.txt — Googlebot musi renderować responsywny układ.
• Mobilne Core Web Vitals zaliczone — LCP < 2,5 s, INP < 200ms, CLS < 0,1 na urządzeniach mobilnych (responsywność ≠ szybkość; sprawdź osobno).
• Brak treści ukrytej przed urządzeniami mobilnymi przez display:none, którą faktycznie chcesz indeksować.
• Wyrenderowany mobilny HTML sprawdzony w URL Inspection w Search Console.
• Sprawdzone na prawdziwych przeglądarkach/urządzeniach, nie tylko w zmienionym rozmiarze okna desktopowego — jeden kod nie gwarantuje identycznego renderowania wszędzie.

Antywzorce responsywnego designu

Błędy, które zamieniają “jesteśmy responsywni” w problem:

• Brak meta tagu viewport (lub błędny). Najczęstsza przyczyna niepowodzeń — media queries są napisane poprawnie, ale nigdy nie są wyzwalane, ponieważ telefon renderuje stronę na płótnie o szerokości 980px. Zawsze sprawdzaj to w pierwszej kolejności.
• user-scalable=no / maximum-scale=1. Blokowanie pinch-zoom to regresja dostępności i może zostać oznaczone przez test mobilny Binga. Nie wyłączaj zoomu, aby “chronić” swój układ.
• “Płynny desktop” udający responsywność. Układ skaluje się proporcjonalnie, ale nigdy się nie restrukturyzuje — trzy kolumny po prostu stają się węższe zamiast układać się jedna pod drugą. Technicznie zmienia rozmiar; nie jest naprawdę responsywny.
• display:none na treści, którą chcesz zaindeksować. Ukrywanie całej sekcji na mobile przez CSS, aby “utrzymać porządek”. Przy mobile-first indexing czytany jest mobilny HTML — jeśli go ukryjesz, ryzykujesz, że nie zostanie zaindeksowany. (Zakładki/akordeony, które zachowują treść w HTML, są w porządku; całkowite jej usunięcie nie jest.)
• Traktowanie “responsywności” jako strategii wydajnościowej. Wysyłanie 3 MB desktopowego hero i pozwalanie CSS-owi go zmniejszać, lub wysyłanie desktopowego JS na telefony. Układ się dostosowuje; payload nie. Tak responsywne strony zawodzą w Core Web Vitals.
• Sięganie po dynamic serving lub m-dot z domyślnie. Wybór architektury z dwiema wersjami, gdy wystarczyłby pojedynczy responsywny szablon — skazywanie się na dryf parytetu, kruchość nagłówka Vary lub utrzymywanie adnotacji, których nie potrzebowałeś.
• Zakładanie, że responsywność przynosi rankingi. Budowanie biznesowego uzasadnienia na wzroście pozycji, który nie istnieje. Sprzedawaj to prostotą i mniejszą liczbą błędów, które są realne.

Sprawdź gotowość strony pod kątem responsywności

Szybkie sposoby na potwierdzenie dwóch rzeczy, które decydują o powodzeniu responsywnego designu: tag viewport oraz to, czy serwer po cichu rozdziela HTML według user-agenta.

1) Czy meta tag viewport jest obecny? (shell)

# Fetch the page and look for the viewport meta tag
curl -s https://example.com/ | grep -io '<meta[^>]*name=["'"'"']viewport["'"'"'][^>]*>'
# Expect something like:
# <meta name="viewport" content="width=device-width, initial-scale=1">

2) Czy serwer serwuje inny HTML na mobile niż na desktop? (shell)

Jeśli liczba bajtów znacząco się różni, możesz mieć dynamic serving — i będziesz potrzebować nagłówka Vary: User-Agent.

UA_MOBILE="Mozilla/5.0 (Linux; Android 14; Pixel 8) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125 Mobile Safari/537.36"
UA_DESKTOP="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125 Safari/537.36"

echo "Mobile bytes:  $(curl -s -A "$UA_MOBILE"  https://example.com/ | wc -c)"
echo "Desktop bytes: $(curl -s -A "$UA_DESKTOP" https://example.com/ | wc -c)"

# If they differ, check for the Vary header (needed for dynamic serving):
curl -sI -A "$UA_MOBILE" https://example.com/ | grep -i '^vary:'
# Expect: Vary: User-Agent  (among any other Vary values)

3) Konsola DevTools — audyt tagu viewport z załadowanej strony

Wklej do konsoli przeglądarki na dowolnej stronie:

(() => {
  const vp = document.querySelector('meta[name="viewport"]');
  if (!vp) return console.warn('❌ No viewport meta tag — responsive layout will not work.');
  const c = vp.getAttribute('content') || '';
  console.log('viewport content:', c);
  console.log(/width=device-width/.test(c) ? '✅ width=device-width set' : '❌ missing width=device-width');
  console.log(/user-scalable=no|maximum-scale=1(\b|,|$)/.test(c)
    ? '⚠️ zoom is blocked — accessibility regression' : '✅ zoom not blocked');
})();

4) Konsola DevTools — wykryj poziome przewijanie (zasada “brak poziomego paska przewijania”)

Uruchom przy wąskim viewporcie (włączony pasek narzędzi urządzenia), aby znaleźć elementy szersze niż ekran:

(() => {
  const w = document.documentElement.clientWidth;
  const bleeding = [...document.querySelectorAll('*')]
    .filter(el => el.getBoundingClientRect().right > w + 1)
    .slice(0, 20);
  console.log(bleeding.length ? '⚠️ Elements overflowing the viewport:' : '✅ No horizontal overflow');
  bleeding.forEach(el => console.log(el.tagName.toLowerCase() + (el.className ? '.' + String(el.className).split(' ').join('.') : ''), el));
})();

5) Bookmarklet — szybkie sprawdzenie viewportu

Zapisz jako zakładkę i kliknij na dowolnej stronie:

javascript:(()=>{const v=document.querySelector('meta[name="viewport"]');alert(v?('viewport: '+v.getAttribute('content')):'No viewport meta tag found — responsive layout will not work.');})();

Sprawdź się: Responsywny design

Pięć szybkich pytań o responsywne projektowanie stron internetowych. Wybierz odpowiedź na każde, a następnie sprawdź.

Zasoby warte Twojego czasu

Moje teksty

• Indeksowanie mobile-first przechodzi wyłącznie na mobile — mój przewodnik na Ahrefs; „użyj responsywnego designu” prowadzi listę dziesięciu wskazówek dotyczących budowy przyjaznej dla mobile strony, a także omawia tło parytetu treści, które czyni responsywność bezpiecznym domyślnym wyborem.
• Przewodnik dla początkujących po technicznym SEO — gdzie konfiguracja mobilna mieści się w szerszym obrazie crawlowania, indeksowania i rankingu.
• Core Web Vitals: czym są i jak je poprawić — strona wydajnościowa, ponieważ sama responsywność nie czyni Cię szybkim.

Moje wystąpienia

• Mobile-First Indexing (SMX Advanced 2017) (SlideShare) — moja prezentacja o konfiguracjach mobilnych; cytuje linię Google z listopada 2016, że responsywne i dynamic-serving strony z równoważną treścią “shouldn’t have to change anything” (tłumaczenie) «nie powinny niczego zmieniać» dla mobile-first indexing. (Stałe zastrzeżenie: to moje rozumienie tych systemów, a nie gwarancja kompletności.)

Z branży

• Dobre praktyki indeksowania mobile-first (Google) — kanoniczny dokument: definicja responsywności, trzy konfiguracje oraz uwaga o zakresie, że większość listy kontrolnej nie dotyczy witryn responsywnych.
• Responsywne projektowanie — wykorzystanie możliwości zapytań o media (Google, 2012) — dlaczego samo Google przeszło na responsywność i skąd wzięło się jego zalecenie dotyczące tagu viewport.
• Nauka responsywnego projektowania (web.dev / Google) — kurs na poziomie implementacji: media queries, responsywne obrazy, preferencje użytkownika.
• Ogłoszenie narzędzia Bing do testowania przyjazności mobilnej (Microsoft Bing) — pięć kryteriów Bing dotyczących przyjazności mobilnej (viewport, szerokość treści, czytelność, odstępy między elementami dotykowymi, wtyczki).
• Google: Responsive Design Is Not A Ranking Signal Boost (Search Engine Roundtable) — relacja Barry’ego Schwartza ze stwierdzenia Zineb Ait Bahajji o „braku wzmocnienia sygnału rankingowego”.
• Is responsive web design enough? (Hint: No) (Search Engine Land) — kontrargument, że RWD nie jest srebrną kulą.
• Top 7 SEO Benefits Of Responsive Web Design (Search Engine Journal) — praktyczne korzyści z pojedynczego adresu URL i parytetu, przedstawione krok po kroku.

Filmy

• Google Search Central (YouTube) — wyjaśnienia Martina Splitta dotyczące przyjazności mobilnej i renderowania, a także seria How Google Search Works, obejmują sposób, w jaki Googlebot obsługuje responsywne układy. Kanał

Dziennik zmian