Protokół HTTPS – co to jest i czym się różni od HTTP?

HTTPS (HyperText Transfer Protocol Secure) to szyfrowana wersja protokołu HTTP, która chroni dane przesyłane między przeglądarką a serwerem za pomocą certyfikatu SSL/TLS. Od sierpnia 2014 roku HTTPS jest oficjalnym czynnikiem rankingowym Google – potwierdził to Google na blogu Search Central. Od lipca 2018 Chrome oznacza wszystkie strony HTTP jako „Not Secure.” Dane z Ahrefs: fraza „certyfikat ssl” generuje w Polsce 2 100 wyszukiwań miesięcznie (KD 21, traffic potential 2 900), „http vs https” – 150/mies. (KD 1).

W 2026 roku brak HTTPS to nie kwestia „nice-to-have” – to blokada. Przeglądarki blokują mixed content, HTTP/2 i HTTP/3 wymagają HTTPS, a strony bez certyfikatu SSL tracą zaufanie użytkowników (wzrost bounce rate). Jak podaje Semrush na blogu: „strony HTTP tracą referrer header przy przejściu na HTTPS – tracisz dane analityczne o źródłach ruchu.”

Semgence – agencja SEO z Warszawy – weryfikuje konfigurację HTTPS jako standardowy element audytu technicznego SEO. Najczęstsze problemy: mixed content (zasoby HTTP na stronie HTTPS), brak 301 redirectów z HTTP na HTTPS, brak HSTS header, wygasłe certyfikaty.

Czym różni się HTTPS od HTTP?

HTTP przesyła dane jako plain text – każdy pośrednik (ISP, Wi-Fi publiczne, router) może odczytać transmisję. HTTPS dodaje warstwę szyfrowania TLS (Transport Layer Security) – dane są zaszyfrowane, a serwer jest uwierzytelniany certyfikatem SSL. Jak opisuje Google w dokumentacji HTTPS: „HTTPS zapewnia trzy warstwy ochrony: szyfrowanie, integralność danych i uwierzytelnianie.”

Wersje TLS: TLS 1.2 (standard w 2026), TLS 1.3 (szybszy, bezpieczniejszy). Starsze wersje (TLS 1.0, 1.1) są deprecated. Sprawdź konfigurację: SSL Labs Server Test – bezpłatny audyt SSL/TLS z oceną A-F.

Jak HTTPS wpływa na SEO?

Cztery wymiary. Ranking signal: Google potwierdził HTTPS jako czynnik rankingowy w oficjalnym wpisie z sierpnia 2014. To „lekki” sygnał – sam HTTPS nie wywinduje strony na pozycję 1, ale brak HTTPS może ją obniżyć. Zaufanie użytkownika: Chrome od lipca 2018 (Google Security Blog) oznacza strony HTTP jako „Not Secure” – wzrost bounce rate. Referral data: jak pisze Semrush: „przy przejściu z HTTPS na HTTP referrer header jest usuwany – tracisz informacje o źródle ruchu.” HTTP/2 i HTTP/3: nowsze protokoły wymagają HTTPS – szybsze ładowanie, multiplexing, server push.

Narzędzia do audytu HTTPS: Screaming Frog (Insecure Content report – wykrywa mixed content), Semrush Site Audit (flaguje HTTP pages, mixed content, certificate issues), Ahrefs Site Audit, Why No Padlock? (wykrywa mixed content per URL).

Jak przeprowadzić migrację z HTTP na HTTPS?

Krok 1: Certyfikat SSL. Let’s Encrypt – darmowy, automatycznie odnawialny (90 dni). Certyfikaty komercyjne: DV (Domain Validation – najszybszy), OV (Organization Validation), EV (Extended Validation – zielony pasek, najwyższe zaufanie). Krok 2: 301 redirecty. Każdy URL HTTP musi 301 na HTTPS. W .htaccess (Apache) lub konfiguracji nginx. Krok 3: Mixed content. Zamień wszystkie zasoby wewnętrzne (img, css, js) z http:// na https:// lub użyj protocol-relative URL (//). Screaming Frog Insecure Content report zidentyfikuje problemy. Krok 4: GSC. Dodaj nową property https:// w Google Search Console. Krok 5: HSTS. Header Strict-Transport-Security wymusza HTTPS po stronie przeglądarki.

Jak podaje Search Engine Land: po migracji monitoruj w GSC Crawl Stats i Coverage report przez 2-4 tygodnie. Chwilowy spadek ruchu (1-2 tygodnie) jest normalny. Więcej: checklista technicznego SEO.

