Mogłoby się wydawać, że Google powinno sobie radzić z rozpoznaniem DC wynikającego z indeksacji strony głównej pod kilkoma adresami, np. seostation.pl i www.seostation.pl czy też www.seostation.pl/index.php W końcu naturalne jest, że np. "www" nie jest typową subdomeną, na której może znajdować się zupełnie inny serwis, podobnie jak końcówki adresów w postaci index.php czy index.html domyślnie wczytują zawartość strony głównej. Przez długi okres nie spotykałam się z przypadkami stron, których pozycje ucierpiały w wyniku tego typu problemów, aż do ostatnich miesięcy. Ponieważ odnoszę wrażenie, że problem DC w opisanych przypadkach jest przez wielu bagatelizowany, postanowiłam opisać go na kilku przykładach. 

Przykład nr 1: przejęcie strony w trakcie jej migracji do HTTPS

W połowie września br. zaczęłam się zajmować stroną jednego z nowych klientów. Pech chciał, że trafiłam na moment tuż po przebudowie serwisu i po podjęciu decyzji o migracji do HTTPSa. Ponieważ pech chodzi parami, po tygodniu ogłoszono aktualizację Pingwina, a strona dosłownie dzień przed nią spadła poza top 100 na wszystkie frazy poza tymi, na które wyświetlały się mapki Google. W rezultacie szukałam igły w stogu siana, bo tak samo prawdopodobne było to, że spadki były wynikiem przeindeksowywania strony, jak i to, że zwierzakowi Google nie spodobały się linki... zresztą nic dziwnego, bo sama miałam obawy o to, że prędzej czy później odbiją się na pozycjach i dlatego zaproponowałam usunięcie części z nich. Mimo wszystko zdecydowałam się zacząć od działań on-site, opierając się na dawnych doświadczeniach, w których nawet jeden drobny błąd wywołał efekt podobny do filtra. 

Po rozpoczęciu prac nad stroną zaczęłam od porządków w optymalizacji, a tych było niemało, w tym:

• ustawienie przekierowania 301 z HTTP na HTTPS - wcześniej go nie było, dlatego Google indeksowało część serwisu w dwóch wersjach. Niestety Search Console umożliwia jedynie wskazanie preferowanej domeny tylko pomiędzy tą z i bez "www", ale nie ma takiej opcji pomiędzy HTTP i HTTPS. Z kolei przekierowanie 301 nie zadziałało tak szybko, jak bym sobie tego życzyła; 
• usunięcie zduplikowanych treści podstron - część z nich była dostępna pod różnymi adresami ze względu na błędy skryptu. Udało się to jednak wyeliminować;
• drobne poprawki optymalizacyjne, których nie zdążyłam wprowadzić w pierwszej kolejności. 

Problemy z pozycjami utrzymywały się od momentu, w którym Google zaczęło indeksować pierwsze adresy z HTTPS, ale nie zauważyło jeszcze przekierowania. Trwało do momentu, w którym zapytanie site:domena.pl pokazywało na 1. pozycji adres strony głównej z HTTPS. 

Poniższy wykres prezentuje zmiany w pozycjach dla 4 fraz (po 1 głównej dla najważniejszych podstron). Spadki wystąpiły 22 września, stąd też podejrzenie, że to efekt Pingwina (23 września - zaznaczone linią na wykresie).

Po tygodniu od ustawienia 301 pozycje zaczęły wracać, jednak tylko na chwilę, ponieważ stały wzrost nastąpił dopiero w pierwszych dniach listopada. Wpływ na to mogły mieć też dodatkowe błędy, przez które w wersji HTTP Google indeksował podstrony z 404 i faktycznie dopiero po ich pełnym wyindeksowaniu (połączenie zapisów w robots.txt z ręcznym wyindeksowywaniem przez Search Console) nastąpił listopadowy powrót. 

Wskazówka:

W przypadku zauważenia spadków pozycji (a najlepiej już w tej chwili, niezależnie od kondycji strony) warto zacząć od sprawdzenia, jakie wyniki zwraca Google dla zapytania o site strony. Standardowo na 1. pozycji powinna się znajdować strona główna - jeśli tak nie jest, trzeba się temu bliżej przyjrzeć tym bardziej, jeśli jej pozycje spadły. Jeśli jest to 1. pozycja, ale w wersji innej niż "preferowana" przez nas i również łączy się to z niższymi pozycjami, należy uporządkować tę kwestię przez ustawienie przekierowania 301 albo zastosowanie rel="canonical" i odczekanie, aż wyszukiwarka przeindeksuje adresy, przywracając dawne pozycje. 

