След редизайн сайтът може да изглежда по-бърз и по-удобен, но част от важните страници да изчезнат от резултатите на Google. Друг често срещан признак е Google да показва старо заглавие, да не открива връзки към продукти или да вижда страница без основния текст.
Това не доказва автоматично, че JavaScript е причината. Доказан JavaScript SEO проблем има, когато важен елемент присъства за посетителя, но липсва или се променя във версията на страницата, която Google може да обработи.
Краткият отговор е: сравнете какво връща сървърът, какво се появява след изпълнението на JavaScript и какво показва проверката на Google. Ако разликата засяга основния текст, заглавието, canonical адреса, указанията за индексиране или важните връзки, сайтът има технически риск, който трябва да бъде измерен по групи страници.
JavaScript SEO е проверка дали търсачката получава надеждно съдържанието и техническите елементи на страница, която използва JavaScript. Rendering е процесът, при който кодът се изпълнява и се създава завършената версия на страницата.
Самото използване на JavaScript не е проблем. Google изпълнява JavaScript, но обработката зависи от достъпни файлове, успешни заявки към външни услуги и код, който приключва без грешка. Затова твърдението "сайтът работи в моя браузър" не е достатъчно доказателство.
За бизнеса важният въпрос не е коя технология е използвана. Важното е дали Google получава последователно:
Google описва три основни етапа при обработката на JavaScript страници: обхождане, rendering и индексиране. Първо Googlebot заявява URL адреса и получава отговора на сървъра. След това страницата може да бъде изпратена за rendering, при който JavaScript се изпълнява. Накрая Google анализира получената версия и решава как да я използва в търсенето.
Тези етапи не са непременно един и същ момент. Страница с код 200 може да изчака за rendering. Ако необходим файл е блокиран, заявка към API се провали или кодът прекъсне, крайната версия може да остане непълна.
Google посочва също, че не всички ботове изпълняват JavaScript. Това е още една причина важната информация да не зависи от сложна поредица от действия в браузъра. Официалното описание е в основните насоки за JavaScript SEO.
Една надеждна проверка сравнява три различни състояния на един и същ URL адрес.
Това е кодът, който сървърът връща преди изпълнението на JavaScript. Той показва дали основният текст и важните връзки са достъпни веднага, или първоначално се връща почти празна обвивка.
Това е версията, която виждате в браузъра след зареждането. Тя може да зависи от бисквитки, вход в профил, местоположение, съгласие за бисквитки, успешно заредени данни или действие като натискане и превъртане.
Проверката на URL в Google Search Console може да покаже HTML след rendering, снимка на страницата и проблеми със зареждането. Тази проверка е по-близо до въпроса какво получава Google, но една примерна страница не доказва, че всички продуктови, категорийни или езикови страници работят еднакво.
| Елемент | Какво трябва да установите |
|---|---|
| Основен текст | Присъства ли и в трите версии, без да зависи от действие на посетителя? |
| H1 и заглавия | Еднакви ли са и описват ли конкретната страница? |
| Важни връзки | Използват ли нормален HTML елемент <a> с href? |
| Canonical | Сочи ли към една и съща правилна стойност? |
| Указания за индексиране | Появява ли се неочаквано noindex? |
| Структурирани данни | Съвпадат ли с видимото съдържание? |
Разлика между версиите не винаги е дефект. Меню, форма или интерактивен филтър може умишлено да се появи по-късно. Риск има, когато разликата променя смисъла на страницата, достъпа до важен URL или указание към Google.
Най-полезните признаци са конкретни и могат да бъдат повторени при повече от една страница:
200, а съобщението за липсваща страница се показва само чрез JavaScript;Google препоръчва важните връзки да бъдат HTML елементи <a> с атрибут href. Връзка, реализирана само чрез действие на скрипт, не се извлича надеждно. Това е описано в официалните насоки за връзките.
При единичен URL причината може да е редакционна грешка. Когато един и същ признак се повтаря в шаблон, рискът е системен и приоритетът е по-висок.
Приоритетът не се определя само от броя технически грешки. Първо се оценява дали липсва елемент, без който страницата не може да изпълни основната си задача. Липсващ продуктов текст, празна категория или недостъпна връзка към основна услуга са по-важни от малка разлика в допълнителен елемент.
След това се проверява обхватът. Една засегната статия обикновено изисква ограничена корекция. Един дефект в общ шаблон може да засегне стотици продукти или услуги и трябва да се разглежда като системен риск. Накрая се отчита дали проблемът пречи на посетителя, на Google или и на двете страни. Така техническият списък се превръща в ред за действие, който е разбираем и за управленския екип.
Липсата на страница в Google не доказва JavaScript проблем. Причината може да е видима още преди изпълнението на кода: забрана за обхождане, указание noindex, canonical към друг адрес, грешен HTTP код или пренасочване. Възможно е също Google да е получил страницата правилно, но да не я е избрал за индексиране.
Практичното разграничение е просто. Ако грешката вече присъства в отговора на сървъра, тя не е възникнала при rendering. Ако изходният HTML е правилен, но важен елемент липсва след изпълнението на JavaScript или в проверката на Google, тогава има основание да се изследва JavaScript реализацията.
Тази граница предпазва бизнеса от погрешно решение. Смяна на платформа няма да поправи страница, която умишлено е отбелязана с noindex. От друга страна, редакция на текста няма да помогне, ако шаблонът не подава текста към Google. Диагностиката трябва първо да установи етапа, на който се появява разликата, и едва след това да избере корекция.
Няма един модел, който автоматично решава SEO. Има модели, при които важната информация е достъпна по-рано, и модели, които зависят повече от успешно изпълнение на JavaScript.
| Модел | Какво получава посетителят първоначално | Какво трябва да се провери |
|---|---|---|
| CSR, зареждане в браузъра | Често основа на страницата и JavaScript файлове | Дали съдържанието и връзките се появяват надеждно без допълнително действие |
| SSR, зареждане от сървъра | HTML с основното съдържание | Дали версията от сървъра и версията след JavaScript остават еднакви по смисъл |
| SSG, предварително създаден HTML | Готов HTML файл | Дали всички нужни URL адреси са създадени и данните се обновяват навреме |
| Смесен модел | Различен подход според вида страница | Дали продуктите, категориите и статиите имат последователно поведение |
CSR може да работи добре за Google. SSR и SSG също могат да имат грешен canonical, непълен текст или счупени връзки. Името на технологията не заменя проверката на реалния резултат.
Google вече определя динамичния rendering, при който на ботовете се подава отделна версия, като временно решение, а не като предпочитан дългосрочен подход. Причината е допълнителната сложност и рискът различните версии да се разминават. Вижте официалната препоръка за динамичния rendering.
Не приемайте общи уверения като "Google изпълнява JavaScript" или "имаме SSR". Поискайте кратък пакет от доказателства за представителни URL адреси:
Този пакет е достатъчен, за да се реши дали проблемът е единичен, ограничен до един шаблон или засяга голяма част от сайта. Той също така предотвратява скъпа смяна на платформа без доказана причина.
Вътрешният екип обикновено може да приключи проверката, когато проблемът засяга една страница, причината е ясна и корекцията може да бъде потвърдена в изходния HTML и в Google Search Console.
Пълна диагностика е по-подходяща, когато:
JavaScript SEO проблем не се доказва с името на използваната технология. Доказва се чрез сравнение на конкретни URL адреси и чрез повторяеми разлики между първоначалния отговор, страницата след JavaScript и версията, която Google може да обработи.
SEO одитът на SeoWebDesign може да установи кои групи страници са засегнати, какво точно липсва и кои корекции трябва да бъдат изпълнени първо. Така решението започва от доказания проблем, а не от предположение или скъпа промяна на платформа.