Mixed content – najczęstszy problem po wdrożeniu HTTPS

Z audytów Semgence: mixed content to najczęstszy problem HTTPS, z którym spotykamy się przy migracji i przebudowie serwisów. Mixed content oznacza, że strona HTTPS ładuje część zasobów przez nieszyfrowane HTTP — najczęściej obrazy, pliki CSS i JavaScript. Przeglądarka blokuje takie zasoby (w przypadku „active mixed content” jak JS/CSS) lub wyświetla ostrzeżenie (w przypadku „passive mixed content” jak obrazy). Efekt: strona HTTPS z kłódką, ale obrazy się nie wyświetlają lub style się nie ładują.

Najczęstsze źródła mixed content:

• Obrazy z hardcoded http:// — w treści artykułów, w CMS, w szablonie. Typowe: stare wpisy blogowe z obrazami wstawianymi ręcznie jako <img src="http://domena.pl/img.jpg">
• Pliki CSS/JS z CDN lub wtyczek — np. stara wersja jQuery ładowana z http://cdn.example.com/jquery.min.js. Przeglądarki blokują takie zasoby całkowicie („active mixed content”)
• Fonty zewnętrzne — Google Fonts dawniej serwowane po HTTP (od 2020 tylko HTTPS, ale stare szablony mogą mieć hardcoded http://)
• Iframes i embedy — mapy Google, filmy YouTube, widgety social media ze starymi URL-ami http://
• Linki w CSS — background-image: url(http://...) w plikach .css lub inline styles

Jak opisuje zgred.pl w obszernym poradniku o przebudowie serwisu: przebudowa strony WWW to proces, w którym migracja na HTTPS jest jednym z krytycznych kroków — i mixed content to najczęstsza przyczyna problemów po wdrożeniu. Artykuł krok po kroku opisuje, jak uniknąć utraty pozycji przy przebudowie serwisu, w tym poprawną obsługę redirectów 301, aktualizację sitemap i weryfikację certyfikatu SSL.

Z kolei lexy.com.pl w poradniku o przenoszeniu strony na WordPress podkreśla, że przy migracji CMS (np. z Joomla na WordPress) HTTPS powinien być wdrożony od pierwszego dnia — a mixed content pojawia się szczególnie często, gdy treści importowane ze starego CMS zawierają bezwzględne URL-e z http://. Rozwiązanie: search & replace w bazie danych (np. wtyczka Better Search Replace w WordPress) — zamiana http://domena.pl na https://domena.pl we wszystkich tabelach.

Jak znaleźć i naprawić mixed content?

Narzędzia diagnostyczne: Screaming Frog → Insecure Content report (najskuteczniejsze — skanuje cały serwis, wskazuje konkretne URL-e z mixed content i zasoby HTTP). Why No Padlock? — szybki test pojedynczego URL. Chrome DevTools → Console → filtr „Mixed Content” (widoczne w logach). Semrush Site Audit — flaguje „Pages with insecure content.”

Naprawa krok po kroku: (1) Search & replace w bazie danych: http://twojadomena.pl → https://twojadomena.pl. W WordPress: wtyczka Better Search Replace. (2) Sprawdź pliki szablonu (header.php, footer.php, functions.php) — hardcoded http://. (3) Sprawdź pliki CSS — url(http://...). (4) Sprawdź zewnętrzne skrypty i CDN-y — zaktualizuj na https:// lub użyj protocol-relative //cdn.example.com/. (5) Po naprawie: ponownie przeskanuj Screaming Frog Insecure Content report — powinien być pusty.

Dodatkowa wskazówka z praktyki Semgence: po naprawie mixed content warto dodać nagłówek Content-Security-Policy: upgrade-insecure-requests — przeglądarka automatycznie zamieni http:// na https:// dla wszystkich zasobów, nawet jeśli pominiesz jakiś hardcoded URL. To dodatkowa warstwa bezpieczeństwa, nie zastępstwo dla naprawy. Więcej o diagnostyce technicznej: checklista technicznego SEO.

Jak sprawdzić konfigurację HTTPS? SSL Labs Server Test – case study semgence.pl

SSL Labs Server Test (ssllabs.com) to bezpłatne narzędzie Qualys, które przeprowadza dogłębny audyt konfiguracji SSL/TLS serwera. Wynik: ocena od A+ (najlepsza) do F (krytyczne problemy), z szczegółową analizą protokołów, certyfikatu, szyfrów i znanych podatności. Nie wymaga rejestracji — wpisujesz domenę, czekasz 1-2 minuty, dostajesz pełny raport.

Poniżej wynik testu SSL Labs dla semgence.pl przeprowadzony 22 maja 2026:

Co sprawdza SSL Labs i jak czytać wynik?

Ocena A+ oznacza, że serwer spełnia wszystkie najwyższe standardy bezpieczeństwa. Kluczowe elementy oceny semgence.pl:

• Protokoły: TLS 1.3 + TLS 1.2 — wspierane są tylko bezpieczne wersje. Starsze TLS 1.0 i 1.1 są wyłączone (deprecated od 2020)
• HSTS aktywny — nagłówek Strict-Transport-Security: max-age=31536000; includeSubDomains wymusza HTTPS na poziomie przeglądarki przez 1 rok
• Forward Secrecy (ECDHE) — nawet jeśli klucz prywatny zostanie skompromitowany w przyszłości, wcześniejsze sesje pozostają bezpieczne
• Tylko AEAD ciphers — brak CBC (podatnych na padding oracle attacks). AEAD (AES-GCM, ChaCha20-Poly1305) to nowoczesne szyfry
• Brak podatności — BEAST, POODLE, Heartbleed, ROBOT, DROWN — wszystkie negatywne

Jak uzyskać A+? Trzy warunki: (1) wyłącz TLS 1.0 i 1.1 (zostaw tylko 1.2 + 1.3), (2) włącz HSTS z długim max-age (min. 6 miesięcy = 15 552 000 sekund), (3) skonfiguruj Forward Secrecy na wszystkich cipher suites. Większość nowoczesnych hostingów (LH.pl, nazwa.pl, OVH) spełnia te warunki domyślnie.

Typowe oceny polskich serwisów SEO: A+ (najlepsza) — wymaga HSTS + nowoczesnych protokołów. A — dobra konfiguracja, ale bez HSTS lub z drobnymi problemami. B — obsługuje stare protokoły (TLS 1.0/1.1) lub słabe szyfry. C i niżej — poważne problemy bezpieczeństwa. T — problem z zaufaniem certyfikatu (np. self-signed). Sprawdź swój serwis: ssllabs.com/ssltest.

Glenn Gabe z GSQi — ekspert, który przeprowadził dziesiątki dużych migracji serwisów — zwraca uwagę na najczęściej pomijany element migracji HTTP → HTTPS: redirecty obrazów. Przy zmianie protokołu (lub przebudowie CMS) URL-e obrazów często się zmieniają — a bez 301 redirectów obrazy tracą wszystkie backlinki, które narosły w czasie. Gabe opisuje proces: przed push to production przygotuj pełną listę starych URL-i obrazów (eksport ze Screaming Frog — zakładka Images), zaimportuj ją w list mode do Screaming Frog w środowisku staging i sprawdź, czy każdy stary URL obrazu poprawnie 301 na nowy. Typowy błąd: redirect obrazu prowadzi do 404 zamiast do nowej lokalizacji. Drugi błąd: łańcuch redirectów (obraz → redirect → redirect → docelowy URL). Gabe zaleca dwuetapowy test: najpierw sprawdź czy redirect działa, potem sprawdź czy docelowy URL zwraca 200.

Gabe opublikował też checklistę 8 natychmiastowych sprawdzeń SEO po migracji CMS. Kluczowe punkty z listy: (1) crawl najważniejszych landing pages z GA/GSC natychmiast po push to production — nie czekaj na dane; (2) zweryfikuj redirecty top 100 URL-i (pages z największym ruchem organicznym); (3) sprawdź robots.txt — częsty błąd po migracji to staging robots.txt z Disallow: / wrzucony na produkcję; (4) monitoruj GSC Coverage i Crawl Stats przez 2-4 tygodnie. Gabe podkreśla, że nawet Google napotkał problemy podczas migracji własnego serwisu Webmaster Central na Search Central — co obrazuje, jak skomplikowane są migracje nawet dla najbardziej doświadczonych zespołów.

HTTPS a widoczność w AI Search

Boty AI (GPTBot, ClaudeBot, PerplexityBot) preferują strony HTTPS – bezpieczne połączenie to standard. Brak HTTPS może blokować crawlowanie przez niektóre boty AI (restrykcje bezpieczeństwa). Certyfikat SSL to minimum do budowania zaufania – zarówno dla użytkowników, jak i systemów AI. Więcej: audyt widoczności w AI.

Najczęściej zadawane pytania o HTTPS