JavaScript SEO е работата съдържанието, което JavaScript изгражда, все пак да може да бъде намерено от търсачките. Google обработва такива страници на три етапа: обхождане, рендиране и индексиране. Средният е този, който изненадва хората, защото е отделен, чака на опашка и се случва по-късно. Това е ъгъл от техническото SEO, работата сайтът да остане четим за търсачките, в който провалите са тихи, а симптомите закъсняват.
На прост език
Мебели за самостоятелен монтаж.
Някои доставки идват сглобени. Отваряте вратата, виждате стол и няма какво да мислите.
Други идват като плоска кутия с части и лист с инструкции. Всичко нужно за стола е вътре. Но докато някой не намери време да го сглоби, складовият запис казва „кутия с части“, защото точно това е доставено.
Google сглобява кутията. Просто не винаги го прави веднага, а ако част липсва от опаковката, столът никога не се появява.
Защо това е важно за вашия сайт
Сайт, изграден така, може да изглежда перфектен за всеки, който го проверява, и да е до голяма степен невидим за търсачките за период, който никой не може да предвиди.
Проблемът е, че обичайните тестове не го хващат. Страницата се зарежда в браузър. Колегите виждат съдържанието. Аналитиката записва посещения. Междувременно версията, която Google е запазил, може да е черупката без описанието на продукта, цената или спецификацията. Проучване на Vercel и MERJ върху над 100 000 заявки на Googlebot показва медиана от около 10 секунди между обхождане и завършено рендиране, но най-бавният 1% от страниците са чакали около 18 часа, а адресите с параметри в URL още повече.
И се натрупва. Линкове, които съществуват само след изпълнение на JavaScript, са линкове, които Google намира късно, което забавя откриването на всичко, към което сочат.
Как работи всъщност
Обхождане. Googlebot взема адрес от опашката за обхождане и първо проверява robots.txt. Ако адресът е забранен, спира там. Google казва, че не рендира JavaScript от блокирани файлове или на блокирани страници, така че блокирането на папка със скриптове маха съдържанието, което тези скриптове биха произвели.
Парсване. Google чете отговора и извлича линкове от href атрибутите, добавяйки ги в опашката. Линкове, направени от click handler-и, а не от истински href атрибути, не се хващат на този етап.
Опашката за рендиране. Google нарежда за рендиране всяка страница с код 200 за успех, освен ако robots таг или хедър казва да не се индексира. Собственото описание на Google за чакането е, че страницата може да остане в опашката няколко секунди, но може и да отнеме повече.
Рендиране. Когато ресурсите позволяват, headless Chromium, браузърен двигател без видим прозорец, зарежда страницата и изпълнява JavaScript-а ѝ. Google го поддържа на актуална версия, така че модерните JavaScript функции се поддържат.
Обратно към обработката. Рендираният HTML се връща за второ минаване. Google извлича линковете отново, този път включително тези, които са съществували само след скриптовете, и използва рендирания резултат за индексиране, запазването на страницата в базата, от която идват резултатите.
Два капана, които си струва да се назоват. Google казва, че когато срещне noindex таг, може да пропусне рендирането изобщо, така че скрипт, който трябва да махне този таг, никога не се изпълнява. А услугата за рендиране на Google кешира агресивно и може да игнорира хедърите за кеширане и може да рендира страницата ви с миналомесечния JavaScript. Решението на Google за второто е fingerprinting на съдържанието: хеш от съдържанието на файла в името му, така че всяка промяна дава ново име.
Google не е единственият читател. Същите изследователи установиха, че AI кроулърите се държат различно: кроулърите на ChatGPT и Claude теглят JavaScript файлове, но не ги изпълняват, така че изобщо не могат да четат съдържание, рендирано от страна на клиента. Gemini е изключението, защото работи на инфраструктурата на Google. За всичко, което искате да бъде цитирано в AI отговори, рендирането от страна на клиента не е забавяне. Отсъствие е.
Как изглежда на практика
Търговец преизгражда сайта си като single-page application: сайт, който се зарежда веднъж и после сменя съдържанието на място, вместо да зарежда нови страници.
Суровият HTML за всеки продуктов адрес е една и съща празна черупка. Цялото продуктово съдържание идва после, от JavaScript. А навигацията по категории е направена от бутони с click handler-и, а не от линкове с href атрибути.
Google в крайна сметка рендира страниците, така че сайтът не е невидим. Но откриването зависи изцяло от картата на сайта, защото няма обхождаеми линкове, които Googlebot да следва. Всяка продуктова страница чака в опашката за рендиране, преди съдържанието ѝ изобщо да съществува за Google. А за асистентите, които не рендират, целият каталог е празни черупки.
Нищо тук не е счупено. Всяко решение е било разумно за приложението. Никое не е взето с мисъл за опашката за рендиране.
Какво хората обикновено грешат
„Google не може да чете JavaScript.“ Може, с актуален браузърен двигател. Рискът е във времето и конфигурацията, не в способността, и третирането му като способност води до грешни поправки.
„Ще сложим noindex сега и ще го включим със скрипт по-късно.“ Google може никога да не изпълни този скрипт, защото може да пропусне рендирането, щом види тага.
„Качихме поправката, значи Google я има.“ Не задължително. Агресивното кеширане от страна на Google може да го остави да рендира стари файлове, ако имената им не се сменят със съдържанието.
„Блокирането на скриптовите файлове намалява натоварването от обхождане.“ Спира и рендирането на всичко, което тези скриптове произвеждат, а това обикновено е съдържанието, което искахте индексирано.
Какво можете да направите
Пуснете URL Inspection в Google Search Console на важна страница и прочетете рендирания HTML. Ако описанието на продукта, цената или основният текст липсват от него, това е цялата диагноза.
Сравнете го със суровия код в браузъра. Разликата между двете е колко от сайта ви зависи от рендиране, и колко е невидимо за всичко освен Google.
Правете навигацията от истински линкове с href атрибути, дори в приложение, което прихваща кликовете. Двете може да са верни едновременно.
За съдържание, при което бързината на откриване е важна, новини, продукти, обяви, сложете основното съдържание в първоначалния HTML чрез рендиране от страна на сървъра, при което страницата се генерира на сървъра, преди да се изпрати.
Слагайте fingerprint на имената на JavaScript и CSS файловете, така че промяната винаги да изглежда като нов файл.
Следете и отзивчивостта покрай това. Тежкият JavaScript от страна на клиента е най-честата причина за слаб Interaction to Next Paint, една от Core Web Vitals, метриките за това как страницата се усеща от реалните посетители.
Думи, които ще чуете
Рендиране от страна на клиента. Изграждане на страницата в браузъра на посетителя, а не на сървъра.
Рендиране от страна на сървъра. Изграждане на страницата на сървъра, така че HTML да пристигне готов.
Hydration. Закачане на JavaScript поведение към HTML, който вече е доставен.
Опашка за рендиране. Списъкът с изчакващи страници, които Google е обходил, но още не е рендирал.
Single-page application. Сайт, който се зарежда веднъж и сменя съдържанието на място.
За рендиране, кроулър и индекс вижте Как работи търсенето. За SERP, запитване и Search Console вижте Какво е SEO?
