Prestashop moduł bloga

Odpuść sobie domyślny moduł blogowy Prestashop; te komercyjne o rozpiętości od 40 do 70 euro zresztą też. Jeśli chcesz pozyskiwać ruch do swojego sklepu z wyszukiwarek, to WordPress osadzony w folderze /blog/ albo w subdomenie blog. będzie znacznie lepszym pomysłem. Dlaczego? O tym dziś, ale zanim – upewnij się, że subskrybujesz nasz kanał, masz włączone powiadomienia o nowych materiałach, tymczasem zaczynamy.

Powodów, dla których stosowanie darmowego, podstawowego modułu blogowego dla Prestashop, ale i tych komercyjnych, dostępnych w oficjalnym sklepie Prestashop jest słabszą opcją od zwykłej instancji WordPressa jest całe mnóstwo.

Po pierwsze – zarządzanie blogiem, który ma swój kod, czyli kod, który jest odseparowany, „odklejeny” od CSS’, HTML’a i PHP’a Presty jest po prostu wygodne. Przerabialiśmy wiele modułów blogowych do Presty i zasadniczo – żaden funkcjonalnie nie zbliżał się do tego, co obsłużycie WordPressem.

Kiedy osadzicie bloga na WP’ku, macie do dyspozycji zupełnie osobną instancję, której modyfikacje, dokładanie i zdejmowanie komponentów nie wpływa na funkcjonowanie samego sklepu. Jako, że moduły blogowe dostępne dla Presty bazują na kodzie Presty, to poukładanie semantyki kodu bloga bywa źródłem frustracji. Widoki Presty dziedziczą po sobie i przewidywanie tego, jak zmodyfikowanie funkcji X na blogu wpłynie na widoki e-commerce’u nie daje komfortu psychicznego. Prestashop ma sporo mało oczywistych mechanik także w kontekście SEO i kontrolowanie tego, jak np. wygląda linkowanie wewnętrzne między wpisami na blogu albo czy title strony głównej nie będzie multiplikowany na wszystkich widokach wpisów na blogu może nie są dużymi disruptorami, to takich detali na poziomie mikro jest tak wiele, że rozwiązywanie tych problemów i dywersyfikacja kodu po to, aby blog nie implikował na sklep, i sklep na bloga nie są po prostu warte pracy dewelopera i właściciela, menadżera sklepu. To wszystko.

Już sam fakt tego, że deweloper nie musi modyfikować kodu w taki sposób, aby blog miał inną, swoją architekturę informacji, a nie tę architekturę powtórzoną, odziedziczoną po sklepie jest już wystarczającym argumentem, żeby rozważać osadzenie bloga na WP’ku.

Pomijam już fakt, że WordPress jest po prostu lepszym środowiskiem do obsługi contentu – liczba komponentów, o które można WordPressa rozszerzyć jest nieograniczona, a i połączenie Presty z WordPressem też nie nastręcza większych trudności. Zaciąganie zawartości w obie domeny, tj. między WordPressem a Prestą i między Prestą i WordPressem jest możliwe po API, więc czy to wyświetlanie produktów we wpisach na WordPressie, czy tez wyświetlanie ostatnich wpisów na stronie głównej sklepu na Prestashop jest proste w implementacji.

Ostatecznie – gdyby do tego tematu podejść jeszcze z innej strony, to najłatwiej byłoby operować po prostu na samym WooCommerce, czyli WordPressie zaadaptowanym do celów e-commerce. Wtedy zarówno zamówienia, jak i zarządzanie blogiem mogą być obsłużone w jednym miejscu, dlatego, jeśli nadal nie podjąłeś ostatecznej decyzji w wyborze technologii dla swojego sklepu, to zapraszam do obejrzenia materiału: „WooCommerce czy PrestaShop?”, a jeśli padło ostatecznie na PrestaShop, to pozostaje odpowiedzieć na pytanie:

Folder czy subdomena?

Scenariusze są dwa, tj. albo folder, czyli nazwasklepu.pl/blog/ albo subdomena, czyli blog.nazwasklepu.pl. Które z tych rozwiązań jest lepsze i dlaczego?

Do rozważenia mamy dwa konteksty – bezpieczeństwo i kontekst SEO.

SEO

Gdybym miał oceniać sam kontekst SEO, to powiedziałbym, że rozwiązaniem lepszym jest rzecz jasna folder, ponieważ WordPress postawiony w folderze odziedziczy autorytet domeny, w jakiej jest osadzony. W takim scenariuszu blog jest integralną częścią serwisu, w tym przypadku sklepu na Prestashop. Z kolei gdybyśmy postawili tego bloga w subdomenie, to subdomena jest traktowana przez GoogleBota jako zupełnie osobny serwis, osobna domena, historia.

Obrazowo – zakładając, że Twój sklep ma rok, dwa lata, to czysto teoretycznie, publikując na nim artykuł w folderze pt. „Jak wyczyścić płytki w łazience?”, masz szansę już na starcie – na takie zapytanie do Google zająć pozycję 20., 30., 40 na dzień dobry.

