Обзор на Google – Юли 2018

mobile first indexingПо думи на Гугъл: Все още доста предстои да се случи, докато преминем изцяло на mobile-first индексиране
google recap jul 18

Иии отново идва времето за следващия обзор на ъпдейтите и промените на Гугъл. Макар да ви е отпускарско сега, да мислите за студена бира, морски деликатеси и красиви жени, знайте, че Гугъл не спи, развитието му също! Почти убедени сме и, че ще го запазите за четене след това тази публикация или директно ще се изкушите да ни зададете въпрос. В която и ситуация да се намирате, ще се радваме да постигнем крайната си цел, а именно да ви информираме. А ето и последното случващо се в компанията гигант с най-голям дял в търсенето в уеб.

mobile first indexingПо думи на Гугъл: Все още доста предстои да се случи, докато преминем изцяло на mobile-first индексиране

Както може би вече знаете, преминването към мобилен индекс на Гугъл като процес продължава и е съвсем нормално да отнеме много време, предвид големината на уеб към момента.

Гугъл, съвсем логично отказват да обявят времето, необходимо за приключване на този процес, но споделиха, че имат доста планирани неща, които трябва да бъдат извършени, преди този процес да се отчете като официално завършен. Така остава спорен въпросът кога и как ще бъде завършено преминаването към мобилен индекс.

Не използвайте Noindex & Rel=Canonical едновременно

По думи на Джон Мюлер от Гугъл, търсачката изисква ясни и праволинейни сигнали. Има разлика между rel=“canonical“ и Noindex. В случай, че решите да подадете сигнал на Гугъл, че един URL е по-важен от друг, но друг сигнал го известява за точно обратната информация или просто използвате noindex, за да спрете индексирането, но да използвате тежината на тези страници към други, то очаквайте да бъде в една или друга степен наказани от Гугъл.

Като основно правило – сигналите се комбинират и пренасят чрез каноникализация. Когато Гугъл вижда 2 URLs от сайта Ви, ако те изглеждат еднакви и Вие подавате ясни сигнали за предпочитанията си, Гугъл ще ги комбинира и ще ги третира като един по-силен URL, вместо поотделно.

Пренасочвания, каноникализация, вътрешни линкове и външни такива, сайтмапове, hreflang и други са сигнали, които показват на Гугъл Вашите предпочитания. Тяхната консистентност или с други правилно настройване към правилната страница или страници са от важно значение за сайта Ви, защото именно така Гугъл се ориентира в каноникализацията на страниците Ви и съответното прехвърляне на сигналите към каноникализираната страница.

Използването на noindex, както и disallow в robots.txt не са и не могат да бъдат ясни сигнали за каноникализация. Сами по себе си те не помагат на търсачката да „комбинира“ и да прехвърля сигнали.

При robots.txt disallow е дори още по-трудно, защото практически няма как да се разбере дали дадена страница е подобна или същата като друга на Вашия сайт.

Гугъл: Не използваме сентимента в органичните резултати

По думи на известния Дани Съливан, вече част от екипа на Гугъл, търсачката не разпознава сентимента при класиране на органичните си резултати, поради което няма и оператор за това.

Google може да комбинира URLs преди обхождане

Гугъл се старае да не показва едно и също съдържание в органините си резултати по определена заявка, поради това търсачката извършва много проверки за дублирано съдържание на ниво URL и съдържание.

Ако разсъждаваме логично, то първата мисъл, която ни идва на ум е тази, че съдържанието трябва първо да бъде обходено, за да се прецени дублирано ли е или не, да се обърне внимание и на мета информацията, преди всички сигнали да се пренесат към определена страница или страници. По думи, обаче на Джон Мюлер, Гугъл извършва това още преди да е обходен сайта.

По думи на Мюлер: „Where we look at the URLs that we see and based on the information that we have from the past we think well probably these URLs could end up being the same and then we’ll fold them together„.

Мюлер допълни още, че търсачката използва също и така нар. URL pattern като ясен сигнал за дублирано съдържание. Той даде пример с уебсайт, където например съдържанието е същото или много подобно на поддомейна на този сайт и даден поддиректория и фактът, че търсачката може на „сляпо“ да прецени, че те са близки или дори еднакви без да им „обръща“ особено внимание.

Разбира се, Гугъл използва и сигнали като каноникали, пренасочвания, структури създадени от системите за управление на съдържание като WordPress, които показват ясни шаблони.

Google: Ясната структура на съдържанието ще ви помогне, но и грешно направена, няма да навреди

На Джон Мюлер беше зададен въпросът дали строго спазване на реда на header tags в html кода на сайта Ви би спомогнало, но неговият отговор тук беше, че ясната структура със сигурност ще спомогне, но направена грешно, то тя няма да навреди на сайта Ви като цяло.

Това, разбира се, има двуяко значение. От една страна, ако структурирането не е правилно това би довело до негативни последици за съответната страница, но не и за целия сайт, от друга структурирането следва да няма никакво значение.

Какво мислим ние от Серпакт? Определено има значение и то за всяка страница, както и за целия сайт. Няма как обаче да се даде ясен и точен отговор, защото, както вече сме споменавали, няма такова понятие като универсални ранкинг сигнали!

Google: „Не разбираме региони! Разбираме само държави и столици“

Гари Айлис от Гугъл спомена, че след проведен тест и преглед на hreflang тагове с кодове MENA, EU, ASIA, експертът от Гугъл е установил, че търсачката не „разбира“ региони, а само държави и столици. Те дори не използват и езиците от тези тагове, а оставят ранкинг системите да преценят това и да класират сайтовете.

Каква е основната причина? Тя, всъщност, е доста проста! Както всички знаем, има региони, където се говорят много повече от 1-2 езика. Няма как да бъдат обхванати всички, съответно няма и как да бъдат ограничени до определени езици, защото може да се окаже, че хора, не разбиращи даден език, ще получат резултати класирани точно на този език.

държави

Добавянето на продуктите на Вашия онлайн магазин в Амазон може да навреди на класирането ви в Гугъл

Представете си, че имате онлайн магазин с продукти, както и че решавате да качите тези продукти в онлайн платформата на Амазон, за да се продават и там. След известно време ще видите как Амазон ще бъде много по-добре класиран от Вашия уебсайт по всички важни за Вашия бизнес и продукти, фрази за търсене.

Същият въпрос е бил зададен и на Джон Мюлер от Гугъл, който отговаря с доста забавен подход, като създава анкета в Туитър и задава въпрос към всички: Ако добавите същия продуктов каталог на Вашия сайт и в платформата на Амазон, това ще повлияе ли на класирането Ви? Отговорите са 3 възможни – Бих искал да виждам и двата резултата / от онлайн магазина и Амазон/, предпочитам разнообразни отговори /резултати/, бих искал студена бира. 

Google официално премахват инструмента Submit To Index Tool

Google обяви в Twitter, че официално премахват инструмента за изпращане на адреси на страници от сайтове към индекса на търсачката. Потребителят, вместо това, може да продължи да използва „Извличане и изпращане“ в Google Search Console за отделни страници или да използва XML Sitemaps, за да подаде страници към Google по този начин.

submit to index tool

Google: Броят думи не е индикатор за качество на съдържанието

Едно от нещата, които виждаме толкова често да се дискутира в SEO средите е, че се нуждаете от дълго или определено на брой думи съдържание, за да иска Google да го индексира и да го класира добре. Истината е, че това не е вярно – ако е така, Google няма да класира Twitter URL адресите например.

Джон Мюлер от Гугъл каза: „броят думи не е показателен за качеството“. „Някои страници имат много думи, които не казват нищо. Някои страници имат много малко думи, които са много важни и подходящи за конверсии“.

Ние от Серпакт също сме забелязали, че за Гугъл това не е от особено значение. Причината дадени текстове да са по-дълги е фактологията, която изисква съответната тематика, а не защото Гугъл изисква определена дължина. Дължината на съдържанието до голяма степен зависи от това какво точно се казва в него, както и от нишата.

Google „People Also Ask“ Функция се появява с 35% повече пъти от преди

People Also Ask функцията в Google, която започна да се показва през 2015 г., е видяла огромно увеличение във времето, което се показва в резултатите от търсенето. Увеличението се отчита на около 35%, което показва почти половината от всички заявки.

people also ask

Google My Business показва конкурентите на Google Posts

Като начин за насърчаване на бизнеса да използва Google Posts още, Google вече показва на някои фирми Google Posts от техните конкуренти в таблото за управление на Google My Business.

Google: Използването на Rel=“canonical“ не гарантира, че Google ще извежда тази страница като каноникализирана

Джон Мюлер сподели, че Google не използва винаги rel=“canonical“ като единствен сигнал кои страници трябва да бъдат каноничната страница. Може да има и други сигнали, които объркват Google и водят до различно решение на Google.

По негови думи: „Ние използваме множество фактори при определянето на каноничната за страница, rel = canonical не е гаранция.“ После той посочи объркващ сигнал като пример: „rel =“canonical“ на първата страница + rel next / prev са малко противоречащи, или това е същото като първата страница, или те са страницирани серии.“

Google: Crawling SPA (single page application) не е лесно, но може да работи

Google Джон Мюлер бе попитан за това как GoogleBot се справя с обхождането, индексирането и класирането на SPA приложения в мрежата. Той отговори, че това не винаги работи перфектно и със сигурност не е лесно, но за някои сайтове това може да работи добре, дори ако разчитаме на рендиране от страна на клиента.

Всичко това е възможно, но очевидно има много препятствия, за които трябва да сте наясно, когато гарантирате, че Google може да обходи и индексира съдържанието на SPA. Използването на „Извличане“ като Google може да ви помогне да определите какво може да види Google. Но може да се наложи да направите някои по-задълбочени анализи на кода, за да направите client side rendering.

Джон Мюлер добави, дори ако разчитате само на JavaScript и никакво рендиране на сървъра, това може да доведе до още повече проблеми. Така че, ако имате SPA, трябва да тествате и тествате и да видите какво може да „види“ Google.

Търсене на изображения от Google за промяна на URL адреса на референта за проследяване

Google ще актуализира URL адреса за препращане от Google Търсене на изображения през следващите месеци. Това е супер важна новина за всеки, който има уебсайт, който използва всякаква форма на анализ, за ​​да проследява входящия си трафик. Тези, които използват Google Анализ, няма нужда да се притесняват за това. Но за други, тази промяна е много важна, особено за тези, които са изградили свои собствени аналитични инструменти.

Новият referral URL адрес ще бъде: https://images.google.com, така че когато получите трафик от https://images.google.com, ясно ще знаете, че идва от Google Търсене на изображения.

Google определено каза, че настоящият и старият препращач е направил супер трудно човек да знае откъде идва техният трафик – това, което е основно търсене в мрежата или търсене на изображения. По думи на Гугъл:

За уеб администраторите не винаги е било лесно да се разбере ролята на Google Изображения в трафика на сайта. За да отговорим на това, през следващите няколко месеца ще пуснем нов URL адрес за препращане, конкретно за Google Изображения. Referral URL адресът ще е част от HTTP заглавката и ще показва последната страница, на която е ползвал потребителя, и кликнал, за да посети целевата уеб страница.

Google автоматично разпознава по-генералните промени в даден сайт

Джон Мюлер от Google заяви, че Google вече може и разпознава широки промени в сайта и по този начин няма нужда от бутон в Google Search Console, за да се съобщават тези промени.

Това е в отговор на уеб администратор, който иска начин да направи прехода на URL адресите по-бързо – например от http kъм https.
Google има инструмент за смяна на адрес, но това обхваща само конкретни случаи. Простите промени в URL адресите не са обхванати тук, като се използва 301 пренасочвания е начина, което Google обикновено препоръчва да бъде направено.

Когато Google вижда огромни промени в URL адресите на даден сайт, не е необичайно да виждате Google да увеличава честотата на обхождането на сайта, за да ускори тези промени по-бързо и да индексира тези нови адреси по-рано.

Има вероятност Гугъл да добави филтър за гласови заявки в Google Search Console

Отново по думи на Мюлер – това е нещо, което е поставено под въпрос. От доста време в SEO общността този въпрос за предоставянето на информация, относно гласовите заявки за търсене и филтриране по тях, се дискутира. За момента, обаче става ясно, че това не е приоритет на Гугъл, а и самите те също споменаха, че предстои и допитване до webmasters за тяхното мнение и позиция по този въпрос.

За нас от Серпакт обаче това означава само едно! Гугъл определено развиват доста сериозно търсенето по гласови заявки и е повече от ясно, че включването в конзолата за търсене означава, че и оптимизацията за тези заявки ще бъде от изключително важно значение.

Google: Трябва да пренасочите HTTP дори с конфигуриран HSTS

Отново по думи на Джон Мюлер – дори ако имате HSTS (HTTP Strict Transport Security), който по подразбиране пренасочва адресите на даден домейн да преминат от HTTP към HTTPS, все пак трябва да настроите 301 пренасочвания от HTTP към HTTPS.

Още един съвет от него: когато мигрирате към HTTPS, първо пренасочвайте и след няколко месеца, когато всичко е настроено, можете да настроите HSTS, но не е необходимо да премахвате вече създадените пренасочвания.

Поддръжка на структурирани данни на Google за табличен набор от данни

Табличният набор от данни е организиран основно по отношение на решетка от редове и колони. За страници, които вграждат таблични набори от данни, можете също така да създадете по-ясна Schema.org маркировка, основана на новия CSVW JSON-LD формат. Този вид CSVW, абревиатура от „CSV в мрежата“, предоставя таблично съдържание, ориентирано към потребителите на HTML страницата.

Отчет за заявките за търсене в Google My Business

Алисън Райт, мениджър на общността, Google My Business написа:

Радваме се да обявим, че пускаме нова функция Insights в резултат на популярното търсене! Заявките за търсене показват и класифицират термините, използвани от клиентите Ви, за да намерят бизнеса ви в Local Search и Maps.
В тази карта ще видите запитванията, използвани през последните 7 и 28 дни. За да защитим поверителността на потребителите, ще видите само заявки, които отговарят на нашия праг за поверителност.

Google Posts добавя бутон Call Now

Google Публикации стартира бутон за обаждане в Google Публикации. По същество: той ви позволява да добавите телефонния си номер като призив за действие в Google Posts, когато се покаже панел Ви с информация в Гугъл търсене, така че в карусела на публикациите бутонът за повикване може да набира вашия телефонен номер.

След това, когато се появи в резултатите от търсенето с Google, ако кликнете върху него, той ще набере номера на мобилния телефон. Когато се извърши обаждането, Google ще подаде обратна информация за начина, по който това се е случило.

Може да отнеме по-дълго време на Гугъл да обработи пренасочвания за неиндексирани страници

Гугъл обхожда страниците за неиндексиране доста по-рядко. Поради тази причина, ако дадена страница е настроена да не бъде индексирана и има и пренасочване, това може да отнеме доста по-дълго време от индексираните страници за Гугъл.

ccTLD домейните могат да се използват за таргетиране на други държави, но не и за пълно геотаргетиране

Може да използвате домейни с разширение, според държавата, която искате да таргетирате, както и да настройте hreflang, но не можете да използвате същите тези домейни за конкретна държава за цялостно таргетиране на други държави.

Внимавайте с вътрешните линкове на мобилната версия на Вашия сайт

Направена неправилно, тя би могла да се отрази сериозно на това как Гугъл индексира и класира Вашия сайт. Това важи с особена сила след преминаване на индексиране в мобилна среда с приоритет.

structured dataGOOGLE ще използва структурирани данни само за доверени и висококачествени сайтове

Структурираните данни трябва да бъдат правилно внедрени от техническа гледна точка и трябва да бъдат приложени към съответното съдържание, за да се показват в търсенето. Google също трябва да прецени, че сайтът е висококачествен и надежден.

HSTS технологията НЕ Е сигнал за класиране в Гугъл

HSTS не играе никаква роля в класирането. Основното съображение от гледна точка на Google е, че тя не трябва да се добавя към сайт по време на колебание, като миграция. Уверете се, че сте го добавили едва след приключване на класирането и успешното завършване на мигрирането.

GOOGLE ще игнорира входящи връзки, които изпращате към сайта си от директории

Google иска връзките да бъдат естествени препоръки от хора към други сайтове, така че връзките към сайта Ви, които създавате от директории, ще бъдат игнорирани.

Подобни имена на домейни не вредят на класирането им Google Търсене

Google третира всяко име на домейн като уникално, дори ако има само една буква разлика. Джон Мюлер каза: „Ако те просто изглеждат подобни, ние все още ги виждаме като отделни URL адреси, така че няма да има алгоритмично припокриване. С други думи нашите алгоритми няма да определят даден сайт като същия с друг с подобно найменоване на домейна. Или това е правилното име на домейн, или не е правилното име на домейн“.

Сега, ако хората създават повече връзки към близкото име (до Вашети) на домейна на вашите конкуренти, дори и да не е объркано, това играе важна роля. Но няма алгоритми, които да объркват имена на домейни, освен ако не използвате каноникализирани адреси или пренасочвания. Така или иначе, използването на имена на домейни или търговски марки, които са подобни на други, не винаги е най-добрата маркетингова стратегия.

Google подразбира формати на телефонни номера и тяхното форматиране НЯМА значение

Вие всички сте го виждали, как различни уеб сайтове форматират своите телефонни номера различно. Някои ги изпизват като 212-555-5555, някои като (212) 555-5555, други 212.555.5555, други 212 555 5555, някои 212_555_5555 и най-досадните 2125555555, както и в много други вариации. От Гугъл споделиха, че търсачката разбира телефоните във всеки формат. Според тях, изискването сайтовете да използват един унифициран формат за телефонни номре е безполезно и по този начин няма смисъл.

Google: Много грешки от типа 5xx могат да забавят обхождането

Джон Мюлер от Google, че обслужването на твърде много грешки 5хх, вътрешните типове грешки в сървъра, може да накара Google да забави обхождането на вашия уебсайт. Ако виждате увеличение на грешките при обхождане, това не е от голямо значение, но ако се случва при тонове грешки от типа 5хх, това означава, че нещо не е наред с вашия уебсайт и Google не иска да го използва за обхождане.

Google напомня за пореден път – няма знаение дали използвате абсолютни или относителни адреси – важното е да има консистентност сред тях.

Джон Мюлер от Google заяви, че няма проблем дали използвате абсолютни или относителни връзки в адресите си, стига изпизсването им да е едно и също, за да може Гугъл да го разбере. Проблеми могат да възникнат, когато подадете смесени сигнали на Google. Тогава търсачката Google се обърква за посоката, в която искате да вървят адресите Ви. Обикновено проблемите идват от сайтове, които правят несъответстващи пренаписвания на URL адреси (напр. Създаване на поддиректории). Ако адресите на сайта имат консистентна, постоянна настройка, относителните връзки са напълно нормални да бъдат използвани.

Налично за всички: Инструмент за проверка на URL адресите на Search Console на Google – Inspection tool.

Преди няколко седмици Google пусна инструмента за инспекция на URL адресите в новата конзола за търсене на Google. Не всички го виждаха, активирането му беше бавно, но сега според Google, той напълно видим. Инструментът подава важна информация за това какво се случва в индекса на Гугъл с дадена страница от Вашия сайт. Можете да започнете да проверявате URL адресите си, като посетите новата конзола за търсене.

google index coverage

Новият Google Индекс Report не показва блокирани URL адреси от Sitemap

Алън Блейауес сподели сцена на това, как в Google Search Console отчетът за Sitemap в Google показва над 11 000 URL адреса, блокирани от robots.txt, като проблем и предупреждение. Алън попита защо новият отчет на Google Индекс в новата конзола за търсене на Google не отчита тези грешки?

Джон Мюлер заяви в Twitter, че новият отчет няма да подаде сигнал за грешка върху примерни URL адреси на нивото на подаване на Sitemap. Той каза, че „тези са примерни URL адреси, тествани преди да бъдат подадени в индексиране – това се прави при подаването на Sitemap, така че няма да бъде в индекса за индексиране в новия НК“.

Google: Самореферентен hreflang е добра практика

Джон Мюлер от Google заяви на Twitter, че макар самореференциалният hreflang да е незадължителен, е добра практика да го приложим.
Ако имате няколко езикови версии на URL адрес, всяка езикова страница трябва да идентифицира различните езикови версии, включително самата нея.

Ако например сайтът Ви предоставя съдържание на френски, английски и испански език, испанската версия трябва да включва самата връзка rel = „alternate“ hreflang = „x“, в допълнение към връзките към френската и английската версия. По аналогичен начин, английската и френската версия трябва да включват същите препратки към френската, английската и испанската версия.

Изясняване на актуализацията на скоростта на Google: Подобряването на скоростта на вече бърз сайт няма да помогне за по-доброто му класиране

Колкото по-бързо можете да направите страниците на сайта си, толкова повече Google ще вземе предвид това. Новият ъпдейт за скоростта на зареждане от юли засяга само най-бавните сайтове. Ако имате бърз сайт и го направите още по-бърз, промяната няма да промени класирането му дори и малка да е тя.

google rankbrainGoogle използва RankBrain за изучаване и разбиране на нови потребителски заявки

RankBrain е средство, чрез което Google може да разбере заявките на потребителите, особено новите заявки, които никога преди не са се виждали.  Ние от Серпакт сме виждали какви ли не изказвания, особено тези, че Ранкбрейн класира сайтове, което не е вярно. Той се използва към момента само за изучаване на заявки за търсене и събиране на информация за потребителското поведение по страниците на Гугъл.

Честотата на обхождане няма нищо общо с класирането на резултатите в Гугъл

Ако Googlebot може често да обхожда сайта Ви, това не означава, че сайтът Ви ще се класира по-високо. Обхождането и класирането са две отделни неща.

IP адресите вече не се използват за GEOTARGETING или local SEO

Сървърните IP адреси на уебсайтовете са били сигнал за класиране на уебсайтове преди. Сега Google използва ccTLD, генерични TLD, hreflang, както и настройките в Google My Business и Google Search Console заедно, за да извлече информация за географското насочване, която е много по-полезна от тази от един IP адрес. Local IP адресите се използват от Гугъл само за държавите, където американските IP адреси са блокирани – например Северна Корея.

Google може да комбинира мета таговете на един ред

Гугъл може комбинира мета таговете на един ред, вместо да ги реди на разлини такива. Например content=”notranslate, nositelinkssearchbox”. Макар и да не се слува всеки път, търсачката може да го направи за по-бързото им разчитане и приоритизиране.

Гугъл отчита и оценява отново URL адреси, премахнати от Disavow файла.

Гугъл използва най-актуалната версия на disavow файла, подаден в този инструмент и в случай, че определени адреси от там са изтрити, то те ще бъдат отчетени и оценени отново от търсачката.

HTTP/HTTPS & WWW/NON-WWW версиите на URL-ите на Вашия сайт трябва да бъдат прехвърлени при MOBILE-FIRST INDEX отделно

Mobile-first indexing се извършва на ниво сайт, което означава HTTP/HTTPS и www/non-www се третират отделно и съответно на уебмастърите ще бъдат изпращани известия за прехвърлянията индивидуално.

Google няма определен принцип на ред при приоритизиране на страници за рендериране.

Google не използва определен наин или принцип за приоритизиране на определени страници в определен ред за рендерирането им, който да се различава от приоритизирането за регулярно обхождане и индексиране във втората вълна на процеса на индексиране. 

Не разчитайте на определени директиви от robots.txt да бъдат следвани и използвани от Гугъл

Не разчитайте noindex директивите в obots.txt да бъдат използвани от Гугъл, защото те не се поддържат официално от търсачката. По препоръки на Гугъл имайте резервен план за неиндексирани винаги, въпреки тези директиви.

google removal tool

Използвайте REMOVAL TOOL & SITEMAPS, за да информирате Гугъл за изтрити страници

URL Removal инструментът може да се използва, когато решите да изтриете адресите от поддиректория на Вашия сайт и това обикновено се случва успешно в рамките на ден. Ако изтривате адреси от сайта Ви в определени групи, но от различни поддиректории, то ги направете от типа 404 и укажете на Googlе, че вече не съществуват чрез сайтмап файла. Най-ефективно 

Можете да блокирате видео да не се показва в резултатите за търсене, като го блокирате в robots.txt файла или сложете дата на изтичане в видео сайтмап.

Как да го направите? Просто забранете обхождането на видеото и thumbnail-a му в robots.txt или добавете дата на изтичане / дата на давност чрез видео сайтмап файл.

Гугъл изисква специфични секции на уебсайта Ви за геотаргетиране, за да бъде то разбрано от него правилно

Макар и това да не е единственият сигнал за геотаргетирането, използван от Google, то търсачката очаква да „открие“ специфични секции от сайта ви, които се отнасят до геотаргетирането, каквото може да е например под-директория на сървъра от типа  domain.com/es/ или специфичен параметър.

Google дава няколко опции за правилна работа с продуктови страници, таргетиращи други държави

Първата опция е отделни лендинг страници с hreflang, което обаче също означава и, че качеството на страницата е разпределено. Втората опция е да си използват пренасочвания чрез IP redirects, но при това положение съдържанието в различните езикови версии е на един адрес и Гугъл може да индексира само английската версия например /ако тя е основната/. Може да се използват и елементи, визуализирани чрез елементи на JavaScript, които да бъдат блокирани от обхождане.

Ние от Серпакт препоръчваме – ако имате възможност, преведете изцяло съдържанието си и използвайте дори и преведени URLs за страниците на продуктите на различните езикови версии на сайта.

Сигналите за нарушение на авторски права и дублираното съдържание оказват влияние как Гугъл третира Вашия сайт

Ако голяма част от страниците на Вашия сайт са наказани от DMCA за нарушение на авторски правa, то Google може да определи и останалата част от съдържанието Ви като нискокачествена.

Ако даден сайт преработва съдържанието Ви може да се класира по-високо, ако Вашият сайт е с ниско качество

Когато сайтовете изземват и перифразират/преработват съдържанието на други сайтове, в случаите, когато тези сайтове успеят да се класиерат по-високо от оригиналния сайт, първоначалният сайт обикновено е с ниско качество. Това е мястото, където алгоритмите могат да се объркат.

fetch as google renderingКешът на Гугъл не е акуратен изтоник на GOOGLEBOT RENDERING

Имайте предвид, че рендерирането на страница може да бъде счупено в Гугъл кеш, за разлика от това, ако използватеFetch & Render инструмента в GSC and the Mobile-friendly Test tool, където рендеринга е много по-акуратен.

Не хоствайте съдържание на външни източници, ако използвате CDN

Необходимо е да хоствате колкото се може повече от съдържанието си на Вашия домейн, ако използвате CDN, защото в случай, че решите да смените доставчика на мрежата, то няма да имате контрол върху пренасочването на URL адресите при миграция на съдържание.

Google не използва pogo-sticking като фактор за класиране на специфични страници по специфични заявки

Google анализира потребителски данни в мащаб за милиони заявки, за да определи успеха на промените в алгоритъма. Това означава, че класирането за страница на ниво заявка няма да пострада, ако потребителите се връщат обратно към SERP от даден резултат.

Новият performance репорт на Google Search Console и старите репорти за грешки в обхождането показват данни от GoogleBot в различни етапи

Отчетът за ефективността в новата конзола за търсене грешките, които вече са били преработени. Това показва различни данни за отчета за грешки при обхождане в старата Search Console, която показва неизправните грешки.

a/b testing

Ако сте решили да правите A/B тестинг на сайта си при миграция, това може да забави Гугъл при обработката на сигналите повреме на миграция

Ако провеждате мащабно тестване от типа A / B повреме на мигриране на сайт, това може да обърка „картината“ на сайта ви в Google и да предотврати изпълнението на алгоритъм, с който лесно да стане превключването на всичките URL адреси към новата им версия.

Сайтмапът е най-доброто решение за Гугъл за обработка на мащабно маркиране с noindex.

Уверете се, че страниците, към които сте добавили noindex таг, са включени в sitemap-а на сайта с последната дата на промяна, за да се гарантира, че Google ще ги прихване възможно най-бързо. Уверете се, че последно променените дати са реалистични и не са еднакви за всяка страница, тъй като това изглежда изкуствено за Google.

Преместете Disavow файла и към мобилния си сайт за mobile-first indexing.

По същия начин, по който трябва да трансферирате файла за при прехвърляне от един домейн на друг или миграция към HTTPS, така трябва да трансферирате файла и към мобилния сайт, ако е бил качен преди това само на вашия desktop сайт.

Индекс системите на Гугъл са по-бавни с рендерирането от инструментите за тестване в реално време

Когато използвате инструментите за тестване на Google за проблеми при изобразяването на JavaScript, няма да получите истински точен изглед за това как Googlebot изобразява Вашата страница, тъй като инструментите имат много по-строго ограничение за изчакване, за да дадат на уеб администраторите бързи резултати.

По-кратките URL адреси не се ползват с преференции в Гугъл

Google не разполага с нищо заложено в алгоритмите си, така че те да предпочитат URL адреси, които са по-къси по дължина, независимо от това, което показват някои изследвания.

rich snippetsGoogle няма ограничения в символите при rich snippets

Google няма изрично ограничение за броя на знаците, включени в rich snippets. Дължината на фрагмента варира от резулта до резултат, понякога включва и структурирани данни, а не само мета описание, което може да варира също с течение на времето.

Използвайте log файловете на хостинг сървъра, за да установите загуби при обхождане и проблеми с  URL-ите.

При одита на сайтове за електронна търговия Джон Мюлер препоръчва първо да прегледате кои URL адреси се обхождат от Googlebot. След това идентифицирайте загубите при бюджета за обхождане и може би променете структурата на някои URL адреси на сайта, за да спре Googlebot да обхожда нежелани URL адреси с параметри, филтри и т.н.

Както става ясно, доста от тези новини променят мисленето и общоприетите практики в SEO до момента. Сред най-дискутираните теми са използването на IP адреси за класиране, дължината на URL адресите и значението й, доколко погостикинг е фактор за класиране, важен ли е HSTS, който се споменава често напоследък, защо сайтът не се рендерира правилно под Search Console или в Cache-a на търсачката, на какви принципи Гугъл приоритизира индексирането и тн.

Отговорите на Гугъл на всички тези, често дискутирани въпроси са явен знак, че представителите на компанията се намесват с компетентността си, за да помогнат на уебмастърите, но и за да спрат множеството слухове и догадки по всеки от тях.

Подобни статии