Trzy problemy SEO, które klient zgłaszał od miesięcy - i jak zniknęły przy migracji na Intum CMS

Najlepsze zgłoszenia od klientów to takie, w których ktoś od dawna wie, co jest nie tak, tylko nie ma jak tego naprawić. Tak zaczęła się migracja strony gabinetu okulistycznego dziecięcego w Warszawie ze starego Siteora na Intum CMS.

Klient przyszedł nie z hasłem „zróbcie mi nową stronę", tylko z listą trzech konkretnych problemów, które obserwował od miesięcy. Wszystkie trzy okazały się prawdziwe i wszystkie trzy dały się naprawić przy okazji przenosin.

Problem pierwszy: własna strona konkurowała sama ze sobą

W wynikach Google obok głównej domeny pojawiała się jej kopia pod adresem technicznym starego systemu. Ta sama treść, dwa adresy - klasyczna sytuacja, w której wyszukiwarka musi zgadywać, którą wersję pokazać, i czasem wybiera tę gorszą.

Po migracji każda podstrona wskazuje samą siebie jako wersję właściwą. Adres techniczny przestaje istnieć jako konkurencja, a po wygaszeniu starego serwisu przekierowanie prowadzi ruch tam, gdzie powinien trafiać. Ścieżki podstron zostały zachowane jeden do jednego, więc pozycje przechodzą płynnie, bez okresu przestoju w indeksie.

Problem drugi: robot Google widział przyciski administratora

Na starej stronie linki „Dodaj artykuł" i „Edytuj artykuł" renderowały się w kodzie także dla niezalogowanych - czyli dla zwykłych odwiedzających i dla robotów wyszukiwarek. Wyglądało to nieprofesjonalnie, a przy okazji zaśmiecało to, co Google widzi na stronie.

W nowym systemie pasek edycji i skrypty administracyjne wstrzykiwane są wyłącznie wtedy, gdy oglądający ma uprawnienia do zarządzania treścią. Anonim i crawler nie dostają ich wcale.

Problem trzeci: podwojony tytuł

Tytuły podstron w wynikach wyszukiwania wyglądały jak „Nazwa gabinetu - Nazwa gabinetu", bo nazwa firmy była doklejana dwa razy: raz w szablonie, raz w tytule podstrony. To drobiazg, który kosztuje realne kliknięcia, bo w wynikach wyszukiwania zjada miejsce na treść.

Teraz nazwę dokleja wyłącznie szablon, a tytuł podstrony niesie samą frazę. Krótko i bez powtórzeń.

Wygląd został, bo był dobry

Osobna sprawa, o którą klient bał się najbardziej: że przy migracji zgubi wygląd, który świadomie wybierał. To realna obawa i traktujemy ją poważnie.

Układ, kolory i typografia zostały odtworzone jeden do jednego, tyle że na nowoczesnym silniku. Jedenaście podstron, dziewięć wpisów bloga z pełną treścią, dwadzieścia dziewięć zdjęć przekonwertowanych na format WebP i przeskalowanych do rozsądnych rozmiarów - bo stare pliki ważyły po kilka megabajtów każdy. Zewnętrzny system rezerwacji wizyt został podpięty tak, jak działał wcześniej.

Efekt: pacjent nie zauważa, że coś się zmieniło. Zauważa tylko, że strona ładuje się szybciej.

Czego nie było wcześniej

Przy okazji doszło to, czego stara strona nie miała w ogóle. Opisy meta dopracowane dla każdej podstrony osobno - tu warto dodać, że klient przysłał własne wersje i były lepsze od naszych, więc poszły jego. Tagi Open Graph, żeby link wysłany rodzicom w wiadomości pokazywał się z podglądem.

I dane strukturalne placówki medycznej: nazwa, adres, współrzędne geograficzne, godziny przyjęć, zakres cen, telefon, profil społecznościowy. To dzięki nim wyszukiwarka może pokazać gabinet z godzinami otwarcia bezpośrednio w wynikach i lepiej dopasować go do zapytań lokalnych, czyli takich, od których zaczyna większość rodziców szukających lekarza dla dziecka.

Mapa witryny i plik llms.txt, czyli opis strony dla asystentów AI, generują się automatycznie. Nowy wpis na blogu sam do nich wpada.

Najlepszy dowód, że się udało

Nie jest nim żaden wykres. Jest nim to, co klient zrobił kilka dni po uruchomieniu, bez pytania nas o zgodę.

Napisał i opublikował nowy artykuł. Zmienił adres jednej z podstron - i, co najbardziej nas ucieszyło, sam założył pod starym adresem przekierowanie i wyłączył je z mapy witryny, dokładnie tak, jak się to robi poprawnie. Dodał nową podstronę z własną strukturą. Poprawił treść we wszystkich wpisach bloga.

To jest moment, w którym wdrożenie się kończy. Nie wtedy, gdy strona rusza, tylko wtedy, gdy właściciel przestaje potrzebować pośrednika, żeby cokolwiek na niej zmienić.

Co z tego wynika dla innych

Migracja ze starszego systemu rzadko sprowadza się do przeniesienia treści. Prawie zawsze pod spodem leży kilka rzeczy, które właściciel od dawna zgłaszał, a które nie dawały się naprawić bez zmiany silnika - duplikaty adresów, elementy panelu widoczne publicznie, tytuły sklejane w złej kolejności.

Warto zacząć od spisania tych problemów, zanim ktokolwiek zacznie rysować nowy layout. Często okazuje się, że nowy wygląd wcale nie jest potrzebny - wystarczy ten sam wygląd na fundamencie, który nie pracuje przeciwko stronie.