Jak zenbox.pl z domen klientów korzystał

Niedawno na blogu sprawnymarketing.pl pojawił się wpis o tym, jak rzekomo Zenbox stosował black hat SEO. Sprawa okazała się znacznie głębsza, szersza i ciekawa, niż na pierwszy rzut oka wyglądał. W różnych wymiarach, od technicznych, po prawne.

Przede wszystkim, niezaprzeczalnym faktem jest, że niektóre strony (raczej: większość) hostowane na zenbox.pl, pokazywały co innego przy wejściu przez HTTP, a co innego przez HTTPS. Jak pokazują zamieszczone w ww. wpisie zrzuty ekranu, narzędzia do badania SEO zauważały te linki. Raczej słusznie, bo wbrew temu, co twierdzi zenbox.pl, strony te nie zostały zignorowane przez Google, lecz normalnie zaindeksowane, co pokazuje poniższy zrzut ekranu:

Zenbox.pl SEO HTTPS

Szybko okazało się, że zenbox.pl nie jest jedynym hostingiem, który działa w ten sposób, a winny jest prawdopodobnie panel DirectAdmin, którego domyślna konfiguracja powoduje pokazywanie „zaślepki” przy braku podpiętego certyfikatu SSL. Potem było już tylko weselej, bo w dyskusji na Wykopie niektórzy sugerowali, że w zaślepkach powinien być w linkach atrybut nofollow. Uważam, że akurat brak nofollow świadczy w tym przypadku na korzyść zenbox.pl i braku celowego działania – gdyby ktoś zawracał sobie głowę atrybutami czy anchor text (a są i tacy), to znaczy, że pomyślał o pozycjonowaniu.

Jeszcze bardziej dziwi mnie skupienie się na SEO i ominięcie sedna sprawy: nie chodzi o – celowe lub nie – wprowadzenie w błąd Google. Przede wszystkim mamy do czynienia z podmianą treści na stronie zamieszczonej w określonej domenie. Wątpię, by właściciele domen mieli wiedzę, że taka podmiana miała miejsce. Jeszcze bardziej wątpię w ich zgodę na takie działanie.

HTTPS zamiast HTTP niewiele tu zmienia – oczywiście jest możliwość serwowania różnych treści w zależności od protokołu, podobnie jak strona z przedrostkiem www (de facto subdomena) z technicznego punktu widzenia może kierować zupełnie gdzie indziej, niż domena bez takiego przedrostka, ale przyjęte jest, że kierują w to samo miejsca. W przypadku HTTPS jest to IMO wręcz oczywiste.

Pamiętajmy też, że strony WWW, zwłaszcza popularniejsze blogi, potrafią po prostu sprzedawać miejsce na reklamę na stronie. Wydaje mi się, że w przypadku takich blogów wykazanie szkody w sądzie byłoby trywialne. Dlatego podejście zenbox.pl do sprawy mnie dziwi. Jak widać w komentarzach na blogu, mamy kolejno:

  1. straszenie „na takie działania godzić się nie można i zrobimy wszystko aby takie akcje miały konsekwencje”
  2. negacja, najpierw problemu w ogóle (screenshot w ww. wpisie), potem wpływu „działania nie mają wpływu na pozycję stron klientów ani wpływu na pozycję witryny zenbox.pl”
  3. przyznanie istnienia problemu „wspomnianego problemu nie doświadczyli” i w końcu podjęcie działań (zmiana konfiguracji, mailingi)

Wydaje mi się, że znacznie bardziej na miejscu byłaby analiza sytuacji, podziękowanie za zwrócenie uwagi, naprawienie problemu (poprawa konfiguracji) i przeproszenie klientów.

Cała sprawa ma jeszcze jeden ciekawy aspekt. Wydaje mi się, że największy błąd popełniło… Google, które podmienioną treść na stronie jak widać łyka jak pelikan. Mimo ewidentnych błędów HTTPS (certyfikat nie pasuje do domeny), które m.in. przed taką podmianą miały chronić. W czasach, gdy każda domena może mieć rozpoznawany przez przeglądarki certyfikat SSL za darmo (oczywiście chodzi o projekt Let’s Encrypt) strony za niepasującymi, wygasłymi i self signed certyfikatami powinny po prostu być ignorowane.

Prawidłowa konfiguracja to IMHO ta sama treść dostępna po HTTP i HTTPS. Czy to za sprawą odpowiedniego przekierowania (to sensownie uda się tylko z HTTP na HTTPS…), czy też – zwł. na shared hostingu – pod certyfikatem hostingodawcy, jeśli domena nie ma własnego.

2 odpowiedzi na “Jak zenbox.pl z domen klientów korzystał”

  1. Prawidłowa konfiguracja kieruje na oddzielne katalogi dla http i https aby nie było sytuacji, gdzie ruch http trafia na kod przeznaczony dla szyfrowanego połączenia. I tutaj tak było… public_html private_html oba miał zaślepki…

    lh na które powoluje sie czarek świeci na cały świat wersją serwera… Informując, że serwer jest podatny na buffor overflow i DDoS oraz suEXEC – Privilege Elevation

  2. @Admin15151 Przypominam, że mamy XXI w. Rozdzielanie serwowanych treści ze względu na protokół ma sens w jakimś… promilu przypadków. A „kod” sam może sprawdzać, po jakim protokole nastąpiło połączenie. Od dawna zalecany jest HTTPS (nie jestem fanem, ale takie są fakty), istnieją rozszerzenia do przeglądarek automatycznie przekierowujące na HTTPS, jeśli jest dostępny dla danej domeny (dla Firefox: HTTPS everywhere, Smart HTTPS, HTTPS by default) i ogólnie i ludzie, i boty spodziewają się tej samej treści na danej stronie, niezależnie od protokołu. No i google premiuje/ma premiować strony z HTTPS.

    Zastanawia mnie jeszcze jedna rzecz, na którą wcześniej nie zwróciłem uwagi: z zamieszczonych screenów wynika, że linki do zenbox.pl zaczęły być indeksowane dopiero pod koniec 2015…

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *