5 sposobów wykorzystania plików dziennika do SEO z Gerry White

W jaki sposób korzystasz z plików dziennika, aby poprawić swoje SEO?

O tym właśnie porozmawiamy dzisiaj z mężczyzną z ponad 20-letnim doświadczeniem w branży SEO, pracującym dla marek i agencji, w tym BBC, Just Eat i Rise at Seven. Serdecznie witamy w podcaście In Search SEO, Gerry White.

W tym odcinku Gerry dzieli się pięcioma sposobami wykorzystania plików dziennika do SEO, w tym:

• Zobacz, jak Google patrzy na Twoją witrynę
• Parametry
• Czy istnieją subdomeny zużywające Twój budżet na indeksowanie
• Pliki JavaScript i CSS
• Kody odpowiedzi

Gerry: Hej, cieszę się, że tu jestem.

D: Dobrze, że jesteś. Możesz znaleźć Gerry'ego, wyszukując Gerry'ego White'a na LinkedIn. Więc Gerry, czy każdy SEO powinien używać plików dziennika?

G: Nie, wiem, że brzmi to kontrowersyjnie, kiedy mówię, że pliki dziennika zawierają ogromne ilości informacji. Ale szczerze mówiąc, przez większość czasu jest to malejące zyski. I często można ogólnie znaleźć wiele informacji, zanim przejdzie się do plików dziennika. Mam na myśli to, że jeśli spojrzysz na informacje w Google Search Console, znajdziesz tam ogromne ilości informacji. Kiedy przeglądałem pliki dziennika, to wtedy po raz pierwszy wyczerpałem wiele innych miejsc. Zawsze zalecam zaindeksowanie witryny za pomocą narzędzia takiego jak Screaming Frog lub innego robota indeksującego, jaki masz, a następnie przejrzenie Google Search Console, zanim zaczniesz przeglądać pliki dziennika.

Powodem, dla którego to mówię, i powodem, dla którego brzmię prawie przeciw plikom dziennika, kiedy mam zamiar mówić o ich użyteczności, jest fakt, że początkowo praca z nimi jest dość trudna. Potrzeba trochę umiejętności, wiedzy i doświadczenia, aby naprawdę dostać się do nich, a nawet uzyskać do nich dostęp. Ale jedną wspaniałą rzeczą w dzisiejszych czasach jest fakt, że teraz mamy większy dostęp do plików dziennika niż prawie kiedykolwiek wcześniej. Początkowo, kiedy zaczynałem, nie mieliśmy Google Analytics ani żadnego oprogramowania analitycznego, jakie mamy dzisiaj. Analiza pliku dziennika polegała na tym, jak przyjrzeliśmy się, w jaki sposób ludzie odwiedzają strony internetowe. Teraz rzadko patrzymy na pliki dziennika, jak ludzie patrzą na strony internetowe, chyba że robimy coś z InfoSec. Albo robimy coś, żeby zdiagnozować coś naprawdę dziwnego i wspaniałego.

Ale tak naprawdę przez większość czasu mamy znacznie lepsze oprogramowanie analityczne. To może się zmienić, ponieważ w rzeczywistości jedną dziwną rzeczą jest fakt, że wiele witryn nie może śledzić, ile osób przechodzi na stronę 404, ponieważ przez większość czasu nigdy nie klikasz, że akceptujesz pliki cookie na stronie 404 . Nagle pliki dziennika znów wracają, aby odpowiedzieć na takie bardzo dziwne pytania.

Ale głównym powodem, dla którego mówię dzisiaj o plikach dziennika, są cele SEO. Więc tak, jeśli masz problemy z dużymi witrynami, jeśli masz dużą witrynę e-commerce, jeśli masz międzynarodową, wielojęzyczną, ogromną witrynę z fasetową nawigacją, pliki dziennika to coś, co zdecydowanie należy wziąć pod uwagę i zdecydowanie należy je jak najszybciej przeanalizować.

D: Więc dzisiaj dzielisz się pięcioma sposobami, w jakie SEO powinno używać plików dziennika. Zacznij od numeru 1, zobacz, jak Google patrzy na Twoją witrynę.

1. Zobacz, jak Google patrzy na Twoją witrynę

G: Tak, Google jest dość nieprzewidywalny, prawie jak niesforne dziecko. To dziwne, ponieważ chociaż mówię, że możemy przeglądać witryny i używać narzędzi do indeksowania, aby zobaczyć, jak Google powinien patrzeć na witrynę, często jesteśmy zaskoczeni, gdy dowiadujemy się, że Google ma obsesję na punkcie jednego zestawu stron lub gdzieś w dół jakąś dziwną trasą. Niedawno pracowałem przez ostatni rok dla supermarketu o nazwie Odor i jedną z rzeczy, które odkryliśmy, było to, że bot Google bardzo uważnie przyglądał się konfiguracji analitycznej i tworzył z niej sztuczne linki. Google znajduje zepsute linki. I przez długi czas próbowałem dowiedzieć się, dlaczego znajduje dziesiątki 1000 404, których w ogóle nie ma na stronie. Ale okazuje się, że patrzy na konfigurację analityczną i tworzy z niej link. Sprawdzamy więc, jaki to miało wpływ. A jeśli spojrzymy na fakt, że Google znajduje wszystkie te 404, może to nie być ogromny problem. Ale teraz chcemy wiedzieć, ile czasu spędza na tych 404, a jeśli naprawimy ten jeden mały problem, czy oznacza to, że indeksowanie reszty witryny wzrośnie o 20-30%? Jaka jest szansa, jeśli naprawimy to tam? Wszystko sprowadza się do przyjrzenia się, dlaczego Google patrzy na tę witrynę w ten sposób i co znajduje, czego tak naprawdę nie powinno znajdować.

2. Parametry

Inną rzeczą, na którą często patrzymy, są parametry. Nie wiem, czy wiesz, ale ludzie zajmujący się SEO zawsze linkują do kanonicznej wersji strony. Chodzi mi o to, że często istnieje wiele wersji strony, które czasami mają jakieś wewnętrzne lub zewnętrzne śledzenie. Jest tak wiele sposobów, w jakie możemy połączyć się ze stroną, a często na przykład produkt może znajdować się w wielu miejscach w witrynie. Dobrym tego przykładem jest to, że pracowałem na stronie, którą był Magento. Każdy produkt wydawał się mieścić w każdej kategorii, więc było niesamowite, gdy dowiedzieliśmy się, że istnieje około 20 wersji każdego produktu, a każdy produkt można zindeksować. Od tego momentu wiedzieliśmy, że Google spędza dużo czasu na indeksowaniu witryny. Co ciekawe, jeśli usuniesz produkt, Google powie „Och, ale mam 19 innych wersji tego produktu”, więc minie trochę czasu, zanim rzeczywista strona prawie zniknie, jeśli korzystałeś 404 lub coś w tym stylu ze względu na sposób, w jaki działa Google. Google zobaczy, że jest to kanoniczna wersja tej strony. Ale jeśli usuniesz wersję kanoniczną, zacznie ona używać innych. I to jest rodzaj informacji, które daje nam logfile.Możliwość spojrzenia na witrynę w taki sposób, w jaki działa Google.

Pozwala nam również spojrzeć na takie rzeczy, jak kody statusu. Świetnym tego przykładem jest kod statusu, który mówi, że nie zostałem zmodyfikowany. I w tej chwili nie mogę myśleć, co to jest, powinienem był to zapisać przed tym podcastem. Ale zasadniczo „Nie zostałem zmodyfikowany” znacznie poprawia szybkość indeksowania witryny. A kiedy dowiaduję się, że Google to szanuje, mogę zrobić ze wszystkimi obrazami, wszystkimi produktami , i wszystkie te elementy, które nie są regularnie modyfikowane, jeśli możemy użyć niezmodyfikowanego i możemy poprawić szybkość indeksowania Google, poprawić efektywność i zmniejszyć obciążenie serwera, możemy następnie znacznie poprawić sposób, w jaki Google znajduje wszystkie różne produkty.

Sposób, w jaki Google patrzy na rzeczy, których chcemy, administratorzy serwerów i wszyscy chcą, polega na tym, aby serwer był tak szybki i wydajny, jak to tylko możliwe. Ponownie, wracając do strony plików dziennika, w dzisiejszych czasach nie mogliśmy w ogóle efektywnie używać plików dziennika przez wiele lat. Ponieważ w przypadku sieci CDN często można zauważyć, że istnieje wiele miejsc, w których strona zostanie trafiona. A CDN często nie miał samego pliku dziennika. Przyjrzymy się więc wszystkim tym różnym miejscom i zobaczymy, jakie jest obciążenie na tym serwerze i jakie jest obciążenie na tym serwerze. Staramy się złożyć wszystko w całość, a pliki dziennika będą miały inny format. Teraz dzięki sieciom CDN możemy faktycznie zacząć rozumieć skuteczność sieci CDN. Nagle rzeczy takie jak PageSpeed ​​zostały znacznie ulepszone i ulepszone przez fakt, że jeśli używamy plików dziennika, możemy zacząć rozumieć fakt, że obraz, na przykład poprzez kanonizację obrazów, więc jeśli jeden obraz jest używany na wielu stronach, jak dopóki adresy URL są spójne, CDN działa, a Google indeksuje je lepiej. Tak, jest tak wiele różnych sposobów, w jakie pliki dziennika pomagają ulepszyć PageSpeed, buforowanie i znacznie wydajniej obsługiwać użytkowników i wyszukiwarki.

D: Przeglądam twoje pięć punktów, którymi chciałeś się podzielić. Istnieją różne ich elementy, które już udostępniłeś. Przypominasz mi kogoś, komu mogę zadać tylko jedno pytanie, a on daje mi 15-minutowy odcinek podcastu bez zadawania dalszych pytań. Jest więc jedna osoba, która prawdopodobnie może to zrobić, nawet więcej niż ty. A to prawdopodobnie Duane Forrester. Duane i ja żartowaliśmy, że to zrobił, zadając mu tylko jedno pytanie, a potem odchodząc i zostawiając go, by podzielił się treścią do końca odcinka. Ale trochę mówiłeś o parametrach. Nie wiem, czy dotknąłeś punktu trzeciego, czyli odkrycia, czy istnieją subdomeny, które pochłaniają budżet indeksowania, ponieważ nie powinno ich być.

3. Czy istnieją subdomeny, które pochłaniają Twój budżet na indeksowanie?

G: Właściwie to wraca do Just Eat. W pewnym momencie odkryliśmy, że witryna była replikowana w wielu różnych subdomenach i wszystkie można było indeksować. Co ciekawe, według narzędzi takich jak Citrix nie były one widoczne. A powodem, dla którego tego nie zrobili, było to, że wszystko zostało kanonizowane. Kiedy więc dowiedzieliśmy się, że chociaż te duplikaty były dostępne, Google wydawał nieco mniej od 60 do 70% swojego budżetu na indeksowanie tych subdomen. A ze względu na sposób, w jaki nie były one buforowane w ten sam sposób z powodu sieci CDN i innych technologii, w rzeczywistości powodowało to duże obciążenie serwera. Było to więc dla nas coś fascynującego, ponieważ po prostu ignorowaliśmy to jako problem, który trzeba będzie naprawić w najbliższej przyszłości. Ponieważ wiedzieliśmy o problemie. Wiedzieliśmy, że jest jakiś problem i mówiłem o tym. Ale zmieniłem priorytet, dopóki nie zaczęliśmy przeglądać plików dziennika.

Widzieliśmy, że Google poświęca tutaj dużo energii, czasu i zasobów. Jakie jest obciążenie serwera? Jak duży był wpływ? I nie mogliśmy zrozumieć, jak duże było obciążenie serwera z powodu sposobu, w jaki serwer nie był w stanie zinterpretować różnych źródeł. To było fascynujące, że kiedy otrzymaliśmy pliki dziennika, mogliśmy znacznie poprawić niezawodność witryny. Wiedzieliśmy więc o subdomenach, ale nie wiedzieliśmy, jak duży to problem, dopóki nie zaczęliśmy przeglądać plików dziennika. A potem nagle zobaczyliśmy, że trzeba to naprawić jak najszybciej. To była jedna z tych rzeczy, które wiedzieliśmy, jak to naprawić, to było po prostu ustalenie priorytetów. Znajdował się na dole kolejki i awansował na drugie miejsce.

4. Pliki JavaScript i CSS

D: Wspomniałeś o kanonizacji, ale powiedziałeś też, że w szczególności pliki JavaScript i CSS mogą stanowić problem. Dlaczego?

G: Jedną z rzeczy, które często robimy, jest psucie pamięci podręcznej poprzez dodanie parametru do pliku CSS. Powodem, dla którego to robimy, jest to, co dzieje się, gdy używasz CDN lub czegoś podobnego, jest to, że za każdym razem, gdy aktualizujesz CSS, tworzysz nowe strony lub coś w tym rodzaju, problem polega na tym, że masz plik CSS, który jest buforowany i nowe strony nie będą mogły z niego korzystać. We wszystkich tych różnych plikach JavaScript i CSS mamy długi czas buforowania. Tak więc na stronie, gdy tylko dodamy coś, co wymaga aktualizacji JavaScript lub CSS, wystarczy nieznacznie zmienić parametr. Stamtąd musieliśmy upewnić się, że wszystkie różne serwery używają tej samej wersji parametrów w przyszłości. I to było coś, gdzie jeśli pracujesz w wielu różnych zespołach, wielu różnych witrynach internetowych, jeden lepszy JavaScript, który napędza całość, zawsze upewnialiśmy się, że jest to właściwa wersja. A pliki dziennika były jednym ze sposobów, dzięki którym upewniliśmy się, że wszystkie różne strony konsekwentnie uderzają we właściwą wersję JavaScript, ponieważ być może musieliśmy zaktualizować klucz API lub coś podobnego. Musieliśmy to zrobić na wiele różnych sposobów. I to było coś, co było ogromnym zadaniem dla programistów.

Jedną z rzeczy, na które patrzyliśmy w plikach dziennika, było to, czy stary był trafiony, skąd został trafiony i czy możemy to naprawić? Odkryliśmy również, że istnieje wiele różnych sposobów zapisania ścieżki do pliku JavaScript. Na przykład w subdomenie użyliśmy innej nazwy hosta, ponieważ, co ciekawe, jeśli pracujesz na wielu różnych stronach internetowych, często okazuje się, że istnieją różne adresy URL lub różne nazwy domen, które faktycznie uzyskują dostęp do tego samego serwera. I często, jeśli używasz CDN lub używasz podkatalogu, czasami może to być bardzo niespójne. Z punktu widzenia użytkownika, jeśli uderzasz w ten sam plik JavaScript na sześć lub siedem różnych sposobów w trakcie podróży, ładujesz go na sześć lub siedem różnych sposobów. I choć może to nie wydawać się dużo, łącznie dodaje to kilka megabajtów do Twojej podróży. A to oczywiście spowalnia całe doświadczenie i sprawia, że ​​serwery są mniej wydajne. I jest w tym znacznie więcej. Dlatego upewnij się, że zawsze trafiona jest właściwa wersja JavaScript, CSS i innych elementów. A także upewnij się, że nie ma powodu, aby JavaScript był ukryty za parametrami lub czymś takim. Istnieje wiele sposobów tworzenia pułapek na pająki, w tym pliki JavaScript, gdzie na przykład coś jest do nich tagowane, gdzie być może nie używają właściwego bezwzględnego odniesienia do JavaScript. Więc znajduje się w innym katalogu niż inne czasy. Zaskakujące jest, jak wiele różnych sposobów można zauważyć, kiedy JavaScript jest ładowany nieco inaczej przez wiele różnych stron. Więc tak, to bardzo proste. Ale jest to zaskakująco drogie, jeśli chodzi o analizę.

5. Kody odpowiedzi

D: Zapewnienie również, że kody odpowiedzi są dostarczane w pożądany sposób. Przykładem tego jest to, że TOS czasami jest widziany lub nie widziany przez Google, co powinno lub nie powinno być. Dlaczego więc miałoby się to stać?

G: Ponownie, zawsze odwiedzamy strony internetowe za pomocą tej samej przeglądarki, tej samej technologii, tego samego doświadczenia i wszystkiego. Staram się upewnić, że używam innych narzędzi niż te, których zwykle używam, ponieważ wszyscy przeprowadzają audyt Screaming Frog, więc staram się używać wszelkiego rodzaju drobiazgów. Ale zawsze udajemy, że jesteśmy trochę jak komputer. Więc nigdy nie udajemy, że jesteśmy Googlebotem, nigdy nie udajemy, że jesteśmy tymi wszystkimi różnymi rzeczami. Więc jeśli spojrzysz na to, jak boty Google uzyskują dostęp do określonego pliku z innego adresu IP… wiele technologii, takich jak CloudFlare, jeśli udajesz, że jesteś Googlebotem i próbujesz uzyskać do niego dostęp za pomocą Screaming Frog, wie, że jesteś nie Googlebot, tak naprawdę to ty. Dlatego traktuje cię inaczej niż Googlebota. I tak często serwery są skonfigurowane do wstępnego renderowania rzeczy, aby wykonać wszystkie bity. I po prostu upewnia się, że wszyscy otrzymają właściwy kod odpowiedzi z serwera w tym momencie.

I wydaje się to dość proste, ale kiedy zwiększasz skalę na skalę międzynarodową… Kiedy masz przekierowania geograficzne, jeśli użytkownik lub wyszukiwarka nie może uzyskać dostępu do określonej strony, ponieważ ktoś umieścił przekierowanie geograficzne, aby powiedzieć, że jeśli odwiedzisz tę strona internetowa z Hiszpanii, a następnie przejdź i załaduj ten podkatalog... Dlatego nie może przeglądać wersji głównych ani wersji alternatywnych. Dlatego poprawność kodów odpowiedzi jest absolutnie krytyczna. Zaskakujące jest, jak często przechodzisz przez te rzeczy i zakładasz, że wszystko jest poprawnie skonfigurowane. Ponieważ raz po raz wiemy, jak to powinno być ustawione. Dajemy to komuś, ktoś to interpretuje, ktoś to wdraża, a jeszcze ktoś to przechodzi. A potem ktoś inny klika przycisk w CDN, który mówi: „Och, możemy geolokalizować kogoś w tym konkretnym miejscu”. Nie chodzi o to, że jedna osoba zrobiła coś złego, ale o to, że jest coś w łańcuchu, który skutecznie go lekko złamał.

Marynata Pareto - nisko wiszący owoc

D: Zakończmy marynatą Pareto. Pareto mówi, że możesz uzyskać 80% swoich wyników z 20% swoich wysiłków. Jakie działanie SEO poleciłbyś, które zapewnia niesamowite wyniki przy niewielkim wysiłku?

G: W tej chwili moją ulubioną rzeczą jest to, że mam bardzo prosty pulpit nawigacyjny Google Data Studio, który pozwala mi przyjrzeć się temu, co nazywam nisko wiszącym owocem. Teraz wszyscy nienawidzą popularnego bingo. Ale to jest moja rzecz, w której patrzę na rzeczy, które nie są tak dobrze oceniane, jak powinny. Przyglądam się wszystkim słowom kluczowym, które plasują się w rankingu dla określonego zestawu stron, przepisów, produktów lub czegoś takiego. Dobrym przykładem jest to, że w tej chwili pracuję nad dziesiątkami tysięcy produktów, patrzę na wszystkie strony, które mają wysokie wyświetlenia, ale mogą być na pozycji szóstej i mogę je przerobić na pozycję 3. W dziewięciu przypadkach na dziesięć możesz to zrobić, upewniając się, że tagi tytułowe zostały ulepszone, a wewnętrzne linkowanie ulepszone. Bardzo prosta rzecz, aby dowiedzieć się, które słowa kluczowe o dużej liczbie wyszukiwań można nieco zwiększyć, aby zwiększyć współczynnik klikalności.

D: Byłem twoim gospodarzem, David Bain. Możesz znaleźć Gerry'ego, wyszukując Gerry'ego White'a na LinkedIn. Gerry, bardzo dziękuję za udział w podcaście In Search SEO.

G: Cała przyjemność po mojej stronie. Dziękuję za Twój czas.

D: I dziękuję za wysłuchanie. Sprawdź wszystkie poprzednie odcinki i zapisz się na bezpłatną wersję próbną platformy Rank Ranger.