Wprowadzenie
W dzisiejszym odcinku porozmawiamy sobie o doborze systemu CMS do pozycjonowania. Powiem Wam, jaki system. Podpowiem Wam, jaki system CMS możecie wybrać i czy w ogóle to jest ważne oraz pokażę Wam, jak podejść do samego tematu wyboru CMS-a pod kątem właśnie pozycjonowania.
To wideo zaczniemy od krótkiego wprowadzenia, w którym powiem, czym w ogóle jest taki system CMS, bo nie wszyscy mogą wiedzieć. CMS to po angielsku po prostu content management system, czyli system zarządzania treścią i tyle. Chodzi o to, żeby zarządzać sobie treścią w jakiś prosty sposób.
Podstawowe warstwy CMS
Na pewno znacie WordPressa, ewentualnie jakiegoś Drupala, Joomlę. Jeżeli chodzi o takie webowe aplikacje, to na przykład Wix, Webflow i tak dalej. Jeżeli chodzi o sklepy internetowe, na przykład Presta, Shoper, Magento i wiele innych systemów do zarządzania, dodawania produktów i tak dalej.
Głównym celem takiego CMS-a jest to, aby użytkownik nie musiał znać HTML-a do tworzenia stron, bo każda strona składa się z jakiegoś kodu HTML, CSS, JavaScript i ewentualnie jakiegoś języka programowania. HTML odpowiada za dane ustrukturyzowane w jakiś sposób, CSS za ich wygląd, czyli jak to wszystko widzimy, ewentualnie JavaScript za ładowanie, jakieś dynamiczne zmiany na stronie i tak dalej.
I gdyby nie system CMS, to każdy właściciel strony musiałby umieć programować, pisać HTML-a, zajmować się CSS-ami, graficznie to przygotowywać i tak dalej, i wyklikać sobie to w jakiś plikach, w jakichś programach do edycji kodu i wrzucać to na serwer i działać tak.
A dzięki systemowi CMS po prostu logujemy się do jakiegoś panelu administracyjnego danego CMS-a i wyklikujemy sobie to, co jest nam potrzebne. Dodajemy jakieś strony, jakieś sekcje i tak dalej. I wcale nas nie obchodzi, jak ten HTML, CSS i inne rzeczy się generują. Teoretycznie każdy prosty użytkownik, który nie ma pojęcia o tym wszystkim, jest w stanie z takiego CMS-a korzystać, dodać jakąś stronę, jakąś treść i to będzie opublikowane, widoczne w internecie.
Tak, i na tym polega CMS, że oszczędza nam czas i nie musimy mieć jakiejś szerokiej wiedzy, żeby tym wszystkim zarządzać. No bo tworzeniem stron zajmują się programiści, a ludzie od zarządzania treścią mogą tylko po prostu łatwo i przyjemnie zarządzać treścią. Więc z mojej definicji to jest CMS i na bazie tego możemy sobie przejść dalej.
Kolejną bardzo ważną rzeczą związaną z CMS-em, jaki by on nie był, jest to, że każdy CMS ma pewnego rodzaju warstwy technologiczne. I to jest bardzo ważna rzecz w kontekście tego odcinka, bo o tym będzie troszeczkę później. Najpierw jednak poznajmy te warstwy.
Pierwszą warstwą jest tak zwany silnik danego CMS-a, ewentualnie ktoś na to może powiedzieć core, nie ma znaczenia. Chodzi tu o to, że to jest cały system zarządzania, jeżeli chodzi o funkcjonalności, o bezpieczeństwo, o logowanie i tak dalej. Cała logika, jeżeli ktoś się zaloguje tutaj, to ma się stać to i tak dalej. Cała ta logika jest trzymana właśnie w takim silniku. To ten silnik instaluje się na serwerze, wypakowuje się, potem go uruchamia i po prostu to działa. Dzięki temu możemy się zalogować i tak dalej.
Druga warstwa to warstwa bazy danych, czyli po prostu jest sobie obok jakaś baza danych, która trzyma wszystkie dane, nasze opcje, co tam sobie wyklikujemy i tak dalej. To się wszystko zapisuje, bo to musi się gdzieś zapisywać. To trafia po prostu do zwyczajnej bazy danych, a oprócz tego w tej bazie wszystkie treści, wszystkie wpisy blogowe, treści podstron i te wszystkie inne rzeczy, które dodajemy na stronie, też są w tej bazie.
Jeżeli nagle stracimy albo usuniemy całą bazę danych, to nasza strona zostanie, ale będzie pusta.
Po prostu mówiąc tak wprost, trzecią warstwą i ostatnią, a zarazem najbardziej widoczną, jest warstwa prezentacji danych, czyli po prostu ten wygenerowany kod HTML, który jest jakoś ostylowany za pomocą CSS, ewentualnie pojawiają się w nim jakieś funkcjonalności JavaScriptowe. W tym kodzie zawierają się elementy przechowywane w bazie danych.
Mamy widok jakiegoś wpisu na blogu i w środku tego widoku mamy tekst, który jest właśnie w bazie danych. Tak, i teraz tak naprawdę, wchodząc na stronę, widzimy tylko to. Nie widzimy silnika CMS-a, widzimy jedynie to, co jest przechowywane w bazie danych, tekst, obrazy, treści, oraz kod HTML, który się wygenerował.
Ani człowiek, ani Google nie mają dostępu do samego systemu zarządzania treścią, czyli do CMS-a. Oczywiście oprócz właściciela strony. Nie jesteśmy więc w stanie zalogować się do czyjegoś CMS-a i zmienić mu coś na stronie albo zmienić sobie cenę jakiegoś produktu przed zakupem. Oczywiste, prawda?
W zasadzie, bez doświadczenia, nie jesteście w stanie ocenić, jaki CMS odpowiada za daną stronę. Możecie zobaczyć jakąś stronę internetową i nie wiedzieć, czy jest na WordPressie, czy na innym systemie. Ktoś bardziej doświadczony będzie w stanie to określić po kodzie, sposobie generowania treści i tak dalej, ale teoretycznie nie jest to możliwe do rozpoznania na pierwszy rzut oka.
Google też nie obchodzi, jakiego CMS-a używacie. Oczywiście, może go rozpoznać i czasami to robi, ale tak naprawdę nie ma to dla niego znaczenia. Google interesuje tylko informacje wyciągnięte z bazy danych, czyli treści, oraz sposób ich prezentacji użytkownikowi.
To, co dzieje się „pod maską” strony, czyli jak edytujecie treści, w jakim panelu CMS pracujecie, jakie widzicie tam zielone lampki i podpowiedzi, nie ma żadnego znaczenia dla Google. Wyszukiwarka widzi tylko to, co widzi użytkownik. Czyli jeśli wylogujecie się z CMS-a i wejdziecie na swoją stronę, to dokładnie tyle samo zobaczy robot wyszukiwarki.
Mity i rzeczywistość, czyli wpływ CMS na pozycjonowanie
Już na tym etapie chciałbym obalić pewien mit, że jeden CMS lepiej się pozycjonuje od drugiego. Wiele osób mówi, że WordPress jest dobry pod SEO, ale to wcale nie jest prawda.
Każdy CMS będzie się pozycjonował tak samo. Różnica polega jedynie na wygodzie osoby obsługującej stronę. Czasami pewne zadania robi się szybciej i łatwiej, i dlatego mówi się na przykład, że WordPress jest dobry pod SEO.
WordPress domyślnie jest dobrze przygotowany, chociażby pod kątem generowania adresów URL. Nie ma w nim większych problemów z duplikacją, kanibalizacją treści i tak dalej. Po prostu to jest dobry CMS, jeśli chodzi o wygodę użytkownika. Nie jest wcale najlepszy, ale jest sprawnie działający.
Wybór motywu i rola page builderów
To, co chcę powiedzieć, to to, że jeśli dany CMS jest w miarę dojrzały, czyli nie jest jakimś systemem stworzonym w piwnicy tydzień temu, tylko jest rozwijany od lat, to będzie w porządku i nie ma tu żadnego problemu.
Problem z SEO i pozycjonowaniem leży zupełnie gdzie indziej, i o tym będziemy mówić zaraz. Teraz skupimy się na wyborze, a w zasadzie na tym, jak podejść do wyboru systemu CMS. Chciałbym porozmawiać o tym, co tak naprawdę jest ważne przy wyborze CMS-a, bo sam system nie jest aż tak istotny, jak mogłoby się wydawać.
Najważniejsza jest jego warstwa prezentacji, czyli to, co widzi użytkownik i Google, kod HTML, CSS, JavaScript. Każdy CMS ma swoje motywy, szablony, skórki, różnie to ludzie nazywają, ale nie ma to większego znaczenia.
Wchodzicie w galerię motywów i wybieracie to, co Wam odpowiada, układ, kolorystykę, styl. Motyw może być prosty albo bardzo zaawansowany. Można też napisać swój własny motyw, co jest ważne z punktu widzenia SEO.
Niestety, motywów jest bardzo dużo i ciężko wybrać odpowiedni. Jeśli chodzi o te warstwy, o których mówiliśmy wcześniej, to właśnie motyw tworzy tę ostatnią warstwę, czyli warstwę prezentacji.
To od motywu zależy, czy strona będzie optymalna pod kątem Google, czy nie. To właśnie tę warstwę widzi człowiek, widzi robot wyszukiwarki i od jakości motywu zależy, czy strona jest dobrze zoptymalizowana, czy nie.
Sam WordPress czy inny CMS jest tutaj totalnie neutralny. Liczy się to, jak został wdrożony motyw. Jeśli wybierzemy lekki, dobrze napisany zgodnie ze standardami WordPressa motyw, to po prostu będziemy mieli łatwiejsze zadanie w SEO.
Zwłaszcza jeżeli autor takiego motywu wiedział, co robi, jeśli chodzi o SEO, i dobrze wszystko przygotował. I nie mówię tutaj tylko o szybkości strony, ale o samej strukturze. Jak zbudowane jest linkowanie wewnętrzne? Czy na przykład linkuje się z nagłówków, czy jednak z atrybutów? A ewentualnie, czy w pewnych miejscach stosuje się linki nofollow?
To wszystko można zaplanować z góry na poziomie motywu. I takiego zwykłego Kowalskiego to wcale nie musi interesować, tak? Ewentualnie jakieś softy to poprawią, ale w miarę szybko. Najczęściej, jak wejdziecie sobie w galerię motywów, czy to w WordPressie, czy w innym miejscu, to bardzo trudno jest znaleźć coś dobrego.
A najgorsze są te płatne, które wydawałoby się, że będą lepsze. To najczęściej bardzo duże kombajny z olbrzymią ilością opcji, z których w większości i tak nie skorzystacie. I to generuje więcej problemów niż korzyści.
To prawda, że w takim motywie można rzeczywiście wszystko wyklikać i dostosować, ale to generuje olbrzymią ilość kodu, który jest niepotrzebny, spowalnia stronę, powoduje wiele problemów, błędów i w efekcie po prostu nie da się na takim motywie funkcjonować na dłuższą metę.
Też wspomnę jeszcze o tak zwanych page builderach typu Elementor, Divi i tak dalej. W zasadzie nazwa nie ma większego znaczenia, bo wszystkie działają na podobnej zasadzie. Co do zasady, seowcy nienawidzą takich motywów opartych na page builderach.
W teorii wszyscy mówią to samo, że Elementor generuje ogromną ilość kodu, co spowalnia stronę, że nie da się jej przyspieszyć i tak dalej. Natomiast to wcale nie jest aż takim problemem i pod kątem SEO nie jest aż tak źle.
Tak, da się wypozycjonować stronę, która jest trochę wolniejsza i działa na Divi. My mamy takich klientów, było trudno, ale dało się to zrobić.
Natomiast główny problem tego typu motywów polega na tym, że one łączą warstwę bazy danych i warstwę prezentacji. W bazie danych, tam gdzie normalnie trzymamy content, tekst i inne treści, zamiast czystej treści znajduje się kod HTML generowany przez builder, który potem jest „wypluwany” na stronę.
I jeśli na przykład chcecie zmienić Elementora na zwykły motyw, to będziecie mieli ogromny problem ze sprzątaniem zbędnego kodu. Zamiast samej treści w polu przeznaczonym na nią w bazie danych znajduje się cała masa niepotrzebnego HTML-a, co zaśmieca stronę i powoduje wiele problemów.
W zasadzie taką stronę łatwiej jest postawić od zera, niż ją przebudowywać i rozbudowywać. A to będzie ważne w kontekście tego, o czym będę mówił za chwilę. Więc nie po to rozdziela się wszystkie elementy strony na osobne warstwy, żeby potem wrzucać je do jednego worka, mieszać wszystko i w efekcie psuć stronę.
Te aplikacje po prostu uzależniają użytkownika od siebie. Potem ciężko z nich wyjść, trzeba kombinować, zalepiać błędy i problem robi się coraz większy. Trzeba się liczyć z tym, że jeśli zdecydujecie się na zmianę takiego motywu na inny, to w praktyce oznacza to konieczność przebudowy całej strony od zera.
Drugim problemem takich page builderów jest zarządzanie treścią. Jeśli słuchacie mnie regularnie, to wiecie, że strony pod SEO muszą mieć dość rozbudowaną strukturę, wiele podstron odpowiadających na konkretne potrzeby potencjalnych klientów i tak dalej.
To oznacza, że tych podstron realnie jest dużo. I teraz wyobraźcie sobie, że macie 100 podstron na każde miasto w Polsce, bo oferujecie jakąś usługę lokalną.
Przykładowo, stworzyliście stronę „Usługi Warszawa”, potem skopiowaliście ją 100 razy, zmieniając tylko nazwę miasta, i tak funkcjonujecie. Nawet ruch z tego jest, strona się indeksuje i wszystko wydaje się działać.
I nagle potrzebujecie zmienić wygląd jednej strony, ale globalnie, jeśli chodzi o szablon, i czasami się nie da. Zwłaszcza jeśli to jest ta sekcja z unikalnym tekstem, który jest ważny. I co wtedy? Trzeba 100 razy przeklikać wszystko ręcznie, wykonywać różnego rodzaju gimnastykę, czasami spędzić godziny na poprawieniu jednej rzeczy.
No bez sensu, tak? Niestety, ale ręczna robota razy sto może się tutaj zdarzyć.
Albo inny przykład, macie bardzo dużo usług, na przykład 34, i one muszą jakoś między sobą linkować, bo linkowanie wewnętrzne na tym polega. I gdy budujemy 35. podstronę, nagle musimy ją też uwzględnić w linkowaniu.
I znowu trzeba wszystko przeliczyć, od nowa rozpisać i potem ręcznie przeklikać. A to bez sensu, bo to kolejna masa ręcznej roboty. Bez takich page builderów da się to zrobić w pełni automatycznie, tak, że dodanie nowej strony zajmuje 30 sekund, a nie 3 godziny albo i więcej.
I właśnie dlatego seowcy nienawidzą tych page builderów, bo to marnowanie czasu, który można by było poświęcić na rzeczy, które realnie wpływają na budowanie widoczności w Google.
Taki specjalista albo Wy jako właściciel strony, zamiast planować, optymalizować treści i myśleć strategicznie nad stroną, to w powtarzalny sposób klikacie coś strona po stronie, żeby coś poprawić.
Nic dziwnego, że potem Wam się odechciewa całego SEO, bo jest za dużo roboty, a efektów brak. Więc klikanie po panelu, żeby cokolwiek działało, nie jest do końca sensowne.
Ja wiem, że tak często to wygląda, bo sami mamy z tym problemy. Czasami trafia do nas klient z takim CMS-em i musimy sobie jakoś radzić. Musimy albo coś poprawić, albo zautomatyzować pracę.
Bo zamiast poświęcić 10 godzin na optymalizację, poświęca się 8 godzin na klikanie i 2 na optymalizację. I potem efekty są o wiele gorsze.
Dlatego jeśli chodzi o page buildery, to raczej jestem do nich negatywnie nastawiony, ale nie z tych powodów, o których mówią wszyscy, czyli szybkości i tak dalej, tylko ze względu na zarządzanie stroną.
Skoro już wyraziłem się negatywnie o page builderach, to teraz postaram się powiedzieć coś pozytywnego o innym rodzaju motywów. Dla mnie najlepszy motyw to taki, który został zaprojektowany pod konkretny biznes, a najlepiej taki, który powstał na bazie wcześniej zaplanowanej strategii SEO.
Wtedy praktycznie nie trzeba nic poprawiać na przyszłych stronach, bo od razu są dobrze zbudowane.
Taki motyw przede wszystkim ma minimalną ilość kodu, jest zoptymalizowany strukturalnie pod kątem SEO i zawiera na przykład zasady linkowania wewnętrznego zaplanowane specjalnie pod tę stronę i ten biznes.
Dzięki temu mamy o wiele mniej pracy, jeśli chodzi o SEO. Oczywiście pod warunkiem, że ktoś to dobrze zaprojektował. Bo jeśli ktoś sprzeda Wam „dedykowany” motyw, ale w rzeczywistości zbudował go na Elementorze, to niestety będzie problem.
Chodzi o to, żeby mieć realnie swój motyw, napisany od zera, czasami na bazie różnych motywów startowych, ale jednak dobrze zaplanowany. I najlepiej, jeśli ten motyw bazuje jeszcze na customowych polach, w których przechowujemy różne treści, informacje i tak dalej.
Dzięki temu można maksymalnie oddzielić warstwę logiki od treści i wyglądu. Chodzi o to, że pewne treści, które pojawiają się w różnych miejscach, jak na przykład menu, jakiś tekst, formularz i tak dalej, powinny być przechowywane w bazie danych, a nie w czystym HTML-u.
To znacznie ułatwia zarządzanie stroną i jej rozwój. Zobaczcie na przykładzie naszej firmowej strony. Na ekranie widzicie teraz jedną z pierwszych wersji oraz tę, która jest aktualna. I może trudno w to uwierzyć, ale to jest ciągle ta sama strona.
Wygląd się zmienił, treści się zmieniły, ale wszystko ewoluowało małymi kroczkami, a nie przez rewolucję co trzy lata, dwa lata czy rok. Ta strona ma już około 6 lat i co jakiś czas po prostu robimy drobne poprawki. Dzięki temu mamy pewną stabilność biznesową.
Raz poprawiamy grafikę i kolorystykę, raz treści, raz układ i tak dalej. I ciągle coś się zmienia, ale to wszystko w ramach jednego motywu, jednego CMS-a. Co więcej, nawet jeśli kiedyś będziemy chcieli zmienić szablon na całkowicie nowy, to wszystkie dane zostaną.
Wszystkie wpisy na blogu, wszystkie treści podstron, wszystkie inne informacje zapisane w bazie danych, wszystko zostaje i będzie można dla nich przygotować nowy motyw, nową grafikę.
I tym sposobem unikamy sytuacji, gdzie budujemy nową stronę i nagle ruch spada nam do zera, bo o czymś zapomnieliśmy albo nie uwzględniliśmy jakiejś treści. Treści to jedno, a ich reprezentacja to drugie.
Bardzo polecam takie dedykowane podejście. Oczywiście wiem, że na starcie jest droższe, ale długofalowo wychodzi taniej, bo późniejsza obsługa strony jest o wiele prostsza. Każda kolejna poprawka, każdy rozwój strony jest tańszy.
To, że płacicie więcej na początku, rozumiem. Natomiast potem, co dwa-trzy lata, o wiele łatwiej jest tę stronę modernizować, ewentualnie wprowadzając małe poprawki.
To nie jest tak, że co trzy lata robimy wielką rewolucję i zmieniamy stronę, tylko możemy wprowadzać jedną małą zmianę co miesiąc. I to jest o wiele lepsze podejście, zarówno biznesowo, jak i z punktu widzenia Google, klientów oraz ogólnie wszystkiego.
Więc jeśli macie stronę hobbystyczną, to może nie warto w to inwestować. Ewentualnie, jeśli prowadzicie mały lokalny biznes, to też niekoniecznie. Natomiast każda poważna firma powinna, moim zdaniem, podejść do tego w ten sposób, mieć dobry CMS.
To może być WordPress albo inny system, ale z bardzo dobrze przygotowanym szablonem pod dany biznes. Dzięki temu unikniemy wielu problemów, nie tylko tych związanych z SEO, ale także z wieloma innymi aspektami technicznymi samej strony.
CMS chmurowe kontra instalowane na własnym serwerze
Postawmy sobie jeszcze jedno ważne pytanie, CMS instalowany na własnym serwerze czy systemy chmurowe? Jedno i drugie ma swoje wady i zalety, dlatego warto o tym porozmawiać. Do tych instalowanych należą oczywiście WordPress, Joomla, Drupal, PrestaShop, Magento, jeśli chodzi o sklepy, i tak dalej.
Natomiast systemy chmurowe to na przykład Webflow, Framer, Wix, a nawet WordPress, bo on też może działać w chmurze. Wiem, że wrzuciłem tu różne rozwiązania do tylko dwóch kategorii, ale na potrzeby tego wideo to wystarczy.
Chciałbym Wam pokazać pewną przewagę systemów instalowanych lokalnie nad chmurowymi, które z mojej perspektywy, zwłaszcza pod kątem SEO, nie do końca się sprawdzają.
Już trochę o tym mówiłem, ale powtórzę, rozwiązania chmurowe mają ograniczenia, jeśli chodzi o skalę. Jeśli mamy jedną podstronę, zakładkę „Kontakt”, „Oferta” i nic więcej, to są świetne. Nie polecam w ogóle instalować WordPressa do tak prostej strony. My sami używamy takich narzędzi do budowania landing page’y pod kampanie Google Ads, bo to po prostu łatwiejsze.
Natomiast w SEO, gdzie liczy się struktura, zarządzanie globalne treściami, linkowanie wewnętrzne i tak dalej, systemy chmurowe zawsze będą przegrywać z klasycznym WordPressem instalowanym na własnym serwerze.
Na własnym serwerze można zrobić wszystko. Ważne są też koszty, bo własny hosting jest tańszy. Systemy chmurowe mogą generować o wiele większe koszty, szczególnie gdy mamy dużo podstron. Tutaj często cena rośnie wraz z ruchem na stronie.
Dla przykładu, jeden z naszych klientów z sektora IT miał stronę na Webflow. Wszystko było w porządku, dopóki strategia SEO nie pokazała, że potrzebujemy około 300 nowych podstron na konkretne usługi.
Nie ma znaczenia, jakie to były usługi, ważne, że wyglądały podobnie. Udało się to zrobić ogromnym wysiłkiem i mnóstwem godzin pracy. Następnie klient wpadł na pomysł ekspansji na rynki zagraniczne i chciał dodać wersję angielską strony. No i tutaj zaczęły się ogromne schody. Nie dało się tego zrobić na Webflow w sposób optymalny.
Ostatecznie jakoś to zrobiliśmy, kopiując stronę dwa razy i linkując między wersjami, ale to spowodowało kolejne problemy z hreflangami, czyli oznaczeniami wersji językowych dla Google. Przekierowania nie działały poprawnie i zamiast robić SEO, przez pół roku walczyliśmy z Webflow.
Dlatego uważam, że duże, rozbudowane strony powinny być budowane na własnym hostingu. To daje elastyczność, znacznie łatwiejsze zarządzanie i mniejsze koszty. A przecież o to chodzi. Nawet sam WordPress w wersji chmurowej jest po prostu do wyrzucenia, nie polecam go używać.
Jeśli chcecie korzystać z WordPressa, to tylko i wyłącznie w wersji instalowanej na własnym serwerze. Zakładam, że jeśli dotrwaliście do tego momentu wideo, to możecie mieć pewien mętlik w głowie.
Rozwiązaniem w większości przypadków jest typowy, standardowy WordPress z dedykowanym szablonem, jeśli to możliwe. Ewentualnie, jeśli nie, to przynajmniej z jakimś lekkim szablonem, a nie wielkim kombajnem typu Elementor czy Divi.
Oczywiście WordPress nie jest idealny, ma swoje minusy, ale z punktu widzenia mnie jako seowca to nadal najlepszy system do rozwoju, pozycjonowania i generowania ruchu przez różnego rodzaju strony usługowe, które muszą się skalować i rozwijać strukturalnie, żeby mieć z tego ruch. Jeśli mamy dobrze przygotowany motyw, to będzie to naprawdę dobry wybór.
Domyślnie WordPress jest dobrze przystosowany pod SEO, zwłaszcza jeśli chodzi o budowanie adresów URL i inne podstawowe rzeczy. Nie musimy się tym szczególnie przejmować, to jest dobrze rozwiązane.
Mamy szeroki wybór wtyczek do SEO. Oczywiście nie można z nimi przesadzać, ale dostępnych jest naprawdę wiele dobrych narzędzi. W WordPressie dane są oddzielone od wyglądu, więc motywy można potem łatwo zmieniać. Do tego wszystkiego WordPress nadal jest tani, da się go szybko rozbudować i w miarę łatwo skalować, jeśli motyw jest dobrze przygotowany.
No i w Polsce mamy dużo specjalistów od WordPressa. To nie jest tak, że jak zniknie jeden freelancer, to nagle trzeba robić stronę od nowa. Zawsze można znaleźć kogoś, kto przejmie projekt i będzie go kontynuować. A to wpływa na cenę projektu, to po prostu najtańsze rozwiązanie.
Hosting też nie jest drogi. Hosting za kilkaset złotych rocznie to na pewno tańsza opcja niż rozwiązania chmurowe, gdzie przy większej skali po prostu płaci się dużo więcej. Oczywiście WordPressa nie polecam do wszystkiego. Dla naprawdę bardzo dużych stron trzeba już mieć własne rozwiązania, nie będę o tym mówił, bo właściciele takich stron raczej nie oglądają mojego kanału.
Natomiast jeśli chodzi o sklepy internetowe, to również nie polecam WordPressa. Owszem, dla małego sklepiku sprzedającego np. cztery produkty cyfrowe WordPress jest okej. Natomiast jeśli chcecie zbudować większy sklep internetowy z fizycznymi produktami, to WordPress nie jest najlepszym wyborem.
Chociaż WooCommerce działa całkiem dobrze, to są lepsze i tańsze rozwiązania chmurowe. W przypadku sklepów struktura zawsze wygląda podobnie, mamy kategorie, produkty i wszystko w gotowych motywach. W systemach takich jak Shoper, Magento czy PrestaShop jest to już dobrze przemyślane. Ale to temat na inny odcinek, więc nie będę go tutaj rozwijać.
Natomiast jeśli chodzi o strony usługowe, firmowe, najlepszym rozwiązaniem z perspektywy pozycjonowania będzie właśnie WordPress. I tym chciałem Was dzisiaj zostawić.
Podsumowanie
Podsumowując ten dość rozbudowany materiał, chciałbym przypomnieć, że system CMS ma kilka warstw, warstwę silnika, warstwę bazy danych i warstwę prezentacji. I to w warstwie prezentacji będziemy pracować najwięcej, więc to na niej musimy się skupić.
Sam wybór CMS-a nie jest tak ważny jak wybór szablonu, który będzie odpowiadał naszym potrzebom. Na etapie wyboru musimy zwrócić uwagę, żeby był to sprawny, lekki motyw, a nie wielki kombajn typu Elementor, Divi czy inne podobne narzędzia. Rozwiązania chmurowe są dobre do małych stron, których nie trzeba skalować.
Jeśli ktoś chce zrobić tylko stronę główną i nie planuje jej pozycjonować, to będzie to prostsze rozwiązanie. To nie znaczy, że te systemy są słabe, nie chodzi o to, że Google ich nie indeksuje czy że technologia jest zła. Problemem jest to, że przy rozbudowie i skalowaniu takich stron pojawiają się ograniczenia.
Nie zawsze można dodać kolejną wersję językową, rozbudować stronę czy zarządzać nią tak, jak byśmy chcieli. I właśnie dlatego w przypadku stron, które mają się rozwijać i generować ruch, nie polecam systemów chmurowych. WordPress będzie tutaj najlepszym wyborem, jest łatwy w obsłudze i można go w miarę dobrze skalować.
