19 typowych technicznych problemów SEO (z zalecanymi rozwiązaniami)

W Semetrical nasi specjaliści SEO przeprowadzili przez lata niezliczone audyty techniczne SEO i natknęli się na typowe problemy techniczne, z którymi borykają się strony internetowe w wielu branżach. Nasz przewodnik przedstawia najczęstsze problemy techniczne związane z SEO wraz z zalecanymi rozwiązaniami.

Poniżej wymieniono najczęstsze problemy techniczne związane z SEO:

1. Reguły bez uwzględniania wielkości liter w robotach, txt
2. Duplikowanie adresów URL wielkimi i małymi literami
3. Przekierowanie HTTP 302 do HTTPS
4. Kanoniczne adresy URL wpływające na linki wewnętrzne
5. Kanoniczne adresy URL z linkami do 404 adresów URL
6. Wiele tagów kanonicznych
7. Powielanie strony głównej
8. Różne wersje witryn na urządzenia mobilne i komputery
9. Wykrywanie międzynarodowych adresów IP
10. Powielanie stron międzynarodowych
11. Mapa witryny XML zawierająca historyczne adresy URL i tymczasowe adresy URL
12. Indeksowanie witryny tymczasowej powodującej duplikację
13. Trwa indeksowanie wyszukiwania wewnętrznego
14. Parametry powodujące powielanie
15. Powielanie adresu URL produktu
16. Głębokość strony internetowej
17. JavaScript
18. Nieprawidłowe użycie Meta Robots NOINDEX
19. Miękkie strony 404

1. Reguły bez uwzględniania wielkości liter w robotach, txt

Kwestia:

Podczas przeprowadzania technicznych audytów SEO często stwierdzamy, że reguły zakazu w pliku robots.txt nie uwzględniają zarówno reguł pisanych wielkimi, jak i małymi literami.

Na przykład w witrynach e-commerce ścieżki koszyka często biegną zarówno w /basket/, jak i /Basket/, ale w pliku robots.txt z reguły uwzględniana jest tylko ścieżka pisana małymi literami. Oznacza to, że adresy URL z /Koszykiem/ nadal byłyby indeksowalne, co powodowałoby powielanie treści, czego należy unikać, aby poprawić indeksację witryny w wyszukiwarkach.

Zasady pliku robots.txt:

Odrzuć: /koszyk/

Odrzuć: /koszyk/*

Rozwiązanie:

Przeprowadź audyt swojej witryny i sprawdź, czy istnieją zarówno duże, jak i małe wersje ścieżki, które należy zablokować. Możesz to zrobić za pomocą robota internetowego, takiego jak nasi znajomi z DeepCrawl. Jeśli w witrynie są aktywne obie wersje, dodaj drugą regułę w pliku robots.txt, aby umożliwić zablokowanie ścieżki pisanej wielkimi literami. Na przykład Disallow: /Koszyk/*

Jeśli nie masz dostępu do robota indeksującego, wyszukiwanie protokołu witryny może być bardzo przydatne, aby sprawdzić, czy indeksowane są zarówno wersje pisane wielkimi, jak i małymi literami.

2. Duplikacja adresów URL wielkimi i małymi literami

Kwestia:

Częstym problemem, który wykrywamy, jest duplikacja adresów URL, do których nie jest rozróżniana wielkość liter, do których prowadzą linki w całej witrynie, a Google widzi, że są to dwa różne adresy URL. Na przykład:

Może się tak zdarzyć, gdy redaktorzy w poście na blogu dodają bezpośredni link do strony produktu, ale wpisali wielką literę zamiast małej.

Widzieliśmy również, że dzieje się tak, ponieważ wewnętrzne moduły linkujące mają błąd, w którym linki do popularnych produktów są linkowane za pomocą wielkich liter.

Rozwiązanie:

Zalecamy skonfigurowanie reguły na poziomie serwera, w której wszystkie adresy URL zawierające duże litery przekierowują na małe litery za pomocą przekierowania 301. Zabezpieczy to witrynę przed wszelkimi przyszłymi powielaniami, do których prowadzą zarówno adresy URL pisane wielkimi, jak i małymi literami.

Dodanie reguły przekierowania 301 skonsoliduje również wszelkie wartości linków, w których zewnętrzna witryna może omyłkowo prowadzić do Twojej witryny za pomocą dużej litery.

Jeśli przekierowanie 301 nie jest możliwe, zalecamy dodanie tagu kanonicznego w kodzie źródłowym adresów URL pisanych wielkimi literami, aby odwoływać się do wersji adresu URL pisanej małymi literami.

3. Przekierowanie HTTP 302 na HTTPS

Kwestia:

Firmy często migrują swoje witryny do bezpiecznych adresów URL HTTPS, ale nie zawsze wdrażają regułę przekierowania 301, a zamiast tego implementują przekierowanie 302, więc teoretycznie mówi to wyszukiwarkom, że wersja HTTP adresu URL została przeniesiona tylko tymczasowo, a nie na stałe. Może to zmniejszyć wartość linków i ogólny autorytet Twojej witryny, ponieważ adresy URL HTTP, które z czasem uzyskały linki zwrotne, nie przekażą w pełni wartości linków do wersji HTTPS, chyba że zostanie zastosowane przekierowanie 301.

Rozwiązanie:

Zalecamy skonfigurowanie reguły na poziomie serwera, w której wszystkie adresy URL HTTP 301 przekierowują do wersji HTTPS.

4. Kanoniczne adresy URL wpływające na linki wewnętrzne

Kwestia:

W wielu witrynach e-commerce widzieliśmy produkty, które mają wiele odmian adresu URL produktu, ale każda odmiana zawiera link do kanonicznego adresu URL produktu, aby zapobiec duplikowaniu. Jednak kanoniczną stronę produktu można znaleźć tylko za pomocą kanonicznych tagów i żadnych innych wewnętrznych linków.

Ponadto kanoniczna strona produktu nie zawiera żadnych okruszków, które wpływają na wewnętrzne linki w witrynie.

Ta wewnętrzna konfiguracja kanoniczna linków czasami uniemożliwiała wyszukiwarkom pobranie kanonicznej wersji adresu URL z powodu zignorowania instrukcji, ponieważ linki wewnętrzne w całej witrynie wysyłają mieszane sygnały. Może to spowodować indeksowanie niekanonicznych wersji produktów, co powoduje kanibalizację adresów URL, co ostatecznie negatywnie wpływa na wydajność SEO.

Rozwiązanie:

Aby ułatwić indeksowanie kanonicznych adresów URL, witryny internetowe powinny:

Dodaj kanoniczne adresy URL do mapy witryny XML, a nie do innych wariantów adresów URL

Wewnętrzne linki do kanonicznych wersji adresów URL w ramach wewnętrznych modułów linkowania dla całej witryny, takich jak „popularne produkty”

Dodaj podstawową strukturę nawigacyjną do strony kanonicznego adresu URL.

5. Kanoniczne adresy URL z linkami do 404 adresów URL

Kwestia:

Kanoniczne adresy URL czasami odwołują się do 404 adresów URL, ale to wysyła mieszane sygnały do ​​wyszukiwania

silniki. Kanoniczny adres URL nakazuje robotowi indeksującemu preferowany adres URL indeksowanie, ale obecnie preferowany adres URL już nie istnieje.

Rozwiązanie:

Po pierwsze, należy ustalić, czy kanoniczny adres URL powinien mieć wartość 404, czy też powinien zostać przywrócony. Jeśli zostanie przywrócony, problem zostanie rozwiązany, jednak jeśli kanoniczny adres URL powinien mieć wartość 404, należy wybrać nowy kanoniczny adres URL lub zaktualizować kanoniczny, aby był odwołujący się do siebie.

6. Wiele tagów kanonicznych

Kwestia:

W kodzie HTML strony internetowej czasami mogą znajdować się dwa znaczniki kanoniczne. Może to spowodować wysyłanie sprzecznych wiadomości do wyszukiwarki i tylko pierwsza kanoniczna będzie liczona i używana.

Rozwiązanie:

Niektóre roboty indeksujące witryny mogą oznaczać wiele tagów kanonicznych, jednak jeśli tak nie jest, podczas indeksowania witryny należy skonfigurować wyodrębnianie niestandardowe, aby wyszukać wiele tagów kanonicznych.

Strony internetowe z wieloma znacznikami kanonicznymi w kodzie HTML muszą zostać zaktualizowane, gdy jeden z nich zostanie usunięty i pozostanie tylko poprawny znacznik kanoniczny.

7. Powielanie strony głównej

Kwestia:

Witryny czasami mają wiele adresów URL stron głównych, co powoduje duplikację i może spowodować podział kapitału linków. Typowe adresy URL zduplikowanych stron głównych obejmują:

www.example.com

www.example.com/home

www.example.com/index.html

www.example.com/home.html

Rozwiązanie:

Jeśli Twoja witryna ma wiele adresów URL stron głównych, zalecamy skonfigurowanie przekierowania 301, w którym wszystkie wersje duplikatów przekierowują do głównej wersji strony głównej.

8. Różne wersje witryn na urządzenia mobilne i komputerowe

Kwestia:

Witryny mobilne powinny zawierać tę samą treść, co komputerowa wersja witryny. Przeprowadzając audyty witryn i porównując indeksowanie witryn na komputery z urządzeniami mobilnymi, na niektórych stronach natrafiliśmy na różnice w treści, polegające na tym, że wersja mobilna zawiera mniej treści niż wersja komputerowa.

Może to powodować problemy, ponieważ prawie całe indeksowanie witryny pochodzi z wersji mobilnej, a jeśli brakuje priorytetowej treści, rankingi mogą zacząć spadać.

Rozwiązanie:

Wersja mobilna witryny powinna zawierać taką samą treść jak wersja komputerowa, a brakujące treści należy dodać do witryny mobilnej.

9. Międzynarodowe wykrywanie IP

Kwestia:

W przypadku witryn, które zaimplementowały przekierowania geograficzne IP, najczęstszym problemem jest to, że implementacja przekierowuje wszystkich użytkowników, w tym boty.

Googlebot zwykle indeksuje z amerykańskiego adresu IP, a jeśli boty są przekierowywane na podstawie lokalizacji geograficznej, Googlebot będzie indeksować i indeksować tylko amerykańską wersję witryny. Zapobiegnie to przemierzaniu i indeksowaniu innych geograficznych wersji witryny.

Ponadto może to powodować problemy z cenami produktów Oznaczenia schematu w witrynach e-commerce, w których ceny są aktualizowane na podstawie lokalizacji geograficznej, ponieważ na wszystkich rynkach pojawi się tylko cena w USA. Na przykład poniższy fragment przedstawia ceny w USA w brytyjskiej wersji witryny w Wielkiej Brytanii.

Rozwiązanie:

Jeśli musisz wdrożyć przekierowania geograficznego adresu IP, zalecamy wykluczenie wszystkich botów z reguł przekierowań, ponieważ umożliwi to botom, takim jak Googlebot, przemierzanie i indeksowanie wszystkich wersji międzynarodowych.

Jeśli nie wdrożysz przekierowań geo IP, zalecamy utrzymywanie otwartych witryn dla wszystkich użytkowników z dowolnej geolokalizacji i wyświetlanie przyjaznego dla użytkownika banera JavaScript, który umożliwia użytkownikom wybór własnego języka/lokalizacji.

Jest to przydatna funkcja UX, jeśli użytkownik wylądował na nieprawidłowej międzynarodowej wersji strony internetowej. Wyskakujące okienko pojawi się w oparciu o wykrycie adresu IP, na przykład, jeśli użytkownik przejdzie na stronę internetową w USA z adresu IP w Wielkiej Brytanii, pojawi się baner z informacją, że witryna w Wielkiej Brytanii może być bardziej odpowiednia.

10. Powielanie stron międzynarodowych

Kwestia:

Wiele wersji witryny jest często spotykane, gdy firmy działają w różnych krajach na całym świecie. Jest to powszechna praktyka, ponieważ najlepiej jest zapewnić użytkownikom jak najlepsze wrażenia, a w tym celu strony internetowe dla poszczególnych krajów umożliwiają firmom dostosowywanie ścieżki użytkownika w zależności od tego, gdzie użytkownik znajduje się na świecie.

Jednak firmy mogą popełnić błąd, tworząc wiele wersji swojej witryny, ale nie wysyłają żadnych sygnałów do wyszukiwarek, aby wskazać, która witryna powinna być kierowana na określony kraj lub region.

Gdy właściciele witryn tworzą wiele wersji witryn bez instrukcji dla wyszukiwarek, może to spowodować chaos, taki jak powielanie witryn i kanibalizacja między domenami.

Rozwiązanie:

Tworząc międzynarodowe wersje swojej witryny, należy używać tagów Hreflang, aby pomóc w sygnalizowaniu wyszukiwarkom, takim jak Google, właściwej strony internetowej do wyświetlenia użytkownikowi na podstawie jego lokalizacji i języka.

Tagi Hreflang zapobiegają również postrzeganiu międzynarodowych wersji witryny jako duplikatów przez wyszukiwarki, ponieważ tag Hreflang zasadniczo wskazuje, że do obsługi użytkownika w lokalizacji X potrzebna jest konkretna strona z ustawieniem języka X.

Konfigurowanie i mapowanie tagów Hreflang może być mylące i jest dużym zadaniem w zależności od rozmiaru Twojej witryny. Nieprawidłowa konfiguracja może mieć negatywny wpływ na ruch w witrynie.

Zapraszamy do odwiedzenia naszej międzynarodowej strony usług SEO, jeśli planujesz międzynarodową ekspansję witryny lub masz problemy ze swoimi międzynarodowymi witrynami.

11. Mapa witryny XML zawierająca historyczne adresy URL i tymczasowe adresy URL

Kwestia:

Interesującym problemem, z którym spotykamy się częściej, niż mogłoby się wydawać, są strony internetowe mające stare adresy URL w swoich mapach witryn XML lub tymczasowe adresy URL, które w jakiś sposób wciskają się w mapę witryny XML.

Może to powodować problemy, ponieważ jeśli w mapach witryn pojawiają się tymczasowe adresy URL, a Twoja witryna może nie być blokowana przez wyszukiwarki, te adresy URL mogą zacząć być indeksowane, co z kolei może powodować niepotrzebne powielanie.

Historyczne adresy URL w Twojej mapie witryny, które mają teraz kod stanu 4xx lub 3xx, mogą wysyłać mylące sygnały do ​​wyszukiwarek, na których stronach chcesz zindeksować lub zaindeksować.

Rozwiązanie:

Pamiętaj, aby regularnie kontrolować swoją mapę witryny XML, obserwując Search Console i monitorując pojawiające się błędy lub konfigurując regularne indeksowanie w narzędziu takim jak Deepcrawl.

Skonfigurowanie regularnego indeksowania map witryn XML w Deepcrawl jest bardzo przydatne, ponieważ może szybko oznaczać wszystkie adresy URL, które nie powinny pojawiać się w mapie witryny, i pozwala śledzić ten potencjalny problem.

12. Indeksowanie witryny inscenizacyjnej powodującej duplikację

Kwestia:

Co zaskakujące, wiele firm ma swoje strony internetowe, które można indeksować w wyszukiwarkach takich jak Google, nie celowo, ale przez pomyłkę. Może to spowodować znaczne zduplikowanie, ponieważ pomostowa witryna zwykle będzie repliką Twojego aktywnego środowiska. Od wykonania prostego wyszukiwania protokołu URL w Google istnieją miliony tymczasowych stron internetowych, które można zindeksować.

Rozwiązanie:

W Semetrical zalecamy dodanie warstwy uwierzytelniającej, w której musisz wprowadzić nazwę użytkownika i hasło, aby uzyskać dostęp do strony testowej. Dodanie reguły zakazu jest również opcją zapobiegającą indeksowaniu środowisk pomostowych, jednak lepiej jest to zaimplementować, jeśli witryna pomostowa nie została jeszcze zindeksowana. Na przykład:

Agent użytkownika: *

Uniemożliwić: /

Większość narzędzi do indeksowania witryn internetowych ma wbudowaną funkcję nadpisywania pliku robots.txt, dzięki czemu można łatwo pominąć regułę zakazu podczas przeprowadzania testów w środowisku pomostowym.

13. Indeksowanie wyszukiwania wewnętrznego

Kwestia:

Wewnętrzne adresy URL wyszukiwania w witrynach internetowych mogą być świetne dla SEO, ponieważ pozwalają witrynom na pozycjonowanie pod kątem zapytań wyszukiwania o bardzo długim ogonie lub na pozycjonowanie słów kluczowych, w których nie mają głównego adresu URL do rankingu.

Jednak w wielu przypadkach wewnętrzne strony wyszukiwania mogą powodować wiele duplikacji w witrynach internetowych, a także mogą powodować problemy z budżetem indeksowania w witrynach na dużą skalę. W tym przewodniku skupimy się na negatywnej stronie wyszukiwania wewnętrznego.

Wewnętrzne strony wyszukiwania są zwykle bardzo niskiej jakości, ponieważ nie będą optymalizowane i często są klasyfikowane jako cienkie treści, ponieważ zawierają niewielką liczbę wyników, takich jak produkty.

Rozwiązanie:

Przed podjęciem decyzji o zablokowaniu wewnętrznych stron wyszukiwania zaleca się sprawdzenie, czy te strony nie mają obecnie pozycji w rankingu pod kątem żadnych słów kluczowych lub nie generują regularnego ruchu.

Dodatkowo sprawdź, czy te adresy URL nie zbudowały linków zwrotnych przez lata. Jeśli Twoje wewnętrzne strony wyszukiwania nie mają autorytatywnych linków zwrotnych i nie generują ruchu organicznego, w Semetrical zalecamy dwa kroki:

Krok pierwszy: Dodaj znaczniki NOINDEX, FOLLOW do wszystkich stron wyszukiwania, aby umożliwić wyszukiwarkom deindeksowanie tych stron. Gdy te strony zostaną usunięte z indeksu w ciągu kilku miesięcy, wdrożymy krok drugi.

Krok drugi: Dodaj wewnętrzny katalog wyszukiwania do pliku robots.txt, na przykład Disallow: */search*

14. Parametry powodujące powielanie

Kwestia:

Duplikacja parametrów sortowania i filtrowania może być częstym problemem podczas audytu witryn internetowych. Wiele witryn korzysta z filtrów, ponieważ może to poprawić wrażenia użytkownika i umożliwić użytkownikom filtrowanie wyników wyszukiwania. Jednak głównym problemem jest to, że witryny internetowe utrzymują indeksowanie filtrów, ponieważ generuje to znaczną ilość duplikatów w całej witrynie. Na przykład:

Od czasu do czasu natkniemy się na witryny, które dodają parametry śledzenia na końcu adresów URL w linkach wewnętrznych, aby wskazać, gdzie w witrynie kliknięto ten link. Nie zalecamy tej konfiguracji w pierwszej kolejności, jednak gdy witryny już ją mają, może to spowodować wiele duplikacji w witrynie, ponieważ może tworzyć wiele wersji tej samej strony. Na przykład:

Innymi typowymi parametrami śledzenia, które mogą powodować duplikację, są parametry śledzenia UTM, w których linki są używane do określonych kampanii w celu śledzenia skuteczności kampanii. Na przykład:

Rozwiązanie:

Istnieje wiele sposobów zapobiegania indeksowaniu parametrów i powodowaniu duplikacji, między innymi:

Kanonizacja adresu URL parametru do czystej wersji adresu URL

Dodanie reguły w pliku robots.txt, aby zabronić określonych parametrów

Dodanie parametrów do narzędzia parametrów adresów URL w Search Console, które sygnalizuje Google, że niektóre parametry nie powinny być indeksowane.

15. Powielanie adresu URL produktu

Kwestia:

W witrynach e-commerce duplikacja adresów URL produktów może być dużym problemem, podobnie jak w witrynach wydawców. Głównym powodem duplikowania adresu URL produktu jest to, że produkty mogą dziedziczyć kategorię/podkategorię w swojej strukturze adresu URL, a jeśli produkt znajduje się w wielu kategoriach/podkategoriach, w związku z tym tworzonych jest wiele adresów URL.

W witrynach wydawców dokumenty mogą również znajdować się w wielu obszarach, a jeśli adres URL dokumentu dziedziczy lokalizację dokumentu, tworzonych jest wiele wersji. Na przykład:

Rozwiązanie:

Gdy natkniemy się na takie powielanie, istnieje wiele sposobów na jego usunięcie, dzięki czemu możemy upewnić się, że przeszukiwana i indeksowana jest poprawna wersja adresu URL.

Aby naprawić duplikację adresu URL, zalecamy kanonizację wszystkich wariantów adresu URL produktu do wersji nadrzędnej lub do wersji ogólnej. Na przykład:

Rodzicowy przykład kanoniczny

kobiety-kolekcje-sukienki-sukienki-dzienne

/71hdo/bella-lula-kwiecista-mini-sukienka

kanonizowałby do:

kobiety-kolekcje-sukienki

/71hdo/bella-lula-kwiecista-mini-sukienka

Ogólny przykład kanoniczny:

kobiety-kolekcje-sukienki-sukienki-dzienne

/71hdo/bella-lula-kwiecista-mini-sukienka

kobiety-kolekcje-sukienki

/71hdo/bella-lula-kwiecista-mini-sukienka

Czy kanonizować do

Alternatywy:

Jeśli masz dostęp do programistów, alternatywnym rozwiązaniem byłoby wewnętrzne linkowanie do kanonicznych produktów w całej witrynie i przekierowanie 301 wszystkich adresów URL produktów, które są uruchamiane z kategorii/podkategorii do ogólnego kanonicznego adresu URL produktu.

Zatrzymałoby to powielanie produktów i umożliwiłoby łączenie się z produktami wieloma trasami

16. Głębokość strony internetowej

Kwestia:

Głębokość strony to liczba kliknięć określonej strony ze strony głównej witryny. Podczas przeprowadzania audytów witryn natrafiamy na strony, które mają głębokość większą niż 10. Oznacza to, że te strony są oddalone o 10 kliknięć od strony głównej!

Im więcej kliknięć potrzeba, aby znaleźć stronę internetową, tym trudniej wyszukiwarce znaleźć ten adres URL i jest bardziej prawdopodobne, że adres URL nie będzie odwiedzany tak często, jak strony znajdujące się wyżej w witrynie.

Dodatkowo, im wyższa strona znajduje się w architekturze Twojej witryny, tym większa szansa, że ​​będzie ona postrzegana jako strona priorytetowa przez wyszukiwarki. Jeśli strony priorytetowe znajdują się niżej w architekturze, istnieje ryzyko, że nie będzie ona równie rangowana.

Rozwiązanie:

Główne sposoby na zwiększenie głębi witryny i upewnienie się, że strony priorytetowe znajdują się wysoko w architekturze witryny, obejmują:

Wewnętrzne linki w witrynie, takie jak polecane produkty, produkty powiązane i polecane strony

Korzystanie z bułki tartej w całej witrynie

Konfigurowanie paginacji obejmującej pierwszą, ostatnią i dwie strony wyników po obu stronach strony, na której się znajdujesz

Przeprowadzanie badań słów kluczowych w celu odkrycia stron kategorii najwyższego poziomu, które powinny być połączone w głównej nawigacji witryny i dodawanie linków do stron priorytetowych

17. Problemy techniczne z SEO w JavaScript

Kwestia

Wiele witryn korzysta obecnie z JavaScript, jednak po wyłączeniu JavaScript niektóre witryny nie są w pełni funkcjonalne, a linki mogą zniknąć i nie będzie można ich znaleźć dla wyszukiwarek. Jest to częsty problem techniczny SEO.

Często widzimy, że moduły „możesz też polubić” na stronach produktów e-commerce nie są widoczne dla robotów wyszukiwarek, co sprawia, że ​​wewnętrzny moduł linkowania jest zbędny.

Ponadto w modułach JavaScript znajdują się moduły recenzji zawierające bogaty w słowa kluczowe treści UGC, które również nie mogą być wykrywane przez roboty indeksujące.

Interesującym problemem, z jakim borykają się różne witryny e-commerce, jest wyłączenie JavaScriptu na stronach wyników, linki do produktów nadal można znaleźć, ale wszystkie obrazy znikają, ponieważ nie ma opcji powrotu do odkrycia obrazów.

Rozwiązanie:

Współpracuj z zespołem programistów, aby spróbować utworzyć awaryjny kod JavaScript, w którym obrazy są nadal obecne w kodzie źródłowym, a także moduły JavaScript, które można indeksować za pomocą kodu HTML.

Świetnym sposobem sprawdzenia, w jaki sposób jest indeksowana treść JavaScript, jest przejście do wersji witryny z pamięci podręcznej i sprawdzenie, jak wygląda „pełna wersja” strony, a także sprawdzenie „wersji tylko tekstowej”.

18. Nieprawidłowe użycie Meta Robots NOINDEX

Kwestia:

Nasz zespół techniczny SEO przeprowadził audyt witryn internetowych i odkrył, że tagi NOINDEX zostały przez pomyłkę dodane do kodu źródłowego stron. Ponadto widziano strony, które w przeszłości powodowały ruch, z tagiem NOINDEX.

Co zaskakujące, problem, który może się zdarzać częściej, niż mogłoby się wydawać, polega na tym, że programiści wypychają środowiska pomostowe na żywo z tagiem NOINDEX nadal obecnym w kodzie źródłowym.

Ostatecznie tag NOINDEX poinformuje wyszukiwarki, aby nie indeksowały strony i uniemożliwi jej wyświetlanie w wynikach wyszukiwania.

Rozwiązanie:

Jeśli natrafisz na strony, które mają tag NOINDEX podczas audytu witryny i nie jest jasne, dlaczego tag jest na miejscu, skontaktuj się z zespołem programistów, aby dowiedzieć się, kiedy i dlaczego te strony zawierają ten tag.

Jeśli tag NOINDEX został dodany przez pomyłkę, powinieneś poprosić programistów o zaktualizowanie kodu źródłowego i całkowite usunięcie tagu lub zaktualizowanie go tak, aby czytał <meta name=”robots” content=”INDEX, FOLLOW”>

19. Miękkie strony 404

Kwestia:

Miękka strona 404 nie powinna istnieć w witrynie, dzieje się tak, gdy nieistniejąca strona, która powinna zwrócić kod stanu 404, zwraca kod stanu 200 OK. Jeśli strony 404 zwracają kod stanu 200, nadal można je przeszukiwać i indeksować.

Jest to ostatecznie problem, ponieważ wyszukiwarki, takie jak Google, mogą tracić czas na indeksowanie tych stron, które nie zapewniają wartości marnowania budżetu na indeksowanie, zamiast skupiać się na wartościowych stronach. Te strony mogą również tworzyć zduplikowane problemy w witrynie, zwłaszcza jeśli witryna ma tysiące miękkich stron 404 z komunikatem „nie znaleziono strony”.

Istnieje kilka różnych sposobów na znalezienie miękkich stron 404, które obejmują:

Odwiedzasz Search Console, gdzie oznacza miękkie strony 404

Indeksowanie witryny i szukanie 200 stron kodowych stanu z tagami tytułowymi „Nie znaleziono strony”

Indeksowanie witryny za pomocą niestandardowego wyodrębniania, które wyszukuje wiadomość kopii treści, która jest obecna na stronach kodowych stanu 404, a każda strona z kodem stanu 200 z tą wiadomością powinna być miękkim komunikatem 404

Rozwiązanie:

Jeśli natkniesz się na miękkie strony 404 w swojej witrynie, istnieje kilka rozwiązań, które można wdrożyć, są to między innymi:

301 przekierowuje miękkie strony 404 na odpowiednią alternatywną stronę, jeśli jest dostępna

Zmień kod statusu tych stron na kod statusu 404 lub 410, ale sprawdź, czy nie zostanie utracony kapitał linków.

Jeśli masz problemy ze swoją witryną lub potrzebujesz audytu technicznego SEO, odwiedź naszą stronę poświęconą usługom technicznym SEO, aby uzyskać więcej informacji o tym, jak Semetrical może pomóc.