Enterprise SEO – widoczność organizacji działających w wielu krajach i technologiach

WordPress

Rozwiązanie o największym udziale w rynku systemów zarządzania treścią, obecne również w portfelach korporacyjnych — zwykle jako podstawa serwisów wizerunkowych, redakcyjnych i krajowych. Zaletą jest pełna kontrola nad warstwą prezentacji i nad generowanym kodem, dostępność kompetencji na rynku pracy oraz rozbudowane zaplecze rozszerzeń.

Przy zastosowaniach korporacyjnych wymaga uporządkowania trzech obszarów. Pierwszym jest zarządzanie rozszerzeniami: w serwisach prowadzonych latami narastają one w liczbie utrudniającej utrzymanie i wpływającej na wydajność. Drugim jest wydajność, zależna w większym stopniu od warstwy buforującej i od infrastruktury niż od samego systemu. Trzecim jest bezpieczeństwo — nieaktualne rozszerzenia pozostają najczęstszą drogą naruszenia integralności serwisu.

W projektach obejmujących wiele serwisów krajowych sprawdza się konfiguracja wielowitrynowa z centralnie zarządzanym standardem, przy jednoczesnej swobodzie redakcyjnej po stronie zespołów lokalnych. Wymaga to jednak rozstrzygnięcia, kto odpowiada za aktualizacje i za zgodność ze standardem technicznym.

WooCommerce

Rozszerzenie sklepowe dla powyższego systemu, w portfelach korporacyjnych spotykane najczęściej w spółkach zależnych i na rynkach o mniejszej skali. Daje pełną kontrolę nad strukturą adresów, nad indeksacją filtrów i nad danymi uporządkowanymi, co przy standaryzacji portfela jest istotną zaletą.

Obszarem wymagającym nadzoru jest generowanie adresów przez mechanizmy filtrowania oraz obsługa produktów przypisanych do wielu kategorii. Przy większych katalogach wydajność zależy od poprawnie zbudowanej warstwy buforującej oraz od optymalizacji zapytań do bazy danych, co wymaga kompetencji wykraczających poza samą platformę.

Shopify oraz wariant korporacyjny

Rozwiązanie udostępniane w modelu usługowym, cenione za stabilność, szybkość działania oraz brak obciążeń związanych z utrzymaniem infrastruktury. Wariant przeznaczony dla dużych organizacji rozszerza możliwości integracyjne, obsługę wielu sklepów i wielu rynków oraz podnosi limity operacyjne.

Ograniczenia dotyczą swobody kształtowania struktury adresów oraz dostępu do warstwy serwerowej. Przy dużych katalogach odczuwalny bywa brak dzienników serwera, co zawęża diagnostykę do narzędzi udostępnianych przez wyszukiwarki. Warto również zweryfikować sposób obsługi produktów należących do wielu zbiorów oraz wskazywania adresu podstawowego.

Jest to rozwiązanie sensowne przy sprzedaży na wielu rynkach, przy nacisku na szybkość wdrożenia oraz przy organizacjach, które świadomie rezygnują z części kontroli w zamian za ograniczenie obciążeń utrzymaniowych.

Adobe Commerce

Platforma przeznaczona dla wdrożeń o wysokiej złożoności: wiele sklepów, wiele magazynów, rozbudowane reguły cenowe, złożone procesy sprzedaży oraz integracje z systemami klasy korporacyjnej. Zakres możliwości konfiguracyjnych należy do najszerszych na rynku.

Ceną jest złożoność utrzymania oraz wymagania infrastrukturalne. Wydajność zależy od poprawnie zbudowanej warstwy buforującej i od architektury wdrożenia — serwis uruchomiony bez tego pozostaje wolny mimo znacznych zasobów sprzętowych. W warstwie widoczności największym ryzykiem jest generowanie adresów przez nawigację warstwową w konfiguracjach, które nie zostały świadomie ograniczone.

PrestaShop

Rozwiązanie instalowane we własnej infrastrukturze, z rozbudowaną obsługą wielu języków i wielu sklepów w ramach jednej instalacji. W portfelach europejskich spotykane często w spółkach o średniej skali oraz na rynkach, na których ma ugruntowaną pozycję.

Wymaga uwagi przy nawigacji warstwowej oraz przy wydajności zapytań do bazy danych, która przy dużych katalogach bywa głównym ograniczeniem. Istotne jest również utrzymanie aktualnej wersji, ponieważ różnice między wydaniami bywają znaczące, a część rozszerzeń nie nadąża za zmianami.

Wix oraz Wix eCommerce

Platforma udostępniana w modelu usługowym, wywodząca się z kreatora stron, obecnie wyposażona w zestaw ustawień pozwalających na pracę nad widocznością: kształtowanie adresów, przekierowania, mapę witryny oraz sterowanie znacznikami. W portfelach korporacyjnych spotykana zwykle w serwisach kampanijnych, wizerunkowych i w spółkach o niewielkiej skali.

Ograniczenia ujawniają się przy dużych katalogach i przy rozbudowanym filtrowaniu, a także przy potrzebie ingerencji w sposób generowania kodu. Przy wdrożeniach obejmujących kilka rynków warto zweryfikować obsługę wersji językowych oraz sposób generowania danych uporządkowanych przed podjęciem decyzji o standaryzacji na tej platformie.

Squarespace

Rozwiązanie kierowane do organizacji ceniących spójność wizualną i prostotę utrzymania. W portfelach korporacyjnych występuje zwykle jako podstawa serwisów wydarzeniowych, kampanijnych i marek o ograniczonej skali.

Zakres możliwości w warstwie technicznej jest węższy niż przy rozwiązaniach instalowanych we własnej infrastrukturze, co przy niewielkich serwisach nie stanowi przeszkody. Przy planach rozwoju obejmujących rozbudowany katalog warto rozważyć to na etapie wyboru, ponieważ zmiana platformy w trakcie działania serwisu jest przedsięwzięciem kosztownym.

Shoper, IdoSell oraz Sky-Shop

Polskie platformy udostępniane w modelu usługowym, dobrze osadzone w realiach krajowego rynku: z gotowymi integracjami z serwisami aukcyjnymi, porównywarkami, systemami płatności i operatorami logistycznymi oraz z obsługą dostosowaną do krajowych obowiązków sprzedawcy.

Pierwsza z nich sprawdza się przy sklepach o średniej skali szukających kompletności bez zaplecza technicznego. Druga jest nastawiona na sprzedaż wielokanałową i rozbudowaną logistykę, co przy dużej liczbie zamówień bywa rozstrzygające. Trzecia kierowana jest do mniejszych i średnich sklepów, z naciskiem na szybkie uruchomienie i niższy koszt wdrożenia.

We wszystkich trzech zakres zmian wyznacza panel administracyjny, więc przed standaryzacją warto zweryfikować sterowanie indeksacją filtrów, obsługę przekierowań oraz możliwość korekty danych uporządkowanych. Są to obszary, w których platformy tego rodzaju różnią się między sobą, a możliwości zmieniają się wraz z kolejnymi wydaniami.

OpenCart

Rozwiązanie instalowane we własnej infrastrukturze, lekkie i niewymagające, spotykane w spółkach o niewielkiej skali oraz w serwisach o ograniczonym katalogu. Podstawowa obsługa katalogu i zamówień działa bez rozszerzeń.

Część funkcji istotnych dla widoczności wymaga rozszerzeń o zróżnicowanej jakości, w tym obsługa adresów, przekierowań i danych uporządkowanych. Przy przejmowaniu takiego serwisu do portfela pierwszym etapem bywa doprowadzenie instalacji do wersji możliwej do bezpiecznego utrzymania.

Drupal

System zarządzania treścią stosowany w organizacjach o rozbudowanych wymaganiach dotyczących modelowania treści, zarządzania uprawnieniami i obsługi wielu witryn w jednej instalacji. Spotykany często w administracji publicznej, w szkolnictwie wyższym oraz w przedsiębiorstwach o złożonej strukturze informacyjnej.

Zaletą w kontekście widoczności jest precyzja modelowania treści i pełna kontrola nad generowanym kodem, co ułatwia wdrożenie danych uporządkowanych oraz konsekwentnej struktury adresów. Wymaga natomiast kompetencji programistycznych — zmiany wykraczające poza konfigurację są przedsięwzięciem wytwórczym, a nie czynnością redakcyjną.

TYPO3

Rozwiązanie o ugruntowanej pozycji na rynku niemieckojęzycznym, stosowane w organizacjach o rozbudowanych strukturach wielojęzycznych. Obsługa wersji językowych i zarządzania wieloma witrynami należy do jego mocnych stron, co przy portfelach europejskich bywa argumentem rozstrzygającym.

Przy pracy nad widocznością wymaga uwagi w obszarze konfiguracji adresów oraz obsługi treści powtarzalnych między witrynami w tej samej instalacji. Zasoby kompetencyjne na rynku są węższe niż przy rozwiązaniach o większym udziale, co warto uwzględnić przy planowaniu ciągłości.

Adobe Experience Manager

Platforma klasy korporacyjnej przeznaczona do zarządzania doświadczeniem odbiorcy w wielu kanałach, z rozbudowanymi mechanizmami personalizacji, zarządzania zasobami cyfrowymi oraz obsługi procesów redakcyjnych o wielu szczeblach akceptacji.

W warstwie widoczności największą uwagę wymaga sposób renderowania treści oraz konfiguracja mechanizmów buforujących, ponieważ wdrożenia tej klasy bywają rozbudowane na tyle, że domyślne ustawienia nie odpowiadają potrzebom. Personalizacja wymaga odrębnego rozstrzygnięcia: treść zmienna w zależności od odbiorcy musi mieć ustaloną postać podstawową, którą zobaczy robot wyszukiwarki.

Sitecore oraz Optimizely

Platformy korporacyjne łączące zarządzanie treścią z personalizacją i prowadzeniem testów. Stosowane w organizacjach, w których zawartość serwisu zmienia się zależnie od segmentu odbiorcy, źródła wejścia albo historii kontaktu.

Podstawowym zagadnieniem jest tu rozdzielenie warstwy personalizowanej od warstwy stałej. Serwis, w którym treść podstawowa zależy od zmiennych kontekstowych, bywa dla wyszukiwarki trudny do jednoznacznego odczytania, a wyniki testów prowadzonych bez uwzględnienia tego aspektu potrafią wprowadzać w błąd.

Salesforce Commerce oraz SAP Commerce

Rozwiązania sprzedażowe klasy korporacyjnej, wdrażane w organizacjach o rozbudowanych procesach handlowych, wielu kanałach sprzedaży i integracjach z systemami zarządzania przedsiębiorstwem. Zakres funkcjonalny wykracza znacznie poza obsługę katalogu i zamówień.

W warstwie widoczności wymagają uwagi w trzech obszarach: sposobie generowania adresów przy rozbudowanej strukturze katalogu, obsłudze nawigacji warstwowej oraz wydajności stron listingowych przy dużej liczbie pozycji. Wdrożenia tej klasy prowadzone są zwykle przez wyspecjalizowanych partnerów, więc praca nad widocznością odbywa się w uzgodnieniu z nimi, w ich rytmie wydawniczym.

BigCommerce

Platforma sprzedażowa udostępniana w modelu usługowym, kierowana do organizacji o średniej i dużej skali, z rozbudowanymi możliwościami integracyjnymi oraz obsługą wdrożeń rozdzielonych, w których warstwa prezentacji budowana jest osobno.

Przy zastosowaniach korporacyjnych warto zweryfikować sposób obsługi wersji językowych, sterowanie indeksacją przy filtrowaniu oraz zakres kontroli nad strukturą adresów. Wariant rozdzielony daje większą swobodę, przenosząc jednocześnie odpowiedzialność za renderowanie i wydajność na zespół budujący warstwę prezentacji.

Architektury rozdzielone

Model, w którym warstwa prezentacji jest oddzielona od zaplecza zarządzania treścią i pobiera dane przez interfejsy programistyczne. Stosowany coraz częściej w organizacjach dostarczających treść do wielu kanałów jednocześnie: serwisu, aplikacji, urządzeń i partnerów zewnętrznych.

Zaletą jest swoboda w budowie warstwy prezentacji oraz możliwość osiągnięcia bardzo wysokiej wydajności. Zagrożeniem jest sposób renderowania: treść generowana wyłącznie po stronie przeglądarki bywa dla części robotów niedostępna albo dostępna z opóźnieniem. Rozstrzygnięciem stosowanym w projektach, w których widoczność ma znaczenie, jest renderowanie po stronie serwera albo generowanie postaci statycznej — decyzja ta zapada na etapie projektowania architektury i jest kosztowna do zmiany później.

Drugim zagadnieniem jest zarządzanie przekierowaniami i adresami, które w tym modelu bywa rozproszone między warstwę prezentacji, warstwę pośredniczącą i infrastrukturę sieci dostarczania treści. Bez ustalenia, gdzie znajduje się jedno źródło prawdy, konfiguracje zaczynają się rozjeżdżać już po kilku miesiącach.

Aplikacje jednostronicowe

Rozwiązania budowane w oparciu o React, Angular lub Vue, w których nawigacja odbywa się bez przeładowania strony. Model sprawdzający się w zastosowaniach aplikacyjnych, a przy serwisach nastawionych na widoczność wymagający dodatkowych rozstrzygnięć.

Podstawowym jest zapewnienie, że treść jest dostępna bez wykonywania kodu po stronie przeglądarki. Drugim — poprawna obsługa adresów: każdy stan aplikacji, który ma być odnajdywany w wyszukiwarce, musi mieć własny, trwały adres zwracający pełną treść przy bezpośrednim wejściu. Trzecim jest obsługa znaczników opisujących stronę, które w tym modelu bywają ustawiane dynamicznie i wymagają weryfikacji.

Wdrożenia autorskie

Serwisy budowane na zamówienie w środowiskach programistycznych: w rodzinie Java, w środowisku .NET, a także na Laravel, Symfony, Django czy Ruby on Rails. W portfelach korporacyjnych spotykane przy systemach obsługujących nietypowe procesy biznesowe.

Charakterystyczne dla takich wdrożeń jest to, że bywają dopasowane do procesu i jednocześnie pozbawione elementów uznawanych za oczywiste: mapy witryny, panelu przekierowań, obsługi danych uporządkowanych, poprawnej obsługi kodów odpowiedzi. Przy przejmowaniu takiego serwisu do standaryzacji pierwszym etapem jest uzupełnienie podstaw, a nie optymalizacja.

Zaletą jest natomiast brak ograniczeń narzuconych przez platformę: przy odpowiednich zasobach wytwórczych da się zrealizować dowolne rozwiązanie. Warunkiem jest dostępność zespołu oraz uwzględnienie prac w planie rozwoju systemu.

Infrastruktura i warstwa dostarczania

Przy projektach tej skali wydajność zależy w większym stopniu od architektury dostarczania treści niż od samej aplikacji. Sieci dostarczania treści, warstwy buforujące, sposób obsługi żądań przez warstwę pośredniczącą oraz konfiguracja mechanizmów ochronnych mają bezpośredni wpływ na to, czy i jak często roboty wyszukiwarek pobierają zawartość serwisu.

Szczególnej uwagi wymagają mechanizmy ochrony przed nadmiernym ruchem. Skonfigurowane bez uwzględnienia ruchu robotów potrafią blokować pobieranie treści, przy czym serwis działa prawidłowo dla odbiorców, a problem pozostaje niewidoczny bez analizy dzienników. Jest to jedna z częstszych przyczyn niewyjaśnionych spadków w organizacjach o rozbudowanej infrastrukturze.

Drugim zagadnieniem jest spójność między środowiskami. Konfiguracja obowiązująca w środowisku produkcyjnym bywa odmienna od testowego, a zmiany wprowadzane w warstwie sieciowej nie zawsze przechodzą przez tę samą ścieżkę akceptacji co zmiany w aplikacji. Uporządkowanie tego należy do zakresu ładu opisanego wcześniej.

W projektach tej klasy szczególną uwagę poświęcamy rozbieżności między tym, co widzi odbiorca, a tym, co otrzymuje robot wyszukiwarki. Serwis może działać bez zarzutu dla użytkowników i jednocześnie zwracać robotom odpowiedź niepełną albo odmowną. Przyczyną bywa konfiguracja mechanizmów ochronnych, warstwa pośrednicząca, personalizacja treści albo sposób obsługi zapytań pochodzących z wybranych regionów.

Jedynym wiarygodnym źródłem informacji w tym obszarze pozostają dzienniki serwera. Pokazują, które zasoby są pobierane, z jaką częstotliwością, jakimi odpowiedziami serwer reaguje i jak rozkłada się uwaga wyszukiwarki między segmentami portfela. Przy organizacjach, w których dostęp do dzienników wymaga uzgodnień z działem bezpieczeństwa, występujemy o niego na etapie uruchamiania projektu, ponieważ bez tych danych diagnostyka pozostaje niepełna.

Drugim obszarem o wysokiej wadze jest personalizacja. Treść zmienna zależnie od segmentu odbiorcy, lokalizacji albo historii kontaktu wymaga ustalenia postaci podstawowej — tej, którą otrzyma robot. Bez takiego rozstrzygnięcia serwis bywa oceniany na podstawie wersji przypadkowej, a wyniki testów prowadzonych równolegle mogą wprowadzać w błąd.

Przy organizacjach o ugruntowanej pozycji pierwszym zadaniem nie jest budowanie obecności, lecz weryfikacja jej treści. Systemy generatywne zwykle znają dużą markę, natomiast informacje, które o niej podają, pochodzą z materiałów o różnym stopniu aktualności. Zestawienie pytań testowych zadawanych regularnie pozwala ustalić, co dokładnie jest powtarzane, i wskazać źródła wymagające korekty.

Drugim zadaniem jest rozstrzygnięcie w sprawie dostępu. Organizacja może nie życzyć sobie wykorzystywania swoich materiałów do uczenia modeli, a jednocześnie oczekiwać obecności w odpowiedziach generowanych na bieżąco. Rozróżnienie to wymaga świadomej konfiguracji i uzgodnienia z działem prawnym oraz z właścicielami praw do treści. W praktyce spotykamy organizacje, w których blokada została ustanowiona przypadkowo, przy okazji prac nad zabezpieczeniem infrastruktury.

Trzecim jest praca nad źródłami zewnętrznymi. Ponieważ obraz organizacji powstaje głównie poza jej serwisem, działania obejmują publikacje branżowe, obecność w opracowaniach, aktualność danych w rejestrach oraz reagowanie na informacje nieprawdziwe. Jest to obszar łączący widoczność z komunikacją korporacyjną i przy dużych organizacjach wymaga współpracy kilku działów.

Czwartym jest przygotowanie własnych materiałów w postaci nadającej się do cytowania. Zwarte odpowiedzi na pytania zadawane przez odbiorców, dane liczbowe opatrzone źródłem, jasne warunki i zakresy. Materiały wyłącznie promocyjne nie zawierają informacji możliwych do przytoczenia, więc nie uczestniczą w budowaniu odpowiedzi.

W praktyce najczęstszym źródłem napięcia jest konfiguracja narzędzi analitycznych. Wymagania dotyczące zgód i ograniczenia w śledzeniu wpływają na kompletność danych, na podstawie których ocenia się skuteczność działań. Rozwiązaniem jest ustalenie modelu pomiaru uwzględniającego te ograniczenia od początku, wraz z jawnym opisaniem, jaka część danych pozostaje nieuchwytna.

Drugim jest dostępność cyfrowa, traktowana niekiedy jako obciążenie, a w istocie w znacznej części zbieżna z tym, co służy widoczności: poprawna struktura nagłówków, opisy alternatywne obrazów, czytelna nawigacja i możliwość obsługi bez myszy. Wdrożenie tych wymagań poprawia jednocześnie odbiór przez odbiorców i przez systemy automatyczne.

Trzecim jest sposób formułowania treści w branżach objętych ograniczeniami. Materiał obiecujący określony skutek bywa niedopuszczalny i jednocześnie oceniany niżej przez systemy weryfikujące wiarygodność. Ostrożność w twierdzeniach przynosi tu korzyść podwójną, co bywa zaskoczeniem dla zespołów przyzwyczajonych do języka promocyjnego.

Nie zastępujemy obsługi prawnej organizacji ani osoby odpowiedzialnej za ochronę danych. Wskazujemy obszary wymagające ich decyzji i przygotowujemy rozwiązania techniczne zgodne z przyjętym stanowiskiem. Ocena zgodności z przepisami pozostaje po stronie właściwych jednostek — i mówimy to na etapie ustalania zakresu, żeby nie powstało wrażenie, że przejmujemy tę odpowiedzialność.

Zakres danych, który wystarcza do sensownej analizy, jest niewielki. Potrzebne są: znacznik czasu, adres żądania, kod odpowiedzi, identyfikator klienta, rozmiar odpowiedzi i czas jej obsługi. Okres obejmujący cztery tygodnie pozwala zobaczyć rytm tygodniowy i wychwycić zdarzenia jednorazowe; przy dużych portfelach bywa to kilkadziesiąt milionów wierszy, co wymaga przetwarzania narzędziami przystosowanymi do tej skali, a nie arkuszem kalkulacyjnym.

Pierwszym zabiegiem jest weryfikacja tożsamości robotów. Identyfikator klienta jest łatwy do podrobienia, więc żądania podające się za roboty wyszukiwarek weryfikuje się przez sprawdzenie, czy adres, z którego pochodzą, faktycznie należy do danego dostawcy. Bez tego kroku analiza obejmuje również ruch narzędzi analitycznych i automatów, co zniekształca wnioski.

Drugim jest podział adresów na kategorie. Reguły przypisujące adres do typu podstrony — strona główna, kategoria, karta produktu, materiał redakcyjny, adres z parametrem, zasób pomocniczy. Dopiero po takim podziale widać, jak rozkłada się uwaga wyszukiwarki, i dopiero wtedy dane stają się podstawą decyzji.

Trzecim jest zestawienie z innymi źródłami. Dzienniki pokazują, co zostało pobrane; narzędzia dla webmasterów pokazują, co zostało zaindeksowane; system analityczny pokazuje, co przyniosło ruch. Rozbieżności między tymi trzema zbiorami są mapą problemów: podstrony pobierane i niezaindeksowane, zaindeksowane i bez ruchu, przynoszące ruch i rzadko odwiedzane przez robota.

W organizacjach, w których dostęp do dzienników wymaga uzgodnień z działem bezpieczeństwa, warto wystąpić o niego na etapie uruchamiania projektu. Zwykle wystarcza wyciąg zawierający wyłącznie żądania robotów, pozbawiony danych mogących identyfikować odbiorców, co upraszcza uzgodnienie. Przygotowanie takiego wyciągu po stronie działu technicznego jest zadaniem na kilka godzin.

Najczęstszym błędem przy szacowaniu jest podawanie pojedynczej liczby bez wskazania założeń. Deklaracja mówiąca o wzroście o trzydzieści procent brzmi konkretnie i przy pierwszej weryfikacji okazuje się nieweryfikowalna, ponieważ nie wiadomo, czego dotyczyła ani co miałoby pozostać bez zmian. Oszacowanie użyteczne zawiera populację, wielkość odniesienia, założenia i przedział.

Drugim jest pomijanie kosztu po stronie organizacji. Rekomendacja wymagająca dwustu godzin pracy zespołu wytwórczego konkuruje z innymi zastosowaniami tych godzin. Przedstawienie jej bez tej informacji przenosi ciężar oszacowania na osobę decydującą, co zwykle kończy się odłożeniem sprawy.

Trzecim jest brak rozróżnienia między korzyścią a uniknięciem straty. Część prac nie zwiększa wyniku, lecz zapobiega jego pogorszeniu: aktualizacja oprogramowania, uporządkowanie przekierowań, przegląd wydajności. Uzasadnianie ich obietnicą wzrostu jest nierzetelne i podważa wiarygodność pozostałych pozycji w tym samym dokumencie.

Warto prowadzić rejestr oszacowań wraz z wynikami rzeczywistymi. Po kilku kwartałach staje się on najmocniejszym argumentem w rozmowie o priorytetach: pokazuje, w których obszarach oszacowania okazywały się trafne, a w których wymagają ostrożności. Organizacje, które go prowadzą, podejmują decyzje o nakładach szybciej i przy mniejszym oporze.

Rozstrzygnięciem stosowanym w serwisach, w których widoczność ma znaczenie, jest renderowanie po stronie serwera albo generowanie postaci statycznej. Treść jest wtedy obecna w dokumencie od razu, niezależnie od możliwości urządzenia odbiorcy i od czasu, jakim dysponuje robot. Decyzja ta zapada na etapie projektowania architektury, a jej późniejsza zmiana bywa przedsięwzięciem porównywalnym z przebudową warstwy prezentacji.

Rozwiązaniem pośrednim jest przygotowywanie odrębnej postaci dla robotów. Bywa stosowane, wymaga jednak ostrożności: treść przygotowana dla wyszukiwarki musi odpowiadać tej, którą widzi odbiorca. Rozbieżność między nimi jest traktowana jako działanie wprowadzające w błąd, z konsekwencjami obejmującymi cały serwis.

Przy serwisach z personalizacją obowiązuje dodatkowe rozstrzygnięcie. Trzeba ustalić postać podstawową — tę, którą otrzyma robot i odbiorca odwiedzający serwis po raz pierwszy. Bez takiego ustalenia zawartość indeksu zależy od przypadkowych okoliczności żądania, a wyniki testów prowadzonych równolegle stają się trudne do interpretacji.

Weryfikację warto włączyć do procesu wdrożeniowego jako czynność stałą. Zmiana w warstwie prezentacji potrafi przenieść treść z dokumentu do skryptu bez żadnego widocznego skutku dla odbiorcy. Wykrycie tego po fakcie zajmuje tygodnie, a wykrycie przed wdrożeniem — kilka minut.

Wynikiem dobrze przeprowadzonej konsolidacji bywa wzrost ruchu przy jednoczesnym zmniejszeniu liczby podstron. Zjawisko to jest nieintuicyjne dla organizacji przyzwyczajonych do mierzenia aktywności liczbą publikacji, więc warto uprzedzić o nim przed rozpoczęciem prac. Materiał powstały z połączenia pięciu opracowań częściowych odpowiada na pytanie odbiorcy pełniej niż każde z nich osobno.

Kryterium rozstrzygającym nie jest wiek materiału. Opracowanie sprzed lat, aktualne merytorycznie i przynoszące ruch, jest zasobem. Materiał opublikowany niedawno, powielający treść istniejącą, jest obciążeniem. Decyzja opiera się na zestawieniu danych z oceną merytoryczną, a nie na dacie publikacji.

Przy wycofywaniu obowiązuje ostrożność wobec materiałów z odnośnikami zewnętrznymi. Podstrona bez ruchu z wyszukiwarki może mieć odnośniki z serwisów branżowych, które przenoszą wartość na cały serwis. Przed usunięciem warto sprawdzić profil odnośników; przy ich obecności właściwym rozwiązaniem jest przekierowanie, a nie wyłączenie.

W organizacjach o rozbudowanej strukturze konsolidacja bywa trudna politycznie. Materiały przygotowane przez różne jednostki mają swoich autorów i swoich obrońców, a decyzja o połączeniu bywa odbierana jako ocena czyjejś pracy. Dlatego prowadzi się ją na danych i z udziałem właścicieli biznesowych, a nie jako rozstrzygnięcie techniczne narzucone z zewnątrz.

Etapy od drugiego do czwartego stanowią fazę przygotowawczą i bywają odbierane jako opóźnienie właściwych prac. Uprzedzamy o tym na wstępie, ponieważ przy tej skali pominięcie ich prowadzi do sytuacji, w której zalecenia są wdrażane wybiórczo, bez ustalonego standardu i bez możliwości wykazania efektu.

Zakres po stronie organizacji ustalamy przed rozpoczęciem. Obejmuje on wskazanie osoby decyzyjnej, zapewnienie dostępu do dzienników serwera i do systemów analitycznych, ustalenie trybu współpracy z zespołami wytwórczymi oraz wyznaczenie osób znających asortyment i procesy biznesowe. Brak tych ustaleń jest najczęstszą przyczyną, dla której poprawnie przygotowane rekomendacje pozostają niewdrożone.

Docelowym stanem jest samodzielność organizacji w obszarach, w których jest ona osiągalna. W trzecim roku współpracy część zadań powinna być prowadzona przez zespół wewnętrzny, a nasz udział ograniczać się do obszarów wymagających specjalizacji. Organizacja, która po kilku latach potrzebuje nas w niezmienionym zakresie, jest dowodem, że współpraca nie przyniosła zamierzonego skutku.