Optymalizując strony sklepów internetowych wdrażamy przeróżne rozwiązania, które mają na celu zwiększyć ogólnie pojętą wydajność, zmniejszając między innymi czas ładowania strony, co prowadzi do zmniejszenia współczynnika odrzuceń i bezpośrednio zwiększa szansę, iż odwiedzający złoży zamówienie właśnie w naszym sklepie. Czy wszystkie mechanizmy optymalizacyjne są idealne? Jak pokazuje praktyka niektóre rozwiązania mają swoje wady. W tym artykule opowiem o bardzo istotnym problemie wynikającym z użycia wtyczek cache.
To już druga tego typu sytuacja, z którą się spotykam w tym roku, gdzie serwis wskutek błędów 404 traci ruch z Google. Cała historia skłoniła mnie do napisania niniejszego wpisu, aby zwrócić Twoją uwagę na potencjalny problem, który w części przypadków może doprowadzić nawet do wyindeksowania sklepu z Google.
Na czym polega mechanizm cachowania? Zawartość strony internetowej może być generowana w sposób dynamiczny, za każdym razem gdy użytkownik zażąda dostępu do strony, jej zawartość zostanie przetworzona a następnie dostarczona w końcowej postaci (kod HTML). Podobnie jest, gdy strona zawiera informacje, które muszą zostać pobrane z bazy danych. Żądanie wyświetlenia strony spowoduje wykonanie zapytań do bazy i przetworzenie uzyskanych informacji zgodnie z regułami zawartymi w skrypcie.
Każda tego typu operacja angażuje zasoby serwera WWW i serwera bazodanowego. Jeśli wywołanie strony odbywa się raz na jakiś czas, problemu wielkiego nie będzie, kłopot z wydajnością zacznie się, gdy sklep stanie się popularny lub gdy będziemy przeprowadzali jakąś kampanię promocyjną, wtedy wielu użytkowników w tym samym czasie może zechcieć wyświetlić podstronę z promocją i zaczną się schody. W tym miejscu do gry wchodzi cache – gdy pierwszy z użytkowników zażąda dostępu do podstrony z promocją, nastąpi przetworzenie kodu PHP i zapisanie kodu strony oraz zapytań do bazy w plikach na serwerze. Żądania kolejnych użytkowników będą realizowane z plików, a nie tak jak to miało miejsce na początku – bezpośrednio z kodu PHP i bazy danych. Tym sposobem omijamy etap oczekiwania na przetwarzanie informacji i od ręki dostarczamy użytkownikowi tego czego potrzebuje.
Listę dodatków cachujących dla WordPress znajdziesz w tym wpisie.
Owe mechanizmy są zbawienne jeśli chodzi o odciążenie serwera, jednak wadliwe działanie wtyczek cache może doprowadzić do powstania błędów 404, konsekwencją czego będą spadki pozycji w wynikach organicznych, a czasem nawet może dojść do całkowitego usunięcia strony z wyników wyszukiwania.
Kilka dni temu skontaktował się ze mną właściciel sklepu internetowego, który poprosił mnie o pomoc w zdiagnozowaniu problemu. Wygospodarowałem odrobinę czasu i postanowiłem pomóc.
W skrócie – sklep na WordPress + wtyczka WooCommerce, stron produktowych niecałe 400, po wejściu na część podstron otrzymywaliśmy błąd 404. Dla stron – cache ustawione na 7 dni, z kolei dla zapytań bazodanowych 72h. Po wstępnej analizie okazało się, że mamy do czynienia z problemem generowania cache. Odświeżyliśmy magazyn danych (usunięto katalog cache, w jego miejsce stworzono nowy, przyznano odpowiednie uprawnienia 755, na koniec wyłączono/włączono wszystkie wtyczki cache i wygenerowano nowe pliki pamięci podręcznej), po tych zabiegach nagle strony stały się dostępne dla użytkowników, jak również i dla Google Bota tj. nie generowały już błędów 404.
Co było w tym wszystkim dziwne? Problem dotyczył 30% podstron w sklepie. Zazwyczaj jak coś psuje się to na całego, gdzie globalnie mamy problem z dostępem do całego serwisu, tutaj problem dotyczył części sklepu. Niestety nie miałem czasu by zrobić dogłębną analizę tego przypadku, dlatego faktyczne przyczyny powstania błędu nie są do końca znane, najprawdopodobniej błąd jednej z wtyczek cache, możliwe są też inne błędy (po stronie serwera).
Jak zabezpieczyć się przed tym błędem? Idąc po najmniejszej linii oporu można rzec – najlepiej w ogóle nie używać mechanizmów cache. Cóż… takie podejście do tematu to stąpanie po kruchym lodzie. Sklepy z dużą liczbą użytkowników muszą optymalizować użycie zasobów serwera, czym lepsza optymalizacja, tym sklep przyjmie więcej użytkowników w danej jednostce czasu, jednocześnie zmniejszy się koszt utrzymania infrastruktury serwerowej, również zmniejszenie czasu ładowania strony w wyniku optymalizacji jest w interesie każdego właściciela sklepu, zatem wyłączenie cache nie wchodzi w grę. Co zatem zrobić?
1. Stale zaglądaj do Google Analytics i monitoruj ruch przychodzący z Google Organic.
Przykład spadku ruchu w sklepie, wynikający z błędów 404 i wyindeksownia części podstron…
2. Z poziomu Narzędzi dla webmasterów monitoruj liczbę wyświetleń i kliknięć (Ruch związany w wyszukwianiem => Wyszukiwane hasła).
Na poniższym zrzucie ekranu przykład wycięcia ruchu, gdzie większość podstron w sklepie zwracała kod błędu 404…
3. W WMT monitoruj także Stan indeksowania (Indeks Google => Stan indeksowania) oraz błędy 404 (Indeksowanie => Błędy indeksowania).
W przypadku zauważenia gwałtownego spadku liczby zaindeksowanych podstron, należy podjąć dodatkowe działania, w celu ustalenia przyczyny spadku poziomu indeksacji. W tym celu przejdź do sekcji Błędy indeksowania i sprawdź jak kształtowała się liczba błędów 404 na przestrzeni ostatnich tygodni.
UWAGA! Spadek liczby zaindeksowanych podstron może wynikać z innych przyczyn np. niska jakość stron, duplikacja. Więcej o duplikowaniu tutaj.
4. Użyj wtyczek lub programów, które pozwolą zbadać kody odpowiedzi wszystkich podstron w obrębie sklepu. Mając do dyspozycji sitemapę sklepu, możesz zaimportować ją do narzędzi i przeprowadzić szybko analizę. Analizę wykonuj w godzinach nocnych, gdy Twoją stronę odwiedza mniej użytkowników tj. gdy obciążenie serwera jest niższe.
Przykładowe aplikacje, które możesz wykorzystać:
- Netpeak Spider
- Netpeak Checker
- Screaming Frog SEO Spider (w przypadku posiadania sitemapy: Mode => List)
- Fast Link Checker Lite
- Visual SEO Studio (Przeglądaj sitemapę lub Zaindeksuj stronę)
- LinkCrawler
- SE Auditor (v 1.06a)
- SEO Odkurzacz
- SEO Web Analysis Toolset
- Excel z dodatkiem SeoTools
Część aplikacji pozwala wczytać dane bezpośrednio z pliku sitemap.xml, w innych listę adresów musisz mieć w formacie TXT. Programów podałem wiele, dlatego z pewnością coś dla siebie wybierzesz.
5. Upewnij się, że masz włączone powiadomienia mailowe w Narzędziach dla webmasterów (Ikonka koła zębatego => Narzędzia dla webmasterów – preferencje => Włącz powiadomienia e-mail => Typ: Wszystkie problemy). Dzięki temu wszystkie wykryte problemy z witryną zostaną zasygnalizowane wiadomością e-mail.
Znasz inne metody walki z tym problemem? Skomentuj artykuł podając rozwiązanie…
Ciekawa rzecz. Mariusz a może by pomogło częstsze cachowanie tych podstron? 3 doby dla zapytań bazodanowych to sporo.
Druga sprawa: te przypadki to tylko WP + WooCommerce czy jakiś inny skrypt zawalił?
Owszem może pomóc częstsze cachowanie ale wtedy benefity z użycia mechanizmów keszujących są mniejsze. Z jednej strony częstsze cachowanie – większe szanse na wystąpienie błędu, z drugiej strony częstsze odświeżanie cache może spowodować, iż nieprawidłowe pliki zostaną szybko zastąpione nowymi dobrymi, także tutaj na dwoje babka wróżyła.
Obydwa przypadki z 404 z tego roku to sklepy na WordPress. Miałem jeszcze podobny przypadek z ubiegłego roku ale on dotyczył platformy OpenCart.
Możesz napisać jaka wtyczka keszująca spowodowała te problemy?
Czy są wtyczki do wordpress automatycznie sprawdzające błedy na stronie czy musimy sami robić analizy używając podanych programów?
Ja w swoim sklepie z tym problemów nie mam, z oprogramowaniem również, świetnie mi działa w domenie od {reklama} i tymże hostingu, zawsze mam pomoc techniczną jakby się ktoś skarżył.
//Dzięki za komentarz, taka reklama nie przejdzie u mnie na blogu, musisz pokazać coś bardziej kreatywnego.
i bardzo dobrze, gratuluję, przeszedł Pan test.
//To sobie testuj gdzieś indziej, tutaj nie ma miejsca na szeptankę w dodatku tak kiepskiej jakości, wysil się trochę