Z kolei ten sam artykuł opublikowany w subdomenie bez żadnej historii, czyli blog.nazwasklepu.pl wyląduje na zapytanie „jak wyczyścić płytki w łazience” poza TOP 100. A to dlatego, że tak, jak wspomniałem – subdomena nie dziedziczy żadnych wartości dodatnich po domenie, w jakiej jest osadzona. Żebyście to dobrze zrozumieli – lata temu, kiedy na polskim rynku popularne były jeszcze darmowe subdomeny, aliasy, to fakt posiadania bloga w subdomenie serwisu zarządzanego przez np. przez grupę Onet – mówię o subdomenach serwisu blog.pl był powszechny i to, że założyłbym bloga w subdomenie tego mocnego w ówczesnym czasie serwisu blog.pl w żadnym razie nie implikowało dodatnio na „pozycje startowe” w wyszukiwarkach. Oczywiście subdomena nie jest tak totalnie odklejona od szerszego kontekstu, bo czysto teoretycznie o ile zbanowanie subdomeny nie wpływa na domenę, w której jest osadzona, to zbanowanie całej domeny oczywiście usuwa z indeksu też subdomenę, ale to nie jest czas i miejsce na rozmowy temat permanentnych banów, które są nota bene już dziś prawdziwą rzadkością. I mówię o banach, a nie penalizacjach, filtrach algorytmicznych lub ręcznych – to zupełnie inny temat.

Ale wracając – sam fakt, że jeśli osadzić bloga na WP w folderze – zajmujesz od razu lepsze pozycje startowe w wyszukiwarkach, to do rozpatrzenia jest wciąż jeszcze jeden kontekst, kontekst bezpieczeństwa.

Bezpieczeństwo

Co do zasady WordPress jest skryptem bardziej narażonym na ataki niż Prestashop. To kwestia skali – liczba domen, które korzystają z WordPressa jest tak duża, że wybrane wtyczki są regularnie poddawane testom bezpieczeństwa. Żeby daleko nie sięgać, miesiąc, półtora miesiąca temu jedna z typowych wtyczek obsługujących formularz kontaktowy dla WordPressa Contant Form 7 miała poważną lukę; ile WordPressów zostało w jej wyniku zainfekowanych, tego nie wiadomo. Wiadomo natomiast to, że na całym świecie z tej wtyczki korzysta ponad 5 milionów stron osadzonych na WordPress, więc skala problemu była, a dla wielu – pewnie nadal jest – imponująca w negatywnym tego słowa znaczeniu.

Skuteczny atak na WordPressa, jego wtyczkę ma swoje implikacje na SEO. Analogicznie, jak w przypadku korzyści płynących z osadzenia WP’ka w folderze, to rozwiązanie jest bronią obosieczną. Jeśli blog będzie osadzony w folderze, a ulegnie atakowi, będzie to oddziaływało na zasięg w wynikach organicznych Google dla całej domeny, czyli i bloga, i sklepu jako całości. I analogicznie – gdybyśmy rozmawiali o blogu w subdomenie to taki ewentualny atak pociągnie za sobą ewentualne konsekwencje tylko dla subdomeny, więc w takim scenariuszu sklep nadal żyje swoim życiem i nie nabywa ujemnej historii.

A mówię o tym, bo z atakami na WordPressa jest zwyczajowo tak, że nikt nie bawi się już specjalnie w osadzanie na takim zainfekowanym WordPressie malware’a albo aplikacji, która kopie BTC, bo jest to łatwe do wychwycenia albo przez samych użytkowników, albo przez właściciela, menadżera sklepu albo samego hostingodawcę, administratora serwera. Znacznie częstszym scenariuszem jest ten, w którym to atakujący zdobywa dostęp do WordPressa i w jego wyniku zaczyna publikować ukryte, niewidoczne na pierwszy rzut oka publikacje, z których pozyskuje linki do swojej domeny. W efekcie – może minąć wiele tygodni zanim ktokolwiek zorientuje się, że doszło do infekcji – a w takim scenariuszu co prawdopodobne – jako pierwsze zorientuje się agencja SEO, która obsługuje sklep – obserwując indeksację nietypowych URL’i w Google i/lub reaktywnie przyglądając się spadkom, ujemnym korektom w zasięgach organicznych Google. A scenariusz rozwiązania tego problemu, tj. kiedy domena otrzyma penalizację albo po prostu zostanie wyeksploatowana w kontekście SEO ze względu na wysoki OBL, czyli dużą liczbę linków wychodzących – nie jest proste, tani ani szybkie w „odkręceniu”.

Rzecz jasna ataki na bloga na WP da się ograniczyć, nie nadużywając zewnętrznych komponentów, wtyczek do rzeczy, które można napisać ręcznie w PHP’ie albo JavaScript’ie, wprowadzając podwójne uwierzytelnienie do panelu logowania, ochronę przed brute-force, zmieniając adresację tabel z WP_ na cokolwiek innego itd., to wciąż – tego scenariusza nie można wykluczać -a to ma szczególnie duże znaczenie, kiedy rozmawiamy o większych organizacjach, bo kiedy firma jest mała, jej przychód nie jest zbudowany wokół wyników organicznych (pomijam fakt, że w ogóle nie powinno wsadzać się wszystkich jaj do 1 koszyka), to problem bezpieczeństwa bywa w tym kontekście drugorzędny, bo kiedy nic jeszcze nie zostało zbudowane, nie ma czego stracić, to z czasem może być to wątek wymagający poddania pod dyskusję.

Ostateczna ocena tego, czy bloga na WP instalować w folderze, czy subdomenie powinna być oceniona przede wszystkim na poziomie właścicielskim, biznesowym. Ważne, żeby to był WP, lub jakikolwiek elastyczny, programowalny CMS, który dobrze znacie.

Tymczasem dzięki bardzo za uwagę, mówił do Was Adrian Pakulski Paq, widzimy się już niebawem, do następnego, cześć.