Защо Google не преобхожда променена страница: lastmod, canonical и трите лоста, с каталога, в който 335 страници мълчаха от май

Google не преобхожда променена страница по три причини, и трите се проверяват за минути. Първата: датата lastmod в картата на сайта е датата на билда, една и съща за всеки адрес, и Google се е научил да я пренебрегва, така че няма сигнал, че нещо се е променило. Втората: страницата носи canonical към друг адрес, най-често началната страница, и Google я е записал като копие, което няма причина да посещава. Третата: Google преобхожда по собствен график, по-рядко за страници, които са били еднакви при последните му посещения, и промяна без сигнал чака месеци. Видяхме и трите в един каталог: 335 от 829 продуктови страници на магазин за климатици мълчаха от май до септември 2026 г., при напълно поправен код.

Какво показаха данните

Проверката беше през API за инспекция на адреси на Google, не по предположение. Всяка продуктова страница, преобходена преди юни, носеше в записа на Google canonical към началната страница, резултат от грешка, поправена още тогава. Всяка страница, преобходена след август, носеше правилния canonical към себе си и беше индексирана. Разделението беше чисто: кодът беше верен от месеци, а записът на Google беше стар, защото Google не се беше връщал. В извадка от 120 мълчащи страници 38% бяха записани като „дубликат, Google избра друг canonical“. Единственият автоматичен лост, който би върнал робота, датата lastmod, беше подпечатан с датата на билда за всеки адрес, и затова не действаше.

Трите лоста, в реда, в който действат

1. lastmod на страница, от реалната промяна. Всяка страница в картата на сайта носи датата, на която самата тя се е променила, взета от последния ѝ запис в системата за версии или в базата, а не от часа на билда. Google казва, че използва lastmod, когато е последователно точен. Карта, в която всеки адрес носи една и съща дата, е карта, която Google се е научил да пренебрегва.
2. Canonical към себе си, в HTML, и никога променян от JavaScript. Страница, чийто canonical сочи другаде, е страница, която Google няма причина да преобхожда отново; поправката на тага е началото, а не краят, защото записът на Google се обновява едва при следващото посещение.
3. Заявка за индексиране в Search Console за страниците, които тежат най-много, и то и в двете свойства, ако имате и домейн, и адрес с префикс: двете водят проверките и заявките поотделно. Това е ръчният лост, ограничен на брой, и се използва за десетте страници, които печелят.

Една страница, която връща код 200 и „пренасочва“ с мета refresh или скрипт, не е пренасочване. Google я индексира като страница, и всички стари адреси се сливат в един запис. Пренасочването е отговор на сървъра с код 301, преди каквато и да е страница.

Какво направихме и какво чакаме

Три малки промени, не нов сайт. Остатъчният мета refresh стана истинско 301. Картата на сайта получи дата на страница от реалната промяна. Десетте най-важни продуктови адреса получиха заявка за индексиране и в двете свойства. После на 22 септември беше натиснато „Потвърди поправката“ в Search Console за цялата категория дубликати, и същия ден всеки адрес от нея мина през инспекция, за да има картина „преди“: 402 адреса, чийто canonical в записа на Google беше един и същ заглушен продукт. Проверка по график сравнява с тази картина всяка седмица. Какво е върнато ще пише на страницата ни с резултати, когато има число, а не очакване.

Двете свойства в Search Console

Повечето сайтове имат две свойства в Search Console, без собственикът да знае: свойство за домейна, което обхваща всички адреси и протоколи, и свойство с префикс за https адреса. Двете водят заявките за индексиране, проверките на поправки и отчетите за страници поотделно. Заявка, подадена в едното, не се вижда в другото; поправка, потвърдена в едното, не се потвърждава в другото. На каталога от този случай „Потвърди поправката“ беше натиснато и в двете, и проверката по график чете и двете. Ако имате само едно свойство, направете и второто; то е безплатно, и половината от объркването в отчетите идва от това, че човек гледа едното и мисли за другото.

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

Колко време е нормално да се чака

Google преобхожда страници, които се променят често и имат връзки към тях, за дни; страници, които са били еднакви при последните му посещения, за седмици или месеци. Каталог с осемстотин продукта, които не се променят, е най-бавният случай: Google научава, че няма какво ново да види, и идва все по-рядко. Трите лоста скъсяват чакането, но не го премахват. Разумният план за каталог като този е четене на всеки седем дни на върнатите адреси срещу картината „преди“, без да се пипа нищо друго, за поне шест седмици, защото всяка допълнителна промяна в същия прозорец прави двете неразличими в отчета. Търпението тук е метод, не липса на такъв.

Как да проверите своя сайт за десет минути

• Отворете картата на сайта и погледнете колоната lastmod. Ако една дата се повтаря на всеки ред, това е датата на билда, и лостът не действа.
• Отворете кода на три страници и потърсете rel=canonical. Той трябва да сочи към самата страница.
• В Search Console, отчет Страници: редовете „дубликат, Google избра друг canonical“ и „открита, но не е индексирана“ са двата списъка, с които започва работата.
• Инспектирайте пет адреса от тях и прочетете датата на последното преобхождане. Ако е отпреди поправката, Google не знае за нея.

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