W celu sprawdzenia ilości podstron zaindeksowanych z HTTPS, nie działa zapytanie site:https://domena.pl tylko site:domena.pl inurl:https a dla sprawdzenia podstron bez HTTPSa może to być zapytanie site:domena.pl inurl:http albo site:domena.pl -inurl:https

Przykład nr 2: przypadkowa indeksacja wersji HTTPS

Podobna sytuacja wystąpiła na stronie kolegi. Ta jednak została zaindeksowana w wersji z HTTPS przez przypadek, co nastąpiło 12 grudnia br. Kiedy w tym tygodniu dostałam informację o problemie, w pierwszej kolejności odpytałam o site i od razu miałam déjà vu - strona główna i najważniejsze podstrony spadły na odległe pozycje i były zaindeksowane w wersji z HTTPS zamiast HTTP. 

Zerknęłam więc do monitora pozycji widząc, że spadki dotyczyły większości fraz, co potwierdzało Search Console. Oto wykres zmian w pozycjach dla 4 wybranych fraz:

Od razu dostałam sygnał, że linkowanie może nie być do końca prawidłowe, jednak szybka analiza danych z Majestic i Search Console pokazała, że nie tylko linków nie ma zbyt wiele, ale także ich profil jest całkiem ciekawy, więc nie powinny one stanowić problemów. Na pierwszy rzut i tak poszły działania on-site, które w tym przypadku ograniczyły się do ustawienia 301 na wersję z HTTP i przyspieszenie zauważenia przekierowania dzięki formularzowi "Pobierz jako Google". 

Jak widać na powyższym wykresie, na efekt nie trzeba było długo czekać. Niewykluczone jednak, że jeszcze przez pewien okres na różnych DC będą widoczne inne wersje adresów, dlatego spadki mogą się powtarzać, chociaż tym razem zapewne na krótszy okres. 

Wskazówka:

Oprócz tego, co napisałam we wskazówce do pierwszego przykładu, warto pobrać pełną* listę zaindeksowanych podstron i przejrzeć ją dokładnie. Można w tym celu skorzystać z rozszerzenia do Chrome o nazwie Scraper. Wystarczy:

• ustawić w Google ilość podstron na 1 stronie wyników na 100;
• odpytać wyszukiwarkę o ilość zaindeksowanych podstron;
• kliknąć na dowolny wynik prawym przyciskiem myszy i wybrać "Scrape Similar";

W rezultacie uzyskujemy czytelną listę, z której nie tylko sprawdzimy zaindeksowane podstrony, ale także sortując po tytułach możemy szybko sprawdzić, czy nie mamy duplikatów.

Taka analiza pozwoli nam to upewnić się co do tego, czy nie występują jeszcze jakieś problemy z indeksacją i czy np. nie powinniśmy dopisać w pliku robots.txt blokady indeksacji niektórych adresów. Mogą to być wyniki wyszukiwania, sortowania, filtrowania czy też wersje artykułów do wydruku. Może się również okazać, że skrypt - mimo włączonego modułu przyjaznych adresów URL - wyświetla podstrony również pod swoimi oryginalnymi, dalekimi od przyjaznych adresami. 

Przykład nr 3: ten nieszczęsny index.php

Wracamy do strony z przykładu nr 1, na której chwilowo występował problem wynikający z indeksacji adresu w postaci domena.pl/index.php Akurat zachowałam zrzut ekranu z SeoStation, na którym widać spadek pozycji właśnie w momencie, kiedy Google uznał za główną wersję adres z index.php na końcu. 

Po ustawieniu przekierowania 301 z adresu z index.php na główny adres, strona jeszcze kilka razy na pojedyncze dni wypadała poza setkę. 

Wskazówka:

Upewnijmy się, że na stronie nie ma nigdzie linków kierujących do plików index.* Jeśli takie linki kiedykolwiek istniały, w szczególności jeśli do tych adresów prowadzą linki z zewnątrz, ustawmy przekierowanie 301 na prawidłowy adres. Aby upewnić się, że przekierowanie działa, można skorzystać np. z narzędzia http://www.webconfs.com/http-header-check.php

Warto przyspieszyć zauważenie przekierowania przez Google, korzystając z Search Console z opcji Indeksowanie -> Pobierz jako Google.