Google odpowiada: “Każda kobieta ma w sobie trochę prostytutki” i inne absurdalne wyniki wyszukiwania – kolejne dowody na problemy Google z ostatnimi zmianami, jakie wprowadzili w wynikach wyszukiwania

Kilka dni temu pisaliśmy, że zmiany, jakie Google wprowadza do wyników wyszukiwania w ostatnich 2 miesiącach są wątpliwie dobre. Kolejne przykłady zawarte są w tym artykule. Jeśli w angielskiej wersji wyszukamy wyrażenia “czy kobiety są złe”, odpowiedź będzie brzmiała “Każda kobieta ma w sobie trochę prostytuki…”, ponieważ za najbardziej trafny wynik przyjęta jest nierzetelna strona.

Cieszy nagłośnienie sprawy przez coraz więcej renomowanych serwisów – daje to nadzieję na szybkie poprawienie fatalnych zmian z ostatnich miesięcy.

Odwiedzający pytają nas ostatnio o spostrzeżenia na temat zmian w sposobie ustalania pozycji, jakie Google przeprowadza od 2 miesięcy.

Faktycznie nie tylko my i inni branżowcy, ale też wszystkie narzędzia diagnostyczne (poniżej zdjęcia z algoroo.com i serpmetrics.com) wskazują na duży chaos w wynikach wyszukiwania, objawiający się zwłaszcza w dniach: 1 lutego, 8 lutego, 21 lutego, 8 marca (zobaczcie zmiany w ruchu na swoich stronach w tych dniach). W pozostałe dni też jednak widać było duże zawirowania.

Z danych, które mamy, wygląda to tak, jak gdyby Google wprowadzało zmiany, a potem się z nich wycofywało lub je mocno poprawiało. Nawet bardzo wartościowe witryny odnotowywały z dnia na dzień duże wzrosty i spadki w ruchu.

Zauważyliśmy nawet przypadek otrzymywania przez 2 dni przez podstronę z jednym produktem ruchu, który wielokrotnie przewyższał średnią miesięczną liczbę wyszukań takich produktów.

Już od około 2 lat Google nie udostępnia bardziej szczegółowych informacji o zmianach, jakie przeprowadza – bo robi to każdego dnia. Te z lutego i marca były jednak ewidentnie chybione i naprawiane czym prędzej. Trudno – jak widać, zdarza się najlepszym. Błędy jednak poprawiono, bo ruch trochę ustabilizował się.

Co więc należy robić? Dalej pozycjonować się etycznie. Google samo zauważa swoje błędy i je poprawia, więc podejrzewamy, że marzec będzie miesiącem, który będzie promował takie pozycjonowanie, jakie Google zaleca. Wszak zdecydowana większość miesięcy w roku przynosi zyski dla tych, którzy postępują zgodnie z zasadami.

Czasami zdarza się, że WordPress wykonuje samoczynnie aktualizacje.

Niekiedy też coś się nie powiedzie i mimo, że aktualizacja jakiegoś elementu (wtyczki, motywu, systemu) nie jest realizowana, to system w trakcie próby wykonania ręcznej aktualizacji wyświetla powiadomienie: “Aktualnie przeprowadzana jest inna aktualizacja” lub – w języku angielskim: “Another update is currently in progress”.

Jest to spowodowane włączeniem się mechanizmu zapobiegania wykonywaniu dwóch jednoczesnych aktualizacji.

Wszystko wróci do normy po 15 minutach – mechanizm sam odblokuje się i możliwe będzie ręczne przeprowadzenie aktualizacji.

Wiele firm hostingowych wdrożyło już wersję 7 języka PHP na swoje serwery, która jest znacznie szybsza od poprzednich (nawet dwukrotnie).

Jednocześnie zauważyłem, że wiele z tych firm (np. nazwa.pl, DreamHost) domyślnie ma wyłączone wsparcie dla mechanizmu OPcache, który według moich testów przyspiesza ładowanie stron na WordPressie i sklepach na WooCommerce dwu- a nawet trzykrotnie! Tak – 200% do 300%!

Najwięcej zyskują duże strony, jak sklepy. Czas ich generowania potrafił spaść z 10 sekund do 3 sekund.

Strony niezbyt skomplikowane, jak niniejsza, zyskują przyspieszenie rzędu 10% (czas ładowania spadł z 0,6s do 0,5s).

Wystarczy zapytać dostawcę hostingu, w którym miejscu można włączyć tą funkcję, a strona magicznie przyspieszy. Wiedza techniczna zazwyczaj nie jest wymagana. Dla WordPressa trzeba jednak zainstalować wtyczkę OPcache Dashboard, która automatycznie wyczyści cache po aktualizacji WordPressa, co jest niekiedy potrzebne.

Będzie to kosztem pamięci RAM, ale jeśli mamy zapas około 100MB (a tak zazwyczaj jest), to nie powinno to być żadnym problemem.

Na serwerze firmy Nazwa spotkaliśmy się z nietypowym problemem: generowane przez funkcję PHP date() polskie nazwy miesięcy i dni tygodnia zamiast polskich znaków wyświetlały typowe ikony “diamentów” z pytajnikiem w środku (tzw. krzaki), sygnalizujące problem z kodowaniem.

Generowane przez PHP, a zarazem WordPressa kodowanie tych znaków nie było kodowaniem Windows-1250, ani UTF-8, ani ISO-8859-2. Mimo jasnych ustawień domyślnego kodowania PHP w phpinfo(), nagłówków HTTP, znacznika meta na UTF-8, usilnie stosowane było bliżej niesprecyzowane kodowanie znaków. Także zapisy w górnej części pliku .htaccess nie pomogły:

AddDefaultCharset utf-8
IndexOptions +Charset=UTF-8

Dopiero wklejenie w górnej części pliku wp-config.php poniższego kodu pomogło:

setlocale(LC_ALL,[‘pl_PL.utf8’, ‘pl_PL’,’pl’,’pl_PL.utf-8′,’Polish_Poland.65001′,’polish_poland’]);

Z kolei pliki zawierające polskie znaki, a wgrane na serwer przy użyciu automatycznego ustawiania kodowania w programie FlashFXP, nie były dostępne przez przeglądarkę (błąd 404: nie znaleziono). Dopiero ręczne przestawienie enkodowania plików w ustawieniach FlashFXP na UTF-8 i ponowne wgranie (nadpisanie) plików w taki sposób pomogło i pliki stały się dostępne w przeglądarce.