Certyfikat SSL jest dziś standardowym elementem strony internetowej, sklepu i aplikacji webowej. Jego obecność pozwala korzystać z HTTPS i zabezpieczać komunikację pomiędzy przeglądarką użytkownika a serwerem.
Samo uruchomienie certyfikatu nie oznacza jednak, że wdrożenie zostało wykonane poprawnie.
Szczególnie w przypadku istniejącej strony przejście z HTTP na HTTPS oznacza zmianę adresów całego serwisu. Trzeba zadbać nie tylko o certyfikat, ale również o przekierowania, linkowanie wewnętrzne, adresy kanoniczne, mapę strony, zasoby zewnętrzne, konfigurację WordPressa, integracje oraz indeksowanie w Google.
Błąd na którymkolwiek z tych etapów może prowadzić między innymi do:
W tym poradniku wyjaśniamy, czym rzeczywiście jest certyfikat SSL, czym różni się HTTP od HTTPS, kiedy wystarczy darmowy certyfikat, jak wygląda jego uzyskanie oraz przede wszystkim jak poprawnie przeprowadzić stronę z HTTP na HTTPS bez niepotrzebnych problemów technicznych i SEO.
Certyfikat SSL to powszechnie używana nazwa certyfikatu cyfrowego, który pozwala przeglądarce uwierzytelnić serwer dla danej domeny i uczestniczy w ustanowieniu bezpiecznego połączenia. Warto przy tym rozróżnić certyfikat od protokołu TLS.
Certyfikat pozwala między innymi potwierdzić, z jakim serwerem łączy się przeglądarka.
TLS jest współczesnym protokołem odpowiedzialnym za zabezpieczenie komunikacji.
Określenie „SSL” pozostało w powszechnym użyciu, dlatego nadal mówimy o:
Technicznie współczesne bezpieczne połączenia HTTPS wykorzystują jednak TLS, a nie historyczne wersje protokołu SSL.
Najważniejszym efektem prawidłowo skonfigurowanego certyfikatu jest możliwość korzystania ze strony przez HTTPS.
Dzięki HTTPS informacje przesyłane pomiędzy użytkownikiem a serwerem są szyfrowane, co znacznie utrudnia ich odczytanie lub modyfikację podczas transmisji.
Ma to szczególne znaczenie przy:
HTTPS jest więc podstawowym elementem technicznego bezpieczeństwa współczesnej strony. Nie oznacza jednak, że sama obecność certyfikatu zabezpiecza stronę przed włamaniem, złośliwym oprogramowaniem (malware), podatnymi wtyczkami czy przejęciem konta administratora. SSL/TLS zabezpiecza przede wszystkim komunikację. Bezpieczeństwo całego serwisu wymaga znacznie szerszego podejścia.
Jeżeli chcesz sprawdzić również inne obszary, opisujemy je w poradniku jak sprawdzić, czy strona internetowa jest bezpieczna.
HTTP jest protokołem wykorzystywanym do komunikacji pomiędzy przeglądarką a serwerem.
HTTPS to jego zabezpieczony wariant, w którym komunikacja odbywa się przy wykorzystaniu TLS.
W praktyce różnicę widać już w adresie:
http://example.pl
oraz:
https://example.pl
Nie są to przy tym dwa zapisy tego samego adresu z punktu widzenia wyszukiwarki.
Google traktuje przejście z HTTP na HTTPS jako zmianę adresów URL witryny, dlatego migracja powinna zostać przeprowadzona podobnie jak inne zmiany struktury adresów: z prawidłowymi przekierowaniami, adresami kanonicznymi, linkami wewnętrznymi oraz mapą strony.
To jeden z najważniejszych powodów, dla których wdrożenie SSL na istniejącym serwisie nie powinno kończyć się na samym aktywowaniu certyfikatu.
W codziennym języku nadal funkcjonuje określenie certyfikat SSL i właśnie tak użytkownicy najczęściej szukają tej usługi oraz informacji na jej temat. Dlatego używanie nazwy „SSL” nie jest błędem komunikacyjnym.
Warto jednak wiedzieć, że współczesne połączenie HTTPS wykorzystuje TLS. Historyczne wersje SSL nie powinny być utożsamiane ze współczesnym standardem zabezpieczania stron. Dla właściciela strony najważniejsza nie jest sama nazwa protokołu, ale to, czy:
Sposób uzyskania certyfikatu zależy od infrastruktury strony. Na typowym hostingu proces jest często w dużym stopniu zautomatyzowany. Panel administracyjny może umożliwiać aktywowanie bezpłatnego certyfikatu dla domeny bez ręcznego wykonywania operacji kryptograficznych.
Podstawy infrastruktury wyjaśniamy szerzej w artykule czym jest serwer i jak wpływa na działanie strony internetowej.
W bardziej zaawansowanej infrastrukturze certyfikaty mogą być zarządzane przez serwer, platformę chmurową, CDN lub inne elementy infrastruktury odpowiedzialne za obsługę ruchu.
Proces w uproszczeniu obejmuje:
W przypadku Let’s Encrypt potwierdzenie kontroli nad domeną może być wykonywane automatycznie przez protokół ACME, a sam urząd certyfikacji nie generuje ani nie przechowuje prywatnego klucza właściciela strony.
Przy niektórych ręcznych lub komercyjnych procesach administrator może wygenerować również CSR, czyli żądanie podpisania certyfikatu.
Dla właściciela zwykłej strony WordPress najczęściej nie jest to jednak czynność, którą trzeba wykonywać samodzielnie. Wiele współczesnych środowisk hostingowych automatyzuje cały proces.
W zdecydowanej większości typowych stron firmowych, blogów, stron WordPress i wielu sklepów internetowych poprawnie wdrożony bezpłatny certyfikat DV jest wystarczającym rozwiązaniem do zapewnienia HTTPS.
Najbardziej znanym dostawcą takich certyfikatów jest Let’s Encrypt – bezpłatny i zautomatyzowany urząd certyfikacji. Let’s Encrypt wydaje certyfikaty typu Domain Validation, czyli potwierdzające kontrolę nad domeną.
Darmowy certyfikat nie oznacza automatycznie słabszego szyfrowania połączenia tylko dlatego, że nie został kupiony.
Znacznie ważniejsze są:
Let’s Encrypt projektuje swój system w oparciu o automatyzację wydawania i odnawiania certyfikatów. Jego standardowe certyfikaty mają stosunkowo krótki okres ważności, dlatego automatyczne odnawianie powinno być częścią prawidłowo skonfigurowanego środowiska.
Nie każda organizacja musi korzystać z bezpłatnego certyfikatu DV. Istnieją również certyfikaty związane z dodatkową walidacją organizacji, takie jak OV i EV. Let’s Encrypt ich nie oferuje – wydaje certyfikaty DV.
Certyfikat komercyjny może mieć uzasadnienie przykładowo wtedy, gdy:
Nie należy jednak zakładać, że płatny certyfikat automatycznie „szyfruje mocniej” od prawidłowo skonfigurowanego bezpłatnego certyfikatu DV.
Decyzja powinna wynikać z wymagań organizacji i infrastruktury, a nie z samego faktu, że certyfikat jest płatny.
Przy bardziej złożonych serwisach warto również sprawdzić, jakie nazwy domenowe powinny być objęte certyfikatem.
Certyfikat może obejmować główną domenę, jej wersję z www, wybrane subdomeny albo kilka różnych nazw domenowych. Dostępne są również certyfikaty typu wildcard, przeznaczone do obsługi wielu subdomen. Let’s Encrypt obsługuje zarówno certyfikaty wielodomenowe, jak i wildcard. Przed wdrożeniem należy więc ustalić, które wersje domen i subdomen rzeczywiście wykorzystuje serwis.
Jeśli problem dotyczy również konfiguracji domeny lub DNS, zobacz poradnik Domena internetowa – rejestracja, właściciel, DNS, ceny i znaczenie dla SEO.
WordPress jest w pełni zgodny z HTTPS i oficjalna dokumentacja zdecydowanie rekomenduje korzystanie z bezpiecznego połączenia zarówno dla użytkowników, jak i logowania do systemu. Wdrożenie certyfikatu na serwerze jest jednak dopiero początkiem.
Przy istniejącej stronie WordPress trzeba sprawdzić między innymi:
Jeżeli część strony nadal odwołuje się do zasobów HTTP, może pojawić się mixed content.
W przypadku starszych lub rozbudowanych instalacji nie powinno się także bezrefleksyjnie zmieniać adresów bez wcześniejszej kopii bezpieczeństwa i weryfikacji wpływu na dane przechowywane przez WordPress i wtyczki.
Profesjonalne utrzymanie takich elementów może być częścią wsparcia technicznego WordPress lub stałej opieki nad stronami internetowymi.
W sklepie WooCommerce konsekwencje niepoprawnej migracji mogą być większe niż na klasycznej stronie firmowej.
Poza standardowymi elementami WordPressa trzeba zweryfikować:
Jeżeli któryś z tych mechanizmów nadal odwołuje się do starego adresu HTTP, może nie działać prawidłowo po migracji.
Szczególnej uwagi wymagają systemy zewnętrzne, które posiadają zapisany konkretny adres zwrotny. Sama zmiana WordPressa na HTTPS nie musi automatycznie zaktualizować konfiguracji po stronie operatora płatności, systemu ERP czy innej usługi.
Dlatego przy sklepie przejście na HTTPS powinno zostać potraktowane jako wdrożenie wymagające testów procesu zakupowego, a nie tylko zmiana ustawienia serwera. Przy istniejących sklepach takie prace mogą być również realizowane w ramach wsparcia technicznego WooCommerce.
Mixed content, czyli mieszana zawartość, pojawia się wtedy, gdy strona otwierana przez HTTPS próbuje pobierać część zasobów przez niezabezpieczony HTTP.
Może to dotyczyć między innymi:
Przykładowo sama strona może działać pod HTTPS, ale zapisany kilka lat wcześniej adres zdjęcia nadal rozpoczyna się od HTTP. W zależności od rodzaju zasobu przeglądarka może wyświetlić ostrzeżenie albo zablokować jego załadowanie.
To dlatego po migracji nie wystarczy spojrzeć na adres strony głównej i stwierdzić, że „SSL działa”. Trzeba sprawdzić również zasoby wykorzystywane przez całą witrynę.
Sprawdzimy certyfikat, przekierowania, mixed content, konfigurację WordPressa lub WooCommerce oraz elementy istotne dla SEO. W przypadku bardziej rozbudowanych serwisów zweryfikujemy również integracje i zachowanie aplikacji po zmianie adresów.
To najważniejszy etap całego procesu. Google klasyfikuje zmianę HTTP → HTTPS jako migrację obejmującą zmianę URL-i. Zaleca przygotowanie nowych adresów, użycie trwałych przekierowań, aktualizację canonicali, linków wewnętrznych i mapy strony oraz późniejsze monitorowanie migracji.
Przed zmianą wykonaj backup strony i bazy danych.
W większym serwisie warto również sprawdzić:
Im większy serwis, tym bardziej przydatna jest wcześniejsza lista elementów wymagających kontroli.
Najpierw HTTPS powinien rzeczywiście działać.
Trzeba sprawdzić, czy certyfikat:
Dopiero później warto kierować cały ruch z HTTP do HTTPS. Włączenie globalnego przekierowania zanim wersja HTTPS zostanie poprawnie skonfigurowana może spowodować niedostępność całego serwisu.
W WordPressie należy upewnić się, że właściwe adresy serwisu korzystają z HTTPS. W innych CMS-ach i aplikacjach sposób konfiguracji będzie zależał od architektury projektu.
Samo przekierowanie ruchu na HTTPS nie wystarczy. Również WordPress lub inna aplikacja powinny być skonfigurowane tak, aby korzystać z właściwych adresów HTTPS.
Następnie trzeba znaleźć i poprawić pozostałe adresy HTTP znajdujące się między innymi w:
Celem jest wyeliminowanie mixed content oraz niepotrzebnych przekierowań zasobów.
Każdy stary adres HTTP powinien prowadzić do odpowiadającego mu adresu HTTPS.
Przykładowa zasada jest prosta:
Nie należy kierować wszystkich starych adresów do strony głównej.
Google rekomenduje trwałe przekierowania po stronie serwera, takie jak 301 lub 308, oraz unikanie zbędnych łańcuchów przekierowań.
Sposób ich konfiguracji zależy od środowiska. Może to być Apache, Nginx, panel hostingu, CDN lub inny element infrastruktury odpowiedzialny za obsługę ruchu.
Dlatego .htaccess jest tylko jednym z możliwych miejsc realizacji przekierowań, a nie uniwersalnym rozwiązaniem dla każdej strony.
Linki w obrębie strony powinny prowadzić bezpośrednio do wersji HTTPS.
Nie warto polegać na schemacie: link HTTP → przekierowanie → HTTPS.
Przekierowanie powinno zabezpieczać stare adresy, ale nowa wersja serwisu powinna linkować już bezpośrednio do właściwych URL-i.
Google również rekomenduje aktualizację linków wewnętrznych podczas migracji.
Jeżeli serwis używa adresów kanonicznych, po migracji powinny one wskazywać wersję HTTPS.
Przykładowo strona:
https://example.pl/oferta/
nie powinna wskazywać jako adres kanoniczny:
http://example.pl/oferta/
Google preferuje HTTPS jako wersję kanoniczną, ale sprzeczne sygnały mogą utrudniać prawidłową konsolidację adresów. W serwisach wielojęzycznych należy również sprawdzić adresy używane przez hreflang.
Mapa strony XML powinna zawierać docelowe adresy HTTPS. Po migracji warto przesłać aktualną mapę w Google Search Console. Google zaleca ten krok przy zmianie URL-i i wskazuje, że może on pomóc wyszukiwarce szybciej odnaleźć nowe adresy.
Migracja to dobry moment, aby sprawdzić, czy przypadkiem:
Pozostawienie blokady po wdrożeniu jest jednym z błędów, które mogą poważnie wpłynąć na indeksowanie.
Po migracji należy monitorować:
W przypadku przejścia wyłącznie z HTTP na HTTPS nie należy korzystać z narzędzia Change of Address – Google wprost zaznacza, że nie jest ono wymagane dla takiej migracji.
W zależności od projektu aktualizacji mogą wymagać:
Im bardziej rozbudowana strona lub sklep, tym większe znaczenie ma ten etap.
Po wdrożeniu sprawdź:
Google zaznacza, że przy znaczących zmianach URL-i mogą występować czasowe wahania widoczności, gdy Google ponownie odwiedza i przetwarza zmienione adresy.
HTTPS jest wykorzystywany przez Google jako sygnał rankingowy. Google wprowadzając go określał jednak jako relatywnie lekki sygnał – znacznie ważniejsze dla wyników pozostają między innymi jakość i użyteczność treści.
Nie należy więc myśleć: „zainstaluję SSL i strona automatycznie awansuje w Google”.
Znacznie większym problemem SEO może być źle przeprowadzona migracja.
Przykładowo:
W takich przypadkach problemem nie jest brak „mocy SEO certyfikatu”, ale niespójna architektura adresów.
HTTPS działa dla jednej wersji domeny, ale użytkownik otrzymuje błąd na www albo na określonej subdomenie.
Automatyczne odnowienie zostało źle skonfigurowane albo przestało działać.
W praktyce sam fakt skonfigurowania automatyzacji nie zwalnia z monitorowania jej działania.
Główna strona działa przez HTTPS, ale część obrazów, fontów lub skryptów nadal jest pobierana po HTTP.
To nieprawidłowe podejście do migracji.
Stary adres powinien prowadzić do swojego nowego odpowiednika, jeśli taki istnieje. Google ostrzega przed masowym przekierowywaniem niepowiązanych URL-i do jednego miejsca.
Przykładowo:
HTTP → HTTPS www → HTTPS bez www → właściwa podstrona.
Takie łańcuchy zwiększają liczbę dodatkowych operacji. Lepiej kierować użytkownika i wyszukiwarkę możliwie bezpośrednio do docelowego adresu.
Strona działa przez HTTPS, ale wysyła wyszukiwarce sprzeczny sygnał dotyczący preferowanego adresu.
Mapa strony nadal zawiera adresy HTTP.
Formularz, API, operator płatności albo webhook nadal korzysta ze starego adresu.
Przy bardziej rozbudowanej infrastrukturze certyfikat może działać poprawnie pomiędzy użytkownikiem a CDN, ale problem występuje na dalszym odcinku komunikacji albo system niewłaściwie rozpoznaje oryginalny protokół.
Może to powodować między innymi pętle przekierowań.
Podstawową kontrolę można przeprowadzić bez wiedzy programistycznej.
Sprawdź przede wszystkim:
W bardziej technicznej analizie warto dodatkowo sprawdzić konfigurację TLS, poprawność certyfikatu, przekierowania, adresy kanoniczne, mapę strony oraz odpowiedzi serwera.
SSL jest także jednym z elementów sprawdzanych podczas audytu bezpieczeństwa WordPress i WooCommerce.
Nie. To jedno z najważniejszych nieporozumień związanych z SSL.
Certyfikat i HTTPS pomagają chronić komunikację pomiędzy użytkownikiem a serwerem. Nie zabezpieczają jednak automatycznie przed:
Strona może posiadać całkowicie poprawny certyfikat SSL i jednocześnie być zainfekowana. Dlatego HTTPS powinien być traktowany jako jeden z fundamentów bezpieczeństwa, a nie jego zamiennik.
Szerszy proces zabezpieczenia opisujemy w materiale o hardeningu WordPress.
Certyfikat wymaga szczególnej uwagi również podczas zmiany hostingu lub infrastruktury. Nowy serwer musi być przygotowany do obsługi HTTPS zanim ruch zostanie na niego przełączony.
Po migracji trzeba sprawdzić między innymi:
Szerzej cały proces opisujemy w poradniku migracja strony internetowej – jak bezpiecznie przenieść witrynę na nowy serwer.
Certyfikat nie powinien być wdrażany i później całkowicie zapominany.
W dobrze utrzymywanym środowisku należy monitorować:
Szczególnie ważne jest to przy serwisach biznesowych, sklepach i aplikacjach, dla których wygaśnięcie certyfikatu może oznaczać problemy z dostępem użytkowników, sprzedażą albo komunikacją z zewnętrznymi systemami.
Takie działania mogą być realizowane w ramach stałej opieki nad stronami internetowymi.
Wdrożenia SSL nie traktujemy wyłącznie jako instalacji certyfikatu.
W zależności od projektu analizujemy cały proces:
Przy istniejącym serwisie najpierw ustalamy jego obecną konfigurację i potencjalne ryzyka, a dopiero później wprowadzamy zmianę. Ma to szczególne znaczenie w większych sklepach, serwisach wielojęzycznych i systemach posiadających wiele integracji, w których przejście na HTTPS może wpływać na znacznie więcej elementów niż tylko to, co użytkownik widzi bezpośrednio na stronie.
Certyfikat SSL jest podstawowym elementem współczesnej strony internetowej, ale jego poprawne wdrożenie oznacza znacznie więcej niż aktywowanie HTTPS w panelu hostingu.
Trzeba zadbać o cały proces:
certyfikat → konfiguracja HTTPS → przekierowania → adresy strony → mieszana zawartość → linkowanie → adresy kanoniczne → mapa strony → integracje → testy → monitoring.
Dla nowej, niewielkiej strony część tych czynności może zostać wykonana niemal automatycznie. Dla istniejącego WordPressa, sklepu WooCommerce lub bardziej rozbudowanej aplikacji przejście z HTTP na HTTPS powinno być potraktowane jak techniczna migracja serwisu.
Najważniejsze jest również to, że darmowy certyfikat SSL może być całkowicie właściwym rozwiązaniem. O jakości wdrożenia decyduje przede wszystkim poprawna konfiguracja całego środowiska, a nie sam fakt zakupu certyfikatu. HTTPS nie zastępuje również zabezpieczenia strony przed atakami. Jest jednym z elementów bezpieczeństwa obok aktualizacji, hardeningu, monitoringu, kopii bezpieczeństwa i właściwej administracji.
Możemy przeanalizować konfigurację istniejącego serwisu, przeprowadzić migrację z HTTP na HTTPS, usunąć problemy mixed content, uporządkować przekierowania i zweryfikować wpływ zmian na WordPress, WooCommerce oraz SEO.
Certyfikat SSL to powszechna nazwa certyfikatu cyfrowego wykorzystywanego do ustanowienia bezpiecznego połączenia HTTPS pomiędzy przeglądarką użytkownika a serwerem. Współcześnie właściwe zabezpieczenie komunikacji realizuje protokół TLS, ale określenie „certyfikat SSL” nadal jest standardowo używane.
Strona może technicznie działać przez HTTP, ale dla współczesnego serwisu produkcyjnego HTTPS powinien być traktowany jako standard. Ma szczególne znaczenie przy logowaniu, formularzach, kontach użytkowników, sklepach internetowych oraz innych miejscach, w których przesyłane są dane.
W większości standardowych stron firmowych, WordPressów i wielu sklepów internetowych prawidłowo skonfigurowany darmowy certyfikat DV jest wystarczający do zapewnienia bezpiecznego połączenia HTTPS. Przykładem jest Let’s Encrypt, który wydaje bezpłatne certyfikaty DV i automatyzuje ich obsługę.
Sam fakt, że certyfikat jest darmowy, nie oznacza słabszego szyfrowania komunikacji. Płatne rozwiązanie może różnić się między innymi sposobem walidacji, wsparciem dostawcy lub wymaganiami organizacyjnymi. O bezpieczeństwie połączenia decyduje jednak także konfiguracja serwera i TLS.
Na większości współczesnych hostingów certyfikat można uzyskać automatycznie w panelu administracyjnym. W bardziej zaawansowanej infrastrukturze certyfikaty mogą być generowane i odnawiane automatycznie przez system zarządzający serwerem lub protokół ACME.
Obecnie standardowe certyfikaty Let’s Encrypt są domyślnie ważne przez 90 dni i powinny być odnawiane automatycznie. Dostawca zapowiedział jednak stopniowe skracanie tego okresu w kolejnych latach, dlatego kluczowa jest poprawnie działająca automatyzacja odnawiania, a nie ręczne pilnowanie konkretnej daty.
Najpierw należy zainstalować i sprawdzić certyfikat, następnie skonfigurować stronę do działania przez HTTPS, usunąć odwołania HTTP i uruchomić trwałe przekierowania ze starych adresów na odpowiadające im nowe adresy HTTPS. Po migracji trzeba również sprawdzić linki wewnętrzne, canonicale, sitemapę, integracje oraz Google Search Console.
Tak, stare adresy HTTP powinny prowadzić do właściwych adresów HTTPS za pomocą trwałych przekierowań. Google rekomenduje po stronie serwera stałe przekierowania, takie jak 301 lub 308.
Nie zawsze. .htaccess jest jednym ze sposobów konfiguracji przekierowań na serwerach Apache. W innych środowiskach przekierowania mogą być realizowane przez Nginx, hosting, CDN, reverse proxy albo inną warstwę infrastruktury.
Mixed content występuje wtedy, gdy strona otwarta przez HTTPS próbuje pobierać część swoich zasobów przez HTTP. Może to dotyczyć obrazów, skryptów, arkuszy stylów, fontów lub innych elementów i powinno zostać usunięte po migracji.
Google wykorzystuje HTTPS jako jeden z sygnałów rankingowych, ale sam certyfikat nie jest sposobem na automatyczne uzyskanie wysokich pozycji. Z perspektywy SEO bardzo ważne jest natomiast poprawne przeprowadzenie migracji z HTTP na HTTPS: przekierowania, canonicale, linkowanie i indeksowanie nowych adresów.
Przy zmianie URL-i mogą pojawić się czasowe wahania, gdy Google ponownie crawluje i indeksuje nowe adresy. Google wskazuje, że jest to normalne podczas migracji. Ryzyko większych problemów rośnie, gdy migracja zostanie wykonana niepoprawnie, np. zabraknie właściwych przekierowań lub canonicali.
Nie. Google wyraźnie wskazuje, że przy migracji wyłącznie z HTTP na HTTPS narzędzie Change of Address nie jest potrzebne. Należy natomiast monitorować indeksowanie i przesłać aktualną sitemapę.
WordPress może technicznie działać bez HTTPS, ale oficjalna dokumentacja zdecydowanie rekomenduje HTTPS dla ochrony użytkowników i logowania do systemu. Dla produkcyjnej strony WordPress HTTPS powinien być obecnie standardem.
Nie. Nadal mogą występować problemy dotyczące innych podstron, mixed content, subdomen, integracji, przekierowań, canonicali albo odnawiania certyfikatu. Dlatego po wdrożeniu warto sprawdzić cały serwis, a nie tylko stronę główną.
Nie. HTTPS chroni przede wszystkim komunikację pomiędzy użytkownikiem a serwerem. Nie zabezpiecza automatycznie przed malware, podatnymi wtyczkami, słabymi hasłami lub przejęciem konta. Pełna ochrona WordPressa wymaga szerszych działań związanych z bezpieczeństwem.
Ten wpis stworzył
Ekspert od wycen dedykowanych rozwiązań i zarządzania projektami. Posiada ogromne doświadczenie w tworzeniu ofert idealnie dopasowanych do potrzeb i oczekiwań klientów, specjalista łączący pasję do nowych wyzwań z analitycznym podejściem do każdego szczegółu projektu.
Twoja strona internetowa jest bezpieczna? Poznaj wskazówki i darmowe narzędzia, które pomogą Ci ochronić witrynę!
Ile kosztuje administracja strony internetowej i WordPressa? Porównaj T&M, pakiety godzin, abonament, retainer, SLA i obsługę jednorazową.
Błąd 404, 500 czy 301? Sprawdź, co oznaczają błędy HTTP na stronie WordPress i jak je naprawić. Dowiedz się, jak uniknąć utraty ruchu.
Sprawdź, ile kosztuje usunięcie wirusa z WordPress, od czego zależy cena, co obejmuje czyszczenie malware i kiedy naprawa jest droższa niż przebudowa strony.
Share:
