Napisz do nas

Zapraszamy na 23 szkoleń z e-marketingu i konferencję I ♥ Marketing oraz zakupu magazynu

19 Szkoleń i I ♥ Marketing oraz zakupu magazynu

ostateczne-poprawki

Zanim wystartujesz z serwisem – Ostateczne poprawki pod kątem SEO

Planując uruchomienie nowego serwisu lub przebudowę już istniejącego, konieczne jest dokładne sprawdzenie, czy wszystko działa poprawnie. Nie jest to kwestia przejrzenia strony na szybko, gdyż wyjątkowo istotne jest, aby ewentualne błędy wyłapał zespół pracujący nad serwisem, a nie klienci. Dlatego też w w testowanie serwisu przed jego uruchomieniem powinno być zaangażowanych po kilku specjalistów z każdego działu, zaczynając od programistów, poprzez copywriterów, aż po specjalistów do spraw SEO.

Poniżej znajduje się lista elementów, które należy sprawdzić właśnie pod kątem SEO. Za przykład niech nam posłuży serwis ogłoszeniowy, w którym mamy kategorie z listami ogłoszeń (możliwe do posortowania np. po dacie dodania), profile użytkowników, ich ogłoszenia, a także wyszukiwarkę wewnętrzną i ewentualnie artykuły.

Treść na stronie

Problem z tekstami na stronie polega na tym, że nie zawsze łatwo jest pogodzić interesy marketingowców chcących używać ich „chłytów” reklamowych do skutecznego sprzedania produktu, z interesami pozycjonerów pragnących wykorzystać każdą możliwość do zdobycia ruchu organicznego. Jeśli więc dotychczas treścią zajmowali się tylko copywriterzy z działu marketingowego, czas na ich analizę pod kątem SEO.

Metatagi

Odrębne schematy metatagów powinny zostać przygotowane dla:

  • strony głównej – powinna ona zostać zoptymalizowana pod kątem najbardziej konkurencyjnych i ogólnych słów kluczowych;
  • podstron statycznych takich jak regulamin, polityka prywatności, kontakt itp. – w tym przypadku optymalizacja pod kątem SEO nie ma zbyt wielkiego znaczenia, dlatego przygotowując title i description tego typu podstron należy skupić się na czysto informacyjnych treściach pisanych tylko pod użytkowników. Jeśli zdecydujemy się nie indeksować w ogóle takich podstron, wystarczy sam title;
  • podstron kategorii – są to podstrony kategorii, lokalizacji oraz ich połączeń. To głównie one będą generować ruch z szerokiego ogona tym bardziej, jeśli uwzględni się na nich odmiany kategorii i lokalizacji, optymalizując je w ten sposób na znacznie więcej kombinacji słów kluczowych;
  • podstron konkretnych ogłoszeń – powinny one zostać zoptymalizowane pod kątem danego ogłoszenia, dlatego w title często zamieszczany jest tytuł wstawiony ręcznie przez użytkownika, a w opisie – fragment ogłoszenia. To kolejne podstron, które będą generować ruch long-tailowy;
  • podstron z profilami użytkowników – powinny być one zoptymalizowane pod kątem imion i nazwisk lub nicków użytkowników. Pomoże im to w wypromowaniu się w wyszukiwarkach;
  • podstrony z listą artykułów – jeśli artykuły dotyczą konkretnej tematyki, można wybrać słowa kluczowe związane z nią;
  • podstrony z artykułem – w tym przypadku można albo przygotować ogólny schemat, albo umożliwić indywidualne wstawianie title, description, a nawet fragmentu artykułu wyświetlanego na liście.

Dobrym rozwiązaniem jest korzystanie ze zmiennych przyporządkowanych do nazw kategorii aktualnej lub nadrzędnej, odmian lokalizacji (przynajmniej największych miejscowości), o których jednak należy pomyśleć nieco wcześniej niż w momencie ostatnich poprawek na stronie.

Blokada przed robotami i wykluczenie z indeksacji

Nie wszystkie podstrony serwisu ogłoszeniowego powinny być indeksowane. Jeśli różne podstrony prezentują tę samą zawartość i nie wnosiłyby nic nowego do indeksów wyszukiwarek, najlepszym rozwiązaniem jest ich blokada przed indeksacją.

Przykładem mogą być wyniki wyszukiwania lub sortowania, które powinny zostać zablokowane w pliku robots.txt lub zawierać noindex w metatagach. W pierwszym przypadku robot nie będzie odwiedzał takich podstron, ale zaindeksuje je (wyświetlając sam adres bez tytułu ani opisu), jeśli będą do nich prowadzić jakiekolwiek linki. Drugie rozwiązanie nie pozwoli na indeksację adresów, ale umożliwi robotom chodzenie po nich.

Innym przykładem jest generowanie wersji PDF, które również powodują duplikowanie treści w obrębie serwisu. Jeśli pliki takie są nieliczne, teoretycznie Google powinno wyświetlić wersje w PDFie niżej od HTMLowej albo nie wyświetlać jej w ogóle. Dla pewności warto je jednak zablokować, tym bardziej jeśli wersja PDF jest generowana automatycznie dla każdego artykułu lub ogłoszenia na stronie.

Struktura URLi – prawidłowa kolejność

Zdarza się, że wchodząc na podstronę ogłoszenia różnymi ścieżkami, trafimy na inny adres:

  • strona główna → kategoria → lokalizacja → ogłoszenie
  • strona główna → lokalizacja → kategoria → ogłoszenie

Jeśli każda z nich doprowadzi nas do innego adresu, odnośniki na stronie powinny zostać poprawione w taki sposób, aby kolejność poszczególnych elementów URLa nie była zależna od pokonanej ścieżki.

Przekierowania

W celu uniknięcia udostępniania tej samej zawartości pod kilkoma adresami, należy upewnić się, czy ustawiono odpowiednie przekierowania na poszczególnych stronach. Oto kilka przykładów adresów, którym należy przyjrzeć się w pierwszej kolejności:

  • adres strony z www lub bez – przekierowanie 301 powinno zostać ustawione po podjęciu decyzji dotyczącej formatu adresu;
  • domena.pl/index.php, www.domena.pl/index.php, domena.pl/ – wszystkie te adresy prowadzą do strony głównej, która powinna być dostępna tylko pod jednym z nich;
  • domena.pl/katalog/ i domena.pl/katalog – w takim przypadku należy zdecydować się, czy adres taki ma się kończyć znakiem „/” czy też nie. W zależności od wyboru, wszystkie odnośniki na stronie powinny zostać poprawione, a dodatkowym zabezpieczeniem przed indeksacją drugiej wersji jest przekierowanie 301 np. z domena.pl/katalog na domena.pl/katalog/;
  • domena.pl/katalog/?p=1 – do nielicznych należą serwisy, na których po przejściu na drugą podstronę i chęci powrotu na pierwszą, znalazłabym prawidłowy link, który NIE kierowałby do adresu z końcówką w stylu p=1. Takie adresy nie tylko powinny zostać poprawione, ale także przekierowane na domena.pl/katalog/.

Należy również pamiętać o tym, że istnieje różnica pomiędzy przekierowaniem 301 a 302, które jest stosowane dość często. W sprawdzeniu rodzaju przekierowania pomoże nam Firebug, który w momencie wejścia na stronę wyświetli jej status.

Niedziałające linki

Bardzo dobrym narzędziem, które wyłapie niedziałające linki na stronie, jest Xenu. Pomoże on nie tylko w wykryciu, ale także zlokalizowaniu błędnych linków zarówno wewnętrznych, jak i wychodzących. Informuje on również o przekierowaniach, poziomie na jakim znajduje się dana podstrona, a także ilości linków otrzymanych z serwisu. Dlatego też Xenu jest przydatny w ogólnej analizie linkowania na stronie.

Usunięte podstrony

Po przeanalizowaniu opisanych już elementów pozostaje nam jeszcze jeden problem – co zrobić z usuwanymi ogłoszeniami i kontami? Kiedy stosować przekierowanie 301 do podstrony profilu użytkownika, który usunął ogłoszenie, kiedy przekierować na podstronę kategorii, w jakiej się ono znajdowało, a kiedy zdecydować się na ustawienie kodu 404 lub 410 na usuniętej podstronie. Ciekawa dyskusja, w której omówione zostały poszczególne przypadki, znajduje się na Forum.MAXroy.com w temacie „Puste strony – co robić?”

sprawnymarketing

Powyższy tekst zawiera prywatne poglądy Autora. Niekoniecznie muszą odzwierciedlać one poglądy Redakcji.

Marta Gryszko

Związana z branżą SEO od 2005 r. Autorka SEO bloga, współtwórca narzędzi SeoStation.pl i Brandle.pl (Wake App Sp. z o.o.). Autorka kursu SEO na poziomie podstawowym, na poziomie średniozaawansowanych i szkolenia z audytów.


  • Redakcja

    Przy okazji przypominamy o nowej grupie na Facebooku, w której odpowiadamy na szereg pytań. Dołącz do Twoja firma w Internecie i Social Media.

    Subskrybuj Sprawny.Marketing na Messengerze, dostaniesz informację o każdym nowym artykule lub materiale video

    Wielkimi krokami zbliża się także dwudniowa konferencja I ♥ Marketing & Social Media oraz organizowane przez nas 24 szkolenia z zakresu marketingu.

    Możesz też zamówić prenumeratę drukowanego magazynu sprawny.marketing


    • No i jeszcze dodajemy sitemap'y (najlepiej html i xml).
      Fajna, praktyczna wiedza zebrana w jednym miejscu – dla mnie super

    • Paweł Jakimowski

      Wszystko to co każdy tworzący stronę powinien wiedzieć. Dobrze, że ktoś to zebrał i przypomniał ;]

      • Zebrałam to właśnie przy okazji testowania nowej wersji serwisu ;-)

    • Z przekierowaniem z /index.php na / jest jeden duży problem: na niektórych serwerach np. Apache + mod_fastcgi + php-fpm nie ma żadnej możliwości ich rozróżnienia, co więcej po wejściu na / zmienne REQUEST_URI, REQUEST_FILENAME itp. zawierają /index.php, przez co aktywacja przekierowania spowodowałaby nieskończoną pętlę. Tak więc nie mogę domyślnie włączać tego (jest tylko canonical) i nie jest to błąd. WordPress też posiada kod ale nieaktywny.

      http://core.trac.wordpress.org/ticket/5017
      http://core.trac.wordpress.org/ticket/7173

      • Widzę że najnowszy WP przekierowuje, ale to tylko błąd w kodzie obsługującym /index.php/ – wyrażenie regularne pasuje też do /index.php (linia 229). Kod obsługujący /index.php dalej jest nieaktywny.

        Jakimś wyjściem mogłoby być sprawdzenie w skrypcie instalacyjnym, czy dla /index.php i / są różne REQUEST_URI i automatyczne skonfigurowanie skryptu.

    • Wszystko się zgadza. Nie rozumiem tylko jednego. Dlaczego działania mają przeprowadzane być na samym końcu – "Zanim wystartujesz z serwisem" i dlaczego traktowane mają być jako: "Ostateczne poprawki pod kątem SEO".

      Osobiście jakoś nie godzi mi się sytuacja, w której agencja zatrudniająca "…po kilku specjalistów z każdego działu, zaczynając od programistów, poprzez copywriterów, aż po specjalistów do spraw SEO" tworząc serwis pomija kwestie związane z jego optymalizacją na etapie tworzenia.

      • No to niech Ci się nie godzi, za witryny zoptymalizowane należy dopłacić. To Polska a nie Niemcy, tu nie stawia się na jakość.

        Co do indeksacji, disallow w robots.txt nie wyklucza całkowicie adresu z indeksu? Dziwne.

      • Jeśli np. do met ma zostać użyta odmiana lokalizacji, trzeba to ustalić znacznie wcześniej. Ale takie błędy jak nieprawidłowe podlinkowanie pierwszej podstrony w paginacji, zbędne podlinkowanie w pathwayu aktualnego zagłębienia, trafianie na różne URLe w przypadku różnych ścieżek czy pominięcie met do niektórych podstron statycznych, zdarza się dość często.

        Nawet mimo wcześniejszych ustaleń co do tych elementów, pracownicy działu IT mogą zapomnieć o ustaleniach działu SEO albo wprowadzić je bez dokładnego sprawdzenia, czy wszystko działa prawidłowo. Błędy są naturalne i jeszcze nigdy nie spotkałam się z tym, żeby przed odpaleniem nowej strony nie znaleźć na niej żadnego błędu.

        Co innego ustalenia na początku projektu, a co innego sprawdzenie tuż przed startem, czy wszystko zostało wykonane zgodne z nimi. Poza tym, o niektórych detalach na początku nawet się nie pomyśli wychodząc z założenia, że to zbyt logiczne, aby o tym mówić, np. jeśli serwis w trakcie budowy jest dostępny tylko dla wybranych IPów, wypadałoby zdjąć blokadę. Jeśli zamiast tego na stronie widnieje noindex, również dobrze byłoby go usunąć w momencie startu z serwisem ;-)

    • Paweł Chwalibóg

      "Przykładem mogą być wyniki wyszukiwania lub sortowania, które powinny zostać zablokowane w pliku robots.txt lub zawierać noindex w metatagach." – a czy nie lepiej ustawić jest rel canonical na stronach sortowania?

      • Najpierw dobrze jest się zastanowić, czy robot w ogóle ma chodzić po takich podstronach i w zależności od tego podjąć decyzję co do konkretnego rozwiązania.

      • Lepiej.
        Ale jest jedna sytuacja, gdzie canonical nie jest optymalny: kilka rodzajów sortowania, ustawione inne niż domyślne + podział na strony. Strona x przy sortowaniu domyślnym nie musi być kanoniczną wersją strony x przy innym sortowaniu. Strona 1 także.

      • Paweł Chwalibóg

        Hmm… czy mógłbyś dokładniej rozwinąć ten przykład?

      • Jest strona z sortowaniem według autora i tytułu:
        /autor
        /tytul
        Domyślne sortowanie jest według autora. Możesz ustawić canonical:
        /autor na stronie /autor
        /autor na stronie /tytul
        i nie masz duplicate contentu.

        Jest strona ze stronicowaniem:
        /
        /2
        /3
        Canonical na każdej ustawisz inny, bo w końcu każda strona zawiera inną treść, nie jest to duplicate content.

        Sytuacja, gdy canonical jest niemożliwy do zastosowania: kombinacja pierwszego i drugiego przypadku – sortowanie + stronicowanie (lub inna operacja zmieniająca zbiór + operacja dzieląca na fragmenty):
        /autor/
        /tytul/
        /autor/2
        /tytul/2
        /autor/3
        /tytul/3

        Na /autor/* ustawisz canonical /autor/* – jest to domyślne sortowanie, poszczególne strony się różnią, tutaj nie ma problemu.
        Z /tytul/* już jest problem:
        – ustawisz /tytul/*, będziesz miał wszystko zaindeksowane podwójnie, bo suma zbioru /tytul/* jest też sumą zbioru /autor/*, chociaż pojedyncze strony się różnią
        – ustawisz /autor/*, to okłamiesz wyszukiwarkę, bo np. trzecia strona według tytułu to nie jest trzecia strona według autora – zawierają one różną treść, w tym przypadku:
        a) jeżeli linkują tylko strony wewnętrzne, to będzie wszystko dobrze – całość zaindeksowana jeden raz, dystrybucja PR w obrębie witryny dobra
        b) jeżeli ktoś z zewnątrz podlinkuje np. /tytul/2, to bot to potraktuje jak link prowadzący do /autor/2 (strony z całkowicie inną treścią niż /tytul/2)
        c) bot może zignorować taki canonical (w szczególności msnbot) lub potraktować to jak spam (nie spotkałem się z taką sytuacją), bo umożliwia to "cloaking" ze względu na to że user-agenty inne niż boty wyszukiwarek nie obsługują instrukcji canonical
        John Mueller z Google twierdzi, żeby w tym przypadku wcale nie wstawiać canonicala, Guglarz na polskim forum Google pisał też, że można zrobić stronę z listą wszystkich wpisów, posortowanych domyślnie, bez stronicowania i ją ustawić jako canonical – ale w praktyce zrobienie na pojedynczej stronie listy np. 50 tys. wpisów jest niemożliwe.
        – ustawisz /autor/1 – jak wyżej, ale dodatkowo pogorszysz rozkład PR wewnątrz witryny

        Jeszcze gorzej jest, jak masz dynamiczne URL i wpadniesz na pomysł, żeby oprócz canonicala ustawić też obsługę parametrów w narzędziach dla webmasterów:
        sortowanie=autor&strona=1
        sortowanie=tytul&strona=1
        sortowanie=autor&strona=2
        sortowanie=tytul&strona=2
        sortowanie=autor&strona=3
        sortowanie=tytul&strona=3
        i ustawisz ignorowanie parametru sortowanie. Istnieje bardzo duże prawdopodobieństwo, że Google zaindeksuje np. tylko
        sortowanie=autor&strona=1
        sortowanie=tytul&strona=2
        sortowanie=autor&strona=3
        czyli nie zaindeksuje całości, bo wpisy ze zbioru (A,2) mogą się nie znajdować w zbiorze (T,2). A opcja ta nie powoduje usuwania ignorowanych parametrów (wtedy by się zaindeksowały wszystkie strony A i żadna strona T, ale dalej linki zewnętrzne do stron T byłyby obsługiwane nieprawidłowo), tylko traktowanie wszystkich URL różniących się tym parametrem jak identycznych stron.
        Zresztą są tutaj też problemy z bezpieczeństwem, przez które nie używam obsługi parametrów absolutnie nigdy. Jakby któryś z konkurentów dowiedział się, że np. ignorujesz parametr PHPSESSID, to może podlinkować twoją stronę z &PHPSESSID=bardzo-długi-tekst-o-rozmiarze-kilku-KB, Google wtedy wejdzie na stronę z takim adresem, zaindeksuje komunikat błędu PHP i nie wejdzie przez długi czas na stronę z prawdziwym adresem, bo przecież ustawiłeś że zmiana PHPSESSID *nigdy* nie powoduje zmiany treści strony.
        Jakby bot usuwał ignorowane parametry z adresu, a nie tylko traktował wszystkie jak identyczne, tego typu atak nie byłby możliwy.

        Niektórzy twierdzą, że canonical to tylko podpowiedź dla bota, ale to nie jest prawda. Canonical inny niż Request-URI powoduje całkowite wyindeksowanie strony i potraktowanie jej jak przekierowanie 301 na canonical (znika z site:, pojawia się w info: z adresem strony docelowej). Jakby właściciel sprawnymarketing.pl ustawił canonical na gmail.com, Google by to potraktował jak 301 na gmail.com, pomimo tego że strony te są całkowicie inne.

    • Leszek Wolany

      mi zabrakło czegoś co jest kluczowe w fazie projektowej, mianowicie struktury linkowania wewnętrznego.

    • Ciekawy tekst.

      Nawiązanie do forum maxroy, to jak rozumiem odpowiedź na ostatnio pojawiające się, negatywne opinie o forum na łamach pio? :-)

      • W podlinkowanej rozmowie wyczerpano ten temat, dlatego nie widziałam sensu w powielaniu informacji tam zawartych tym bardziej, że powstałby z nich osobny artykuł ;-)

    • Emil Kowalczyk

      Jeszcze kilka tygodni temu broniłem się przed tematem seo, ale dzięki takim tekstom i aktywnej dyskusji w komentarzach można się czegoś nauczyć i zrozumieć

    • Tomasz Masajło

      Bardzo fajny tekst, mnie osobiście interesuje zwłaszcza fragment:
      „domena.pl/katalog/?p=1 – do nielicznych należą serwisy, na których po przejściu na drugą podstronę i chęci powrotu na pierwszą, znalazłabym prawidłowy link, który NIE kierowałby do adresu z końcówką w stylu p=1. Takie adresy nie tylko powinny zostać poprawione, ale także przekierowane na domena.pl/katalog/.”

      Pytanie jak to zrobić, gdy strony z parametrami p=1 są przepisywane przy użyciu mod rewrite na ładne adresy, np. /page/1 Reguła w mod rewrite jest jedna, bo czasami podstron p może być 100, więc nierealne byłoby wpisywanie każdej reguły osobno, np.:
      p=1 przepisz na katalog/
      p=2 przepisz na katalog/page/2

      Czy ktoś zna w miarę prostą metodę jak jednocześnie mieć ładne podstrony od 2 wzwyż (katalog/page/2), a stronę /katalog/page/1 przekierować do /katalog/ ?

    Dodaj komentarz

    Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *