W moim ostatnim poście dałem trzy powody, aby unikać przyspieszonych magów mobilnych (Ampery). Przyspieszone strony mobilne to płaskie strony HTML, które następują Google wytyczne i są obsługiwane przez Google, aby zwiększyć wydajność ładowania stron na urządzeniach mobilnych. Ponieważ czas ładowania jest czynnikiem rankingującym, AMP mają zwiększyć SEO. Trzy powody, dla których należy unikać AMP, sprowadzają się do jednego: potrzebujesz JavaScript, aby śledzić i mierzyć skuteczność marketingu oraz budować bardziej spersonalizowane treści. AMP nie zezwalają na JavaScript. Tak więc w przypadku wielu treści marketingowych AMP są niekontrolowane.
Jest czwarty powód, dla którego potrzebujesz JavaScript na swoich stronach: międzynarodowy SEO. Jeśli spróbujesz obsłużyć płaską treść HTML zaprojektowaną dla każdego z krajów, w których prowadzisz działalność, narazisz się na agresywny algorytm filtrowania antyduplikacyjnego Google. Ten artykuł opowiada o tym, jak odkryliśmy ten oczywisty konflikt w standardach Google pod adresem IBM . Ostatecznie było dla nas jasne, że AMP są niezgodne z międzynarodowym SEO. Po tym, jak opowiem tę historię, mam nadzieję, że i ty wyciągniesz ten wniosek.
IBM zmaga się z międzynarodowym SEO
Duże przedsiębiorstwa, które próbują podawać tę samą treść użytkownikom w różnych krajach, od dawna walczą o to, by skutecznie to robić. W IBM próbowaliśmy niemal każdej taktyki, aby poinformować Google, że określony kraj i wersja językowa strony są unikalne dla tego kraju. Na początku próbowaliśmy Dublin Core metadane. Google zignorował to, ponieważ wykonuje większość metadanych w elemencie <head> strony HTML.
Następnie próbowaliśmy umieścić kod kraju i języka (cc-lc) w adresie URL. Google zignorował także nasze kody krajów i języków. W rezultacie, gdyby dwie strony w tym samym języku były kierowane do różnych krajów, Google zdecydowałoby się na uszeregowanie tego, który najbardziej pasował do zapytania. W większości przypadków w języku angielskim była to strona amerykańska, ponieważ treść pochodziła z USA i była częściej aktualizowana w USA. Tak więc ekologiczni użytkownicy wyszukiwania w Wielkiej Brytanii otrzymają strony w USA.
Był to problem, gdy strony zawierały oferty specyficzne dla USA. Był to szczególnie problem, gdy strona amerykańska miała amerykańskie moduły kontaktowe i ceny. Nasza brytyjska organizacja marketingowa musiała wydać o wiele więcej pieniędzy na płatne wyszukiwanie, aby uzyskać pożądane wyniki, ponieważ po prostu nie mogły przewyższyć naszych amerykańskich stron w wyszukiwaniu organicznym.
Ostatnio próbowaliśmy przenieść ten kod cc-lc na początek ciągu URL i zarejestrować go Google Search Console . Własne Google Wskazówki dla webmasterów zasugeruj tę taktykę, szczególnie w przypadku stron produktów, w których najlepszym interesie jest udostępnienie właściwej strony prawidłowemu użytkownikowi w odpowiednim kraju. Z powodów, które zostaną wyjaśnione, działało to wystarczająco dobrze, dopóki strony nie miały duplikatów treści.
Oczywiście połączyliśmy taktykę URL z HREFLANG i kanoniczny tagi. Razem wydawało się, że działają one na zasadzie rankingu stron. Innymi słowy, jeśli strona znajdowała się w indeksie Google i kody te zostały wykonane poprawnie, Google wyświetli odpowiednią stronę w odpowiednim kraju i języku w wynikach wyszukiwania.
Ale na początku tego roku Google zaczęło agresywnie usuwać strony ze swojego indeksu, który uważał za duplikaty. To usunięcie dzieje się poza algorytmem rankingu, więc kody używane do próby poinformowania Google o stronie dla określonego kraju nie działają
Według Google algorytm porównuje tekst na stronie . Jeśli dwie strony mają wiele duplikatów bloków treści, algorytm oznacza je jako duplikaty. Google nie publikuje swoich algorytmów, ponieważ dawałoby to czarnym kapeluszom SEO przepis na manipulowanie wynikami wyszukiwania. Ale konsensus wśród SEO jest taki, że jeśli dwie strony mają więcej niż 70 procent tych samych słów, uważa je za duplikaty i kieruje je do usunięcia z indeksu. W ubiegłym roku Google odfiltrowało miliony stron IBM.com ze swojego indeksu.
Kiedy skontaktowaliśmy się z Google, aby zapytać, dlaczego odfiltrowali tak wiele naszych stron, jako problem podali powielone treści. Zalecili, abyśmy tworzyli unikalne treści dla każdego języka i kraju. To nie jest opcja dla firmy, która prowadzi działalność w 150 krajach i dziesiątkach języków. Zazwyczaj tworzymy jeden zestaw treści i lokalizujemy go na wszystkich odpowiednich rynkach. Na rynkach anglojęzycznych i hiszpańskich oznacza to tworzenie duplikatów funkcjonalnych.
Clincher był szalonym aspektem filtra indeksów Google. Po znalezieniu duplikatów w indeksie pozostawił jeden losowy duplikat w indeksie, który byłby obsługiwany na wszystkich rynkach mówiących tym językiem. W przypadku niektórych z naszych najważniejszych wyszukiwań produktów strona była wyświetlana na Bahamach na wszystkich rynkach anglojęzycznych, w tym w USA. Kiedy się o tym dowiedzieliśmy, wiedzieliśmy, że musimy znaleźć rozwiązanie naszego problemu z duplikatem treści.
Najpierw język
Rozwiązanie można znaleźć w oficjalnych wskazówkach na stronie dla webmasterów powiązanych z powyższym:
Jeśli masz wiele stron podobnych, rozważ rozszerzenie każdej strony lub konsolidację stron w jedną. Na przykład, jeśli masz witrynę podróży z oddzielnymi stronami dla dwóch miast, ale te same informacje na obu stronach, możesz albo połączyć strony na jednej stronie o obu miastach, albo rozwinąć każdą stronę, aby zawierała unikalną treść o każdym mieście. [podkreślenie moje]
Rozwiązanie jest w rzeczywistości dość proste. Jak już powiedziałem, nie jest dla nas rozwiązaniem, aby opracować tak unikalne treści na każdym rynku. Zajęłoby to większą armię copywriterów i redaktorów, niż możemy sobie na to pozwolić. Skupimy się więc na łączeniu stron w jedną stronę kanoniczną.
Zamiast publikować inny adres URL dla każdej kombinacji języka i kraju, spróbujemy opublikować jeden adres URL dla każdego języka dla każdej strony marketingowej. Następnie użyjemy dynamicznych systemów do załadowania unikalnych aspektów tych doświadczeń użytkownikom w poszczególnych krajach.
Na przykład użytkownicy w USA otrzymają wszystkie informacje o walucie w dolarach po wykryciu przez system ich adresu IP. Wszystko, co lokalny rynek chce promować na tej stronie, można załadować w tym samym czasie, w tym lokalne oferty, wydarzenia lub partnerzy. W przypadku IBM język jako pierwszy zmniejszyłby nasz ślad treści o współczynnik 10. To ogromna korzyść niezależna od SEO.
Ponieważ w każdym języku jest tylko jedna strona, nie ma szans, że system będzie działał z filtrem duplikatów treści Google. Ale wyzwaniem jest dynamicznie ładowana zawartość. Oczywiście musimy załadować JavaScript, aby załadować treści specyficzne dla kraju. Ponieważ specyfikacja AMP Google blokuje JavaScript, po prostu nie możesz zrobić języka najpierw ze stronami AMP.
Jeśli prowadzisz mniejsze przedsiębiorstwo, możesz stworzyć unikatową treść dla każdego kraju i kombinacji językowej i obsługiwać je za pośrednictwem Google AMP. Ale dla przedsiębiorstwa z tysiącami marketerów tworzących codziennie treści istnieje tylko jeden zrównoważony model: język jako pierwszy.
Polub ten post?
Zarejestruj się tutaj, aby otrzymywać nasze e-maile.
O James Mathewson
James Mathewson jest poszukiwanym specjalistą ds. Technicznych w IBM. Ma 20 lat doświadczenia w redagowaniu stron internetowych, strategii treści i SEO dla dużych i małych firm. Częsty mówca, wykładowca i bloger, James opublikował ponad 1600 artykułów i dwie książki o tym, jak technologia internetowa i doświadczenie użytkowników zmieniają charakter skutecznej treści. James ma dwa stopnie naukowe na pokrewnych przedmiotach z University of Minnesota.
Polub ten post?