Zaawansowane kluczowe wskaźniki internetowe: techniczny przewodnik po SEO

Dowiedz się, jak ulepszyć Core Web Vitals, wiedząc, jak diagnozować i dostarczać rozwiązania zapewniające lepsze, zorientowane na  środowisko użytkownika. Prawdziwi ludzie chcą dobrych doświadczeń w sieci . Jak to wygląda w praktyce? Cóż, jedno z ostatnich badań cytowanych przez Google w poście na blogu o Core Web Vitals wykazało, że użytkownicy internetu mobilnego skupiali uwagę na ekranie tylko przez 4-8 sekund na raz.

Masz mniej niż 8 sekund na dostarczenie interaktywnej zawartości i nakłonienie użytkownika do wykonania zadania. Wprowadź podstawowe wskaźniki internetowe (CWV). Te trzy wskaźniki służą do mierzenia wydajności witryny w ludzkich doświadczeniach. Projekt Chromium o otwartym kodzie źródłowym ogłosił metryki na początku maja 2020 r. i zostały szybko przyjęte w produktach Google.

Jak oceniamy wydajność w pomiarach zorientowanych na użytkownika?

-Czy się ładuje?

-Czy mogę wejść w interakcję?

-Czy jest stabilny wizualnie?

Zasadniczo, Core Web Vitals mierzy, ile czasu zajmuje ukończenie funkcji skryptu potrzebnych do namalowania treści w części strony widocznej na ekranie. Areną dla tych herkulesowych zadań jest widok 360 x 640. Zmieści się w Twojej kieszeni! Ta wojna z nierozwiązanym długiem technologicznym jest błogosławieństwem dla wielu właścicieli produktów i specjalistów SEO, którzy zalegają z nowymi funkcjami i błyszczącymi bombkami. Czy aktualizacją Page Experience będzie Mobileggedon 4.0? Prawdopodobnie nie.

Ale gdy Twoja strona przejdzie testy CWV, użytkownicy są o 24% mniej skłonni do porzucenia wczytywania strony. Wysiłki te przynoszą korzyści każdemu źródłu i medium, a co najważniejsze – prawdziwym ludziom.

 

Aktualizacja doświadczenia strony

Mimo całego szumu, CWV będzie elementem sygnału rankingowego. Oczekuje się, że będzie stopniowo wprowadzany od połowy czerwca do sierpnia 2021 r. Ranking Page Experience będzie składał się z:

1.Podstawowe wskaźniki internetowe.

-Największa zawartość farby .

-Opóźnienie pierwszego wejścia .

-Stabilność wizualna .

2.Przyjazny dla urządzeń mobilnych.

3.Bezpieczne przeglądanie.

4.HTTPS.

5.Brak natrętnych reklam pełnoekranowych.

 

Zaktualizowana dokumentacja wyjaśnia, że ​​wdrażanie będzie stopniowe i że „witryny generalnie nie powinny spodziewać się drastycznych zmian”.

Ważne rzeczy, które należy wiedzieć o aktualizacji:

-Jakość strony jest oceniana według adresu URL.

-Działanie strony opiera się na przeglądarce mobilnej.

-AMP nie jest już wymagane w przypadku karuzeli Top Stories.

-Zdanie CWV nie jest wymagane, aby pojawiać się w karuzeli Top Stories.

kluczowe wskaźniki internetowe

reklama:

specjalista SEO
Specjalista seo: szymanski.biz.pl
drzwi Warszawa
Drzwi wewnętrzne: Hermes Warszawa.

Nowy raport na temat jakości strony w Search Console

Search Console zawiera teraz raport na temat jakości strony . Nowy zasób zawiera dane z datą wsteczną z ostatnich 90 dni. Aby adres URL był „Dobry”, musi spełniać następujące kryteria:

-W raporcie Podstawowe wskaźniki internetowe adres URL ma stan Dobry .

-Zgodnie z raportem dotyczącym obsługi na urządzeniach mobilnych adres URL nie ma problemów z obsługą na urządzeniach mobilnych.

-Witryna nie ma problemów z bezpieczeństwem.

-Adres URL jest obsługiwany przez HTTPS.

-Witryna nie ma problemów z widocznością reklam lub witryna nie została oceniona pod kątem widoczności reklam.

Nowy raport oferuje widżety wysokiego poziomu łączące się z raportami dla każdego z pięciu „Dobrych” kryteriów.

 

Przepływ pracy dla diagnozowania i działania ulepszeń CWV

Po pierwsze, ważne zastrzeżenie dotyczące danych Field vs Lab. Field Data to dane dotyczące wydajności zebrane z rzeczywistych wczytań stron, których doświadczają użytkownicy na wolności. Możesz również usłyszeć dane pola zwane monitorowaniem rzeczywistego użytkownika. Podstawowe oceny Web Vitals i sygnał rankingu Page Experience będą wykorzystywać dane terenowe zebrane w raporcie Chrome User Experience Report (Crux).

Którzy użytkownicy są częścią raportu dotyczącego wrażeń użytkowników Chrome?

Dane Crux to zagregowane dane użytkowników, którzy spełniają trzy kryteria:

-Użytkownik zgodził się na synchronizację swojej historii przeglądania.

-Użytkownik nie skonfigurował hasła synchronizacji.

-Użytkownik ma włączone raportowanie statystyk użytkowania.

Crux jest Twoim źródłem prawdy dla Core Web Vitals Assessment. Dostęp do danych Crux możesz uzyskać za pomocą Google Search Console, PageSpeed ​​Insights (na poziomie strony), publicznego projektu Google BigQuery lub jako panelu źródłowego w Google Data Studio. Dlaczego miałbyś używać czegokolwiek innego? Cóż, CWV Field Data to ograniczony zestaw metryk z ograniczonymi możliwościami debugowania i wymaganiami dotyczącymi dostępności danych.

Podczas testowania swojej strony możesz zobaczyć, że „Raport dotyczący wrażeń użytkowników Chrome nie zawiera wystarczających danych dotyczących prędkości w świecie rzeczywistym dla tej strony”. Dzieje się tak, ponieważ dane Crux są anonimowe. Musi być wystarczająca liczba załadowanych stron, aby można było zgłosić raport bez uzasadnionej możliwości zidentyfikowania indywidualnego użytkownika.

Web Core Vitals najlepiej identyfikować za pomocą danych terenowych, a następnie diagnozować/poddawać kontroli jakości za pomocą danych laboratoryjnych. Lab Data umożliwia debugowanie wydajności z kompleksowym i głębokim wglądem w UX. Nazywa się to „laboratorium”, ponieważ te emulowane dane są gromadzone w kontrolowanym środowisku z predefiniowanymi ustawieniami urządzenia i sieci. Możesz uzyskać dane laboratoryjne z PageSpeed ​​Insights, web.dev/measure, panelu Lighthouse w Chrome DevTool i robotów indeksujących opartych na Chromium, takich jak lokalne NodeJS Lighthouse lub DeepCrawl.

 

1. Zidentyfikuj problemy z danymi Crux pogrupowanymi według wzorców zachowań w Search Console.

Zacznij od raportu Podstawowe wskaźniki internetowe Search Console, aby zidentyfikować grupy stron, które wymagają uwagi. Ten zestaw danych wykorzystuje dane Crux i czy uprzejmość grupuje przykładowe adresy URL na podstawie wzorców zachowań.

Jeśli rozwiążesz problem główny dla jednej strony, prawdopodobnie naprawisz go dla wszystkich stron, które dzielą to nieszczęście CWV. Zazwyczaj te problemy są wspólne dla szablonu, instancji CMS lub elementu na stronie. GSC zajmuje się grupowaniem za Ciebie.

Skoncentruj się na danych mobilnych, ponieważ Google przechodzi na indeks Mobile-First, a CWV ma wpływać na mobilne SERP. Ustal priorytety swoich działań na podstawie liczby adresów URL, których dotyczy problem. Kliknij problem, aby zobaczyć przykładowe adresy URL, które wykazują te same wzorce zachowań. Zapisz te przykładowe adresy URL do testowania w trakcie procesu doskonalenia.

2. Użyj PageSpeed ​​Insights, aby połączyć dane z pola z diagnostyką laboratoryjną.

Po zidentyfikowaniu stron, które wymagają pracy, użyj PageSpeed ​​Insights (opartego na Lighthouse i Chrome UX Report), aby zdiagnozować problemy laboratoryjne i terenowe na stronie. Pamiętaj, że testy laboratoryjne to jednorazowe testy emulowane. Jeden test nie jest źródłem prawdy ani ostateczną odpowiedzią. Przetestuj wiele przykładowych adresów URL.

PageSpeed ​​Insights można używać tylko do testowania publicznie dostępnych i indeksowanych adresów URL. Jeśli pracujesz na stronach noindex lub uwierzytelnionych, dane Crux są dostępne za pośrednictwem interfejsu API lub BigQuery . Testy laboratoryjne powinny używać Lighthouse .

 

3. Utwórz bilet. Wykonaj prace programistyczne.

Zachęcam Cię jako specjalistów SEO do udziału w procesach udoskonalania zgłoszeń i kontroli jakości. Zespoły programistyczne zazwyczaj pracują w sprintach. Każdy sprint zawiera ustawione bilety. Posiadanie dobrze napisanych biletów pozwala Twojemu zespołowi programistycznemu lepiej ocenić wysiłek i wprowadzić bilet do sprintu.

W swoich biletach dołącz:

Historia użytkownika

Postępuj zgodnie z prostym formatem:

Jako < typ użytkownika/witryny/itp. > chcę, aby <działanie> było <celem>.

Np.: Jako wydajna witryna chcę dołączyć wbudowany CSS dla węzła X w szablonie strony Y, aby uzyskać największą zawartość treści dla tego szablonu strony w mniej niż 2,5 sekundy.

Kryteria akceptacji

Zdefiniuj, kiedy cel został osiągnięty. Co oznacza „zrobione”? Np.:

  • Wstaw dowolny kod CSS ścieżki krytycznej używany do zawartości strony widocznej na ekranie, umieszczając go bezpośrednio w <head>.
  • Krytyczny CSS (czytaj: ten związany z węzłem X) pojawia się nad linkami zasobów JS i CSS w <head>.

Testowanie adresów URL/strategia

Uwzględnij zgrupowane przykładowe adresy URL skopiowane z Search Console. Podaj zestaw kroków, które powinni wykonać inżynierowie ds. kontroli jakości.

Zastanów się, jakie narzędzie jest używane, jakich metryk/markerów szukać i jakie zachowanie wskazuje na zaliczenie lub niepowodzenie.

Łącza do dokumentu dewelopera

Użyj dokumentacji własnej, jeśli jest dostępna. Proszę nie puszyste blogi. Proszę? Np.:

  • Wbudowany krytyczny CSS, Web.dev
  • Wyodrębnij krytyczny CSS, Web.dev

 

4. Zmiany kontroli jakości w środowiskach scenicznych wykorzystujących latarnię morską.

Zanim kod zostanie wypchnięty do produkcji, często jest umieszczany w środowisku przejściowym do testowania. Użyj Lighthouse (poprzez Chrome DevTools lub lokalną instancję węzła), aby zmierzyć podstawowe wskaźniki internetowe. Jeśli dopiero zaczynasz testować za pomocą Lighthouse, możesz dowiedzieć się o sposobach testowania i metodologii testowania w Przewodniku technicznego SEO po wskaźnikach wydajności Lighthouse .

Należy pamiętać, że niższe środowiska zazwyczaj mają mniej zasobów i będą mniej wydajne niż produkcyjne. Polegaj na kryteriach akceptacji, aby sprawdzić, czy ukończone prace rozwojowe spełniły postawione zadanie.

 

Największa zawartość farby

Reprezentuje : Postrzegane doświadczenie wczytywania.

Pomiar : punkt na osi czasu wczytywania strony, w którym największy obraz lub blok tekstu na stronie jest widoczny w widocznym obszarze.

Kluczowe zachowania : strony korzystające z tych samych szablonów stron zazwyczaj korzystają z tego samego węzła LCP.

Cel : 75% wczytanych stron osiąga LCP w < 2,5 sekundy.

Dostępne jako : dane laboratoryjne i terenowe.

 

Co może być LCP?

Metryka LCP mierzy, kiedy widoczny jest największy element tekstu lub obrazu w widocznym obszarze.

Możliwe elementy, które mogą być węzłem LCP strony, obejmują:

  1. <img> elementy.

2, <image>elementy wewnątrz <svg>znacznika.

  1. plakatowe obrazy <video>elementów.
  2. obrazy tła ładowane za pomocą url() funkcji CSS.

5, Węzły tekstowe wewnątrz elementów blokowych.

Spodziewaj się dodatkowych elementów, takich jak <svg>i <video>dodanych w przyszłych iteracjach.

 

Jak zidentyfikować LCP za pomocą Chrome DevTools

  1. Otwórz stronę w Chrome emulując Moto 4G.
  2. Przejdź do panelu Wydajność narzędzi programistycznych ( Command + Option + Ina komputerach Mac lub Control + Shift + Iw systemach Windows i Linux).
  3. Najedź kursorem na LCPznacznik w sekcji Czasy.
  4. Element(y) odpowiadające LCP są wyszczególnione w polu Węzeł powiązany.

Co powoduje słaby LCP?

Istnieją cztery typowe problemy powodujące słaby LCP:

  1. Długie czasy odpowiedzi serwera.
  2. Blokujący renderowanie JavaScript i CSS.
  3. Długie czasy ładowania zasobów.
  4. Renderowanie po stronie klienta.

Problemy źródłowe dla LCP są namalowane w najlepszym razie szerokimi pociągnięciami. Niestety, żadne z powyższych fraz prawdopodobnie nie wystarczy, aby przekazać Twojemu zespołowi programistów znaczące wyniki.

 

Możesz jednak nadać sprawie impetu, kierując się na to, które z czterech źródeł jest w grze. Ulepszanie LCP będzie oparte na współpracy. Naprawienie tego oznacza uczestniczenie w aktualizacjach deweloperów i śledzenie jako interesariusz.

Diagnozowanie słabego LCP z powodu wolnego czasu odpowiedzi serwera

JEŚLI widzisz stale słabą wartość TTFB w danych terenowych, oznacza to, że jest to długi czas odpowiedzi serwera, który przeciąga LCP.

 

Jak naprawić długi czas odpowiedzi serwera?

Na czas odpowiedzi serwera składa się wiele czynników dostosowanych do stosu technologicznego witryny. Nie ma tu srebrnych kul. Najlepszym sposobem działania jest otwarcie zgłoszenia ze swoim zespołem programistów.

Niektóre możliwe sposoby ulepszenia TTFB to:

  1. Zoptymalizuj serwer.
  2. Kieruj użytkowników do pobliskiej sieci CDN.
  3. Zasoby pamięci podręcznej.
  4. Wyświetlaj strony HTML jako pierwsze w pamięci podręcznej.
  5. Wcześnie nawiązuj połączenia z innymi firmami.

 

Diagnozowanie słabego LCP z powodu blokowania renderowania JavaScript i CSS

Gdzie szukać : Lighthouse (za pośrednictwem web.dev/measure , Chrome DevTools, Pagespeed Insights lub instancji nodeJS). Każde z poniższych rozwiązań zawiera odpowiednią flagę audytu.

 

Jak naprawić CSS blokujący renderowanie

CSS z natury blokuje renderowanie i wpływa na wydajność krytycznej ścieżki renderowania. Domyślnie CSS jest traktowany jako zasób blokujący renderowanie.

Przeglądarka pobiera wszystkie zasoby CSS, niezależnie od zachowania blokującego lub nieblokującego.

 

Zminimalizuj CSS.

Jeśli Twoja witryna korzysta z narzędzia do pakowania modułów lub narzędzia do budowania, znajdź wtyczkę, która będzie systematycznie minimalizować skrypty.

 

Odłóż CSS niekrytyczny.

Raport Pokrycie kodu w DevTools pomoże Ci określić, które style są używane na stronie. Jeśli nie jest używany na żadnej stronie, usuń go całkowicie. (Bez osądu, pliki CSS mogą szybko wpakować się do przysłowiowej szuflady śmieci.)

Jeśli style są używane na innej stronie, stwórz osobny arkusz stylów dla tych stron, które używają go do wywoływania.

 

Wbudowany krytyczny CSS.

Uwzględnij kod CSS ścieżki krytycznej używany do treści w części strony widocznej na ekranie (zgodnie z raportem Pokrycie kodu) bezpośrednio w <head>.

 

Użyj dynamicznych zapytań o media.

Zapytania o media to proste filtry, które po zastosowaniu do stylów CSS rozdzielają style na podstawie typów urządzeń renderujących zawartość.

Korzystanie z dynamicznych zapytań o media oznacza, że ​​zamiast obliczania stylów dla wszystkich widocznych okien, wywołujesz i obliczasz te wartości w żądanym obszarze roboczym.

 

Jak naprawić JavaScript blokujący renderowanie

Zminimalizuj i skompresuj pliki JavaScript.

Będziesz musiał współpracować z programistami, aby zminimalizować i skompresować ładunki sieciowe.

Minifikacja polega na usunięciu niepotrzebnych białych znaków i kodu. Najlepiej robić to systematycznie za pomocą narzędzia do kompresji JavaScript.

Kompresja obejmuje algorytmiczną modyfikację formatu danych pod kątem wydajnych interakcji serwera i klienta.

Odłóż nieużywany JavaScript.

Dzielenie kodu rozdrabnia duże fragmenty JS, aby dostarczać mniejsze pakiety. Następnie możesz najpierw załadować te, które mają znaczenie, do zawartości strony widocznej na ekranie.

 

Zminimalizuj nieużywane wypełnienia.

Pamiętasz, jak Googlebot utknął w Chrome 44 przez całe stulecia? Wypełnienia to fragment kodu służący do zapewnienia nowoczesnych funkcji w starszych przeglądarkach, które nie obsługują go natywnie. Teraz, gdy Googlebot jest wiecznie zielony, nosi również nazwę długu technologicznego. Niektóre kompilatory mają wbudowane funkcje do usuwania starszych wypełnień.

 

Jak naprawić blokujące renderowanie skrypty innych firm?

Opóźnij to.

Jeśli skrypt nie wpływa na zawartość strony widocznej na ekranie, użyj asynclub deferatrybutów.

 

Usunąć to.

Jeśli skrypt używa <iframe>w głowie, usuń go. Skontaktuj się z dostawcą, aby uzyskać zaktualizowaną metodę implementacji.

 

Skonsoliduj to.

Kontroluj użycie skryptów innych firm. Kto zarządza narzędziem? Narzędzie innej firmy bez osoby zarządzającej jest również znane jako zobowiązanie.

Jaką to zapewnia? Czy ta wartość jest większa niż wpływ na wydajność? Czy wynik można osiągnąć poprzez konsolidację narzędzi?

 

Zaktualizuj to.

Inną opcją może być skontaktowanie się z dostawcą, aby sprawdzić, czy ma zaktualizowaną wersję odchudzoną lub asynchroniczną. Czasami robią i nie mówią ludziom, że mają swoją starą implementację.

 

Diagnozowanie słabego LCP z powodu długich czasów ładowania zasobów

Gdzie szukać : Lighthouse (za pośrednictwem web.dev/measure , Chrome DevTools, Pagespeed Insights lub instancji nodeJS). Każde z poniższych rozwiązań zawiera odpowiednią flagę audytu.

Przeglądarki pobierają i wykonują zasoby, gdy je odkryją. Czasami nasze drogi do odkrycia nie są idealne. Innym razem zasoby nie są zoptymalizowane pod kątem obsługi na stronie.

Oto sposoby zwalczania najczęstszych przyczyn powolnego ładowania zasobów:

  1. Optymalizuj i kompresuj obrazy.

Nikt nie potrzebuje pliku png o wielkości 10 MB. Rzadko zdarza się, aby wysłać duży plik obrazu. Albo png.

  1. Wstępnie ładuj ważne zasoby.

Jeśli zasób jest częścią ścieżki krytycznej, prosty rel=”preload”atrybut informuje przeglądarkę, aby pobrała go tak szybko, jak to możliwe.

  1. Kompresuj pliki tekstowe.

Koduj, kompresuj, powtarzaj.

  1. Dostarczaj różne zasoby w oparciu o połączenie sieciowe ( serwowanie adaptacyjne ).

Urządzenie mobilne w sieci 4G prawdopodobnie nie będzie potrzebować/chcieć/tolerować czasu ładowania zasobów gotowych na monitor ultra 4K. Użyj interfejsu Network Information API, który umożliwia aplikacjom internetowym dostęp do informacji o sieci użytkownika.

  1. Zasoby w pamięci podręcznej za pomocą Service Workera.

Chociaż Googlebot nie wykonuje usług pracowników usług, urządzenie użytkownika podłączone do połączenia sieciowego z pewnością to zrobi. Współpracuj z zespołem programistów, aby wykorzystać interfejs Cache Storage API .

 

Diagnozowanie słabego LCP z powodu renderowania po stronie klienta

Gdzie szukać : aby rzucić okiem, zobacz źródło strony. Jeśli jest to kilka linijek bełkotu, strona jest renderowana po stronie klienta.

Elementy na stronie mogą być renderowane po stronie klienta. Aby znaleźć elementy, porównaj początkowe źródło strony z wyrenderowanym kodem HTML. Jeśli używasz robota, porównaj różnicę w liczbie wyrenderowanych słów.

Podstawowe wskaźniki internetowe to sposób na zmierzenie skuteczności naszych strategii renderowania.

Wszystkie opcje renderowania mają ten sam wynik (wszystkie tworzą strony internetowe), ale metryki CWV mierzą, jak szybko dostarczamy to, co ważne, gdy ma to znaczenie.

Renderowanie po stronie klienta rzadko jest odpowiedzią, chyba że pytanie brzmi: „Jakie zmiany weszły do ​​produkcji w tym samym czasie, gdy ruch organiczny zaczął spadać?”

 

Jak naprawić renderowanie po stronie klienta

„Stop” naprawdę nie jest użyteczną odpowiedzią. Dokładne, ale nieprzydatne. Więc zamiast:

  1. Zminimalizuj krytyczny JavaScript.

Używaj dzielenia kodu, potrząsania drzewami i funkcji wbudowanych w głowie, aby uzyskać funkcje powyżej części ekranu. Zachowaj te wbudowane skrypty <1kb.

  1. Użyj renderowania po stronie serwera.

Dzięki temu, że serwery wykonują elementy JS, możesz zwrócić w pełni wyrenderowany kod HTML. Zauważ, że zwiększy to TTFB, ponieważ skrypty są wykonywane przed odpowiedzią serwera.

  1. Użyj renderowania wstępnego.

W czasie kompilacji wykonaj skrypty i wyrenderuj kod HTML na potrzeby przychodzących żądań. Ta opcja zapewnia lepszy czas odpowiedzi serwera, ale nie będzie działać w przypadku witryn z często zmieniającymi się zasobami lub cenami.

 

Żeby było jasne: renderowanie dynamiczne nie jest rozwiązaniem dla renderowania po stronie klienta. To sprawia kłopoty z renderowaniem przyjaciela po stronie klienta.

 

Opóźnienie pierwszego wejścia (FID)

Reprezentuje : Reakcja na dane wejściowe użytkownika.

Pomiar : czas od pierwszej interakcji użytkownika ze stroną do momentu, w którym przeglądarka może faktycznie rozpocząć przetwarzanie modułów obsługi zdarzeń w odpowiedzi na tę interakcję.

Kluczowe zachowania : FID jest dostępny tylko jako dane pola.

Cel : 75% wczytanych stron osiąga FID w <= 100 milisekund.

Dostępne jako : Dane pola.

 

Użyj całkowitego czasu blokowania (TBT) do testów laboratoryjnych

Ponieważ FID jest dostępny tylko jako dane laboratoryjne, musisz użyć Całkowitego czasu blokowania do testów laboratoryjnych. Obaj osiągają ten sam wynik końcowy z różnymi progami.

TBT oznacza : Reakcja na dane wejściowe użytkownika.

Pomiar TBT : Całkowity czas, w którym główny wątek jest zajęty przez zadania trwające ponad 50 ms.

Cel : <= 300 milisekund.

Dostępne jako : Dane laboratoryjne.

 

 

Google zamierza corocznie aktualizować składniki Page Experience. Przyszłe metryki CWV zostaną udokumentowane podobnie do początkowego wprowadzenia sygnału. Wyobraź sobie świat, w którym specjaliści SEO z rocznym wyprzedzeniem dowiedzieli się, że nadchodzi Panda! Podstawowe wskaźniki internetowe stanowią już 55% twojego wyniku w Lighthouse v7.

Obecnie największe malowanie treści (LCP) i opóźnienie pierwszego wejścia (FID) są ważone po 25%. Łączne przesunięcie układu to zaledwie 5%, ale możemy się spodziewać, że te wyrównania się wyrównują. Inteligentne pieniądze pojawią się w czwartym kwartale 2021 r., gdy zespół Chromium dopracuje obliczenia. Jako profesjonaliści techniczni SEO jesteśmy w stanie diagnozować i dostarczać rozwiązania, które zapewniają lepsze wrażenia zorientowane na użytkownika. Tutaj rzecz – te inwestycje i ulepszenia mają wpływ na wszystkich użytkowników.

ROI można znaleźć w każdym medium. Każdy kanał. Wydajność organiczna jest ogólnym odzwierciedleniem stanu witryny. Wykorzystaj to stanowisko, kontynuując opowiadanie i powtarzanie. Podziel się tym, czego się nauczyłeś.