Comments 48
Вот интересно посмотреть на кейсы трафика из Microsoft Store. Какую органику он даёт, какой % платящей аудитории от органики.
похоже, что сделать просто это и есть самое сложное
Я не понял механизма индексирования - от кого получается url и кому отдаётся html? Как он встроил браузер между запросом googlе (другого поисковика) и ответом ему же? Или это надстройка над реакт, которая проксирует весь вывод для клиента? Тогда где здесь место облаку?
Вот так работает:
1. Googlebot или пользователь заходит на наш сайт.
2. Если запрос идёт от пользователя, отдается обычное React/Vue SPA. Если запрос идёт от Googlebot передается запрос на Prerender.
3. У Prerender крутится в облаке headless Chrome. Он реально открывает страницу, ждёт пока JS отработает и получает финальный HTML.
4. Финальный HTML отадется Googlbot и в индекс попадает нужный контент.
Спасибо за комментарий. Уточню статью 🤝
То есть ваш сайт выступает прокси и из этого должно следовать, что рекламу нужно давать на ваш домен, продвигать ваш домен и сайт клиента будет уже доменом третьего уровня?
Нет, конечно. Почему сайт клиента вынужден быть доменом третьего уровня при такой схеме?
Но запрос на сайт через ваш адрес?
В списке просто пропущено пара этапов относительно очевидных из контекста:
2. Если запрос идёт от пользователя, отдается обычное React/Vue SPA. Если запрос идёт от Googlebot передается запрос на Prerender <средствами вашего ресурса/сайта>.
4. Финальный HTML <полученный вашим сайтом/ресурсом от Prerender> отадется Googlbot и в индекс попадает нужный контент.
Не читал доку этого конкретного сервиса, но любой приличный SaaS имеет опцию привязки домена клиента - клиент прописывает в DNS IP сервера SaaS, а SaaS по заголовку Host понимает какой клиент пришёл и обрабатывает его соответственно (разумеется, в личном кабинете клиент должен прописать свой домен).
Но можно, например, в конфиге своего веб-сервера прописать разный proxy_pass для гугл бота и для всех остальных. Ничто не мешает в proxy_pass поставить вместо бекэнда внешний ресурс. Тогда от SaaS не требуется даже фича привязки домена.
это называется клоакинг. Клоакинг — это техника маскировки, при которой на один и тот же URL-адрес показывается разный контент в зависимости от того, кто его посещает: поисковый робот или обычный пользователь. Гугл обычно зайдет с обычной айпихи. увидит что контент разный и выбросит из поиска.
У гугла в документации написано, что клоакинг это когда итоговое содержимое разное. Грубо говоря, гугл боту отдают сайт про яблоки, а юзеру сайт про груши.
То есть либо определение клоакинга не автоматическое, либо его детектят более продвинутые боты, умеющие исполнять JS (например, через тот самый headless chrome).
Всё это напоминает doorway, который Гугл очень не любит. И ещё Гугл не любит и понизит в рейтинге, если узнает что пользователям отдается одно, а ботам другое. А он узнает, не все гуглботы имеют в ua надпись googlebot .
Не дорвей а клоакинг скорее. И пока вы специально две версии не делаете разными то с чего бы ему понижать?
Вот что об этом говорит сама документация гугла:
https://developers.google.com/search/docs/crawling-indexing/javascript/dynamic-rendering
Dynamic rendering is not cloaking
Googlebot generally doesn't consider dynamic rendering as cloaking. As long as your dynamic rendering produces similar content, Googlebot won't view dynamic rendering as cloaking.
When you're setting up dynamic rendering, your site may produce error pages. Googlebot doesn't consider these error pages as cloaking and treats the error as any other error page.
Отдается одно и тоже. Причем здесь doorway? Отдается условно "кешированная страница" SSR. Как там этот SSR организован никто никогда не знает.
Да, это прям чистый клоакинг, за который очень часто прилетает бан в Google Ads, даже если вы ничем таким не занимаетесь, а просто A/B тесты те же делаете через TDS.
Чего я не понимаю, это почему ему вообще кто-то платит.
Разработчики, не гумунитарии какие-нибудь, пишут свой продукт на Angular, React или Vue и где-то его хостят. Если это маленький стартапер, он за сотку или две лучше подрядит кого-нибудь пару багов пофиксить. А если это крупная компания, то зачем ей зависеть от какого-то там Тодда в вопросах SEO, когда можно дать девопсу задачу поднять у себя пререндерер, любезно выложенный самим Тоддом? Я бы ещё понял, если бы в лицензии для корпоратов было написано, мол, передаём за проезд (ту же сотку), но предлагать им облачную услугу?
Как говорила Муму: «Что-то Герасим Тодд недоговаривает». 🤔
Есть немаленькие компании в которых вообще нет штатных ит-шников. Внезапно - таких компаний гораздо больше чем с айтишниками. И заказывать этот инструмент будет тот кто отвечает за маркетинг, потому что ему надо SEO. А уж за маркетинг всегда кто-то отвечает.
Да фиг с ним, с Тоддом. У меня вопрос к автору, как он грамотно выдал некий саксесс стори некоего Тодда как удачный пример стартапа за 1 месяц, и потом 220к рубим.
Это если компания айтишная. А если условная кафешка заказала фрилансеру сайт с меню и функцией заказа или взяла что-то готовое, а потом обнаружила проблемы с SEO, то она может выбрать заплатить за готовый сервис, потому что штатного админа у нее нет. И сервера нужной производительности для headless chrome может не быть. А может вообще сервера нет и весь бек тоже SaaS.
В моём мире, прежде всего, если условная кафешка обнаружит проблемы с SEO, она не будет вдаваться в подробности, а устроит скандал разрабам («…вы сделали плохой сайт, который не видит Гугл!!111») и потребует всё переделать. Бесплатно. А если получит отказ — разместит плохой отзыв на разраба, зафиксирует лося и перезакажет у других с учётом полученного опыта, а не будет пожизненно платить неизвестно кому 1000-2400$ в год. Сайт с меню, если не надо делать макеты, если графоний готов, и даже вёрстка нарезана, стоит очень недорого.
От сути моего вопроса вы никуда не уйдёте: по сравнению с разработкой на Ангуларе задача развернуть готовый скрипт — примитивная задача, и не стоит она запрашиваемых денег. А если кто-то скажет, что для больших корпораций это маленькие деньги, тот просто не видел больших корпораций. Как, например, менеджер на устройстве, которое компания продавала за 11 000, заменил аппаратную кнопку на программную, сэкономив 5$ на производстве (пользователи жутко матерились), а затем выписал себе годовой бонус за экономию. И про производительность для headless chrome не надо. Для этого придумали кеширование.
Короче, история оставляет много вопросов.
Шаг 1: вместо HTML отдавать пользователю хрень собирающуюся в браузере.
Шаг 2: обнаружить, что Гугл вас не любит.
Шаг 3: сделать нормально... да не, не нужно. Лучше сделаем костыль, который будет давать негарантированный результат.
Первый шаг в первую очередь делается что-бы свои сервера сбором этих страниц не нагружать.
Это в теории и изначально, а сейчас уже никто не помнит зачем были созданы именно эти инструменты, как правильно ими пользоваться и во что это обходится.
На самом деле, тут есть ироничный момент.
Потому что этот DHTML изначально делался для нескольких вещей (включая, счистелки-перделки), среди которых было не только уменьшение нагрузки на хостинг, но и уменьшение нагрузки на узкий и дорогой канал пользователя.
И вот это вот облегчение жизни пользователю было основным. Поэтому же были галереи картинок с мелкими превьюшкам и подгружающимися большими.
Потом в дело включился гугл и стал пугать темой "скорость загрузки страницы", из-за чего активно стали внедряться всякие асинхронные загрузки.
Попёрли библиотечки, на которые стало модно ругаться "для подсветки кнопки вы заставляете пользователя грузить аж целый мегабайт яваскриптов".
Ну и шаг за шагом мы пришли вот к этому.
Меня каждый раз это веселит, как от желания сэкономить трафик пользователя на несколько десятков килобайт кода отвечающего за дизайн веб-сайта мы пришли к монстрам отжирающим память и процессор в таких количествах, от которых четверть века назад можно было сойти с ума.
среди которых было не только уменьшение нагрузки на хостинг, но и уменьшение нагрузки на узкий и дорогой канал пользователя.
Никогда не видел варианта "сэкономим трафик пользователю". Наоборот, ещё с 2008 (ангуляр вышел в 2009) все ит-компании ставят на то, что ширина канала у всех пользователей будет продолжать расти (что фактически и происходит), трафик уже не проблема.
Проблемой же была отсталость IE6, разнородность браузеров (пилим фичу на 3 браузера: ie6, opera, mozilla), и по сути отсутствие динамики, которое начал решать Angular: просто заводим некую "переменную", выводим её пользователю, и в случае её изменения - данные в нужном месте браузера обновятся самостоятельно, без сложной перестройки.
Наоборот, ещё с 2008
Я же говорю о том, с чего начиналось, а не о том к чему пришло :)
А началось это с того, что держать веб-сайты во фреймах было неудобно, а перезагружать прям всю страницу прям со всеми картинками ради того чтобы добавить товар в корзину или изменить количество товара в корзине, это было очень жестоко по отношению к пользователям.
Веб-чаты, крутотень 1990-х, работали именно на фреймах (причём, более чем на одном, чтобы список сообщений и список пользователей обновлялись независимо.
В те далёкие и основательно забытые времена, Microsoft дал нам технологии, сделавшие интернет таким, каким он является сейчас:
- бесплатный веб-браузер
- коллекцию all , один в один переехавшую в DOM
- XMLHttpRequest , превратившийся в AJAX
- contenteditable , те самые WYSIWYG в браузере
Всё это происходило под стоны разлагающегося зомби-Netscape , которого тщетно пытались гальванизировать и отправить как торпеду в борт IE от Microsoft , и крики крайне редких, но очень громких фанатов норвежского софта, радующихся что Opera с её ноль целых хрен десятых процентов рынка является третьим по популярности веб-браузером в мире.
Проблемой же была отсталость IE6, разнородность браузеров
Забавно то, что Вы это в одном предложении написали.
Никто никогда не поддерживает стандарт на 100% и только стандарт. Все выдумывают что-то своё.
Только вот когда IE не поддерживает CSS с префиксом -moz- , это называют "отсталость IE", а когда наоборот - "разнородность браузеров". :)
Все рассказы про отсталость IE6 это часть популярной истории "давайте соберёмся и победим Microsoft", при этом за отсталость выдавалась тяжеловесность нормального браузера по равнению с никчёмностью Mozilla/Firefox.
Вы же помните, как Mozilla раз за разом ломала обратную совместимость плагинов, обеспечивая себе ту самую лёгкость и скорость?
Ну и в итоге мы имеем настолько прожорливого и тормозного монстра Firefox , что поведение IE6 за тормоза можно и не считать
по сути отсутствие динамики, которое начал решать Angular
Есть очень простой закон развития техники: Если вы видите кого-то кто есть на рынке давно и кто там уверенно закрепился, то значит он был не первым. :)
К моменту появления Angular в его нынешнем виде, уже во всю были prototype и JQuery.
В принципе, мы тут имеем ту же ситуацию, что и в любой другой нише.
Есть актуальный производитель, который рассказывает СВОИМ пользователям (в нашем случае, веб-разработчикам) СВОЮ историю. Его пользователи транслируют эту историю всем остальным. Создаётся иллюзия, что динамические страницы появились в вебе после прихода Angular , а веб-браузеры после того как появился Firefox.
В случае с браузерами, это весьма поучительная ситуация, потому что Firefox получил успех лишь после того, как Google стал его продвигать.
А миленький штурвальчик NN3, после смерти которого начались надругательства над его именем и памятью, как-бы остаётся за рамками этого мифа.
Все таки, что на это говорит гугл?
Из своего опыта я знаю, что он противник "сокращателей" ссылок и редиректов даже в рамках одного домена, даже если описание идентично содержимому. Мне блокировало рекламу моего же ресурса с сообщением, что "зафиксирована подмена контента, атата" (не помню точную формулировку).
Как интересно поплучается, когда началась мода на вот это все динамичное, я задавал простой вопрос, а что делать с поиском. Мне гуру фронта с пеной у рта доказывали, что все схвачено и все модные нынче фреймвоки умеют сервер сайд рендер и отдают гуглу уже готовый документ, а не ведро непойми чего.
А тут получается, что никакого сервер сайда в модных фреймвоках нет и для нормального индекса надо поднимать еще что то одтельное, которое не много не мало запускает ядро хрома на сервере, для вобщем то простой операции.
Эх где мой теплый ламповый интеренет, без всего вот этого, когда нормальная страница грузилась модемом за десяток секунд.
Это больше к пониманию того, насколько компетентные люди переоценивают окружающих. Я помню, как пилил SSR сайты и сам писал движок, который рисует идеальный пререндер по крайней мере 10 лет назад, я помню как еще тогда возмущаелся, что сайт, который возвращает "Cant display shiet" получал 100 баллов производительности от гугла, а я с кровью в глазах выбивал крупицы распараллеливая саму преисподню.
Мне и в голову не приходило, что это может быть проблемой сегодня.
AI Mode окончательно добьет всё SEO и разные претедендеры просто исчезнут.
А Google теперь официально рекомендует Prerender в своей документации по Dynamic Rendering.
Не вижу ничего подобного https://developers.google.com/search/docs/crawling-indexing/javascript/dynamic-rendering видимо написано для красного словца.
Более того, на той же странице гугл признаёт dynamic rendering костылём и сообщает что есть способы лучше.
В статье правильно сказано, что надо стараться сделать проще. Но как это соотносится с тем, чтобы перегружать сайт js и динамическими элементами, получить проблему индексации, и потом начать героически её решать? Когда весь основной html можно сразу формировать на сервере, и вообще не иметь этой проблемы...
Спасибо за интересное замечание. Формулировку уточнил.
Но это не для краснога словца. В доках Google действительно было напрямую указано, что поисковик рекомендует Prerender для Dynamic rendering https://web.archive.org/web/20230306081550/https://developers.google.com/search/docs/crawling-indexing/javascript/dynamic-rendering#implement.
Позже Google стал продвигать только свой аналог - Rendertron, а остальные убрал. Еще позже добавил плашку с с рекомендацией использовать server-side rendering и static rendering вместо dynamic rendering.
Но считаю, что это не умаляет достижение инди-хакера оказаться в официальных доках Google.
И даже несмотря на то, что появились более совершенные технологии, сервис до сих пор под капотом у кучи проектов. Примерно, как WordPress по-прежнему поддерживает половину сайтов в Интернете (несмотря на устаревший по мнению многих PHP).
Фокус статьи был не в том, чтобы показать, что эта технология лучше всех на сегодняшний день. А разобрать очень толковый способ продвижения сервиса.
Но это же занимает время, бот пометит сайт как тормозной и снизит рейтинг
История красивая, но это типичная ошибка выжившего. Челу повезло найти потребность, повезло что может ее легко решить, повезло пробиться через толпы конкурентов, которые почему то оказались глупее его.
Согласен. Вот только то, что это ошибка выжившего, не должно мешать пробовать, ошибатьсч, снова пробовать и таки найти что-то свое и самому стать ошибкой выжившего. Само существование человечества по сути ошибка выжившего.
Ну потребность нашел не пользователь, она существовала до него, конкуренты были до него и по итогу он создал опенсурсный инструмент для решения проблемы. Что тут удивительно это то что опенсурсное принесло ему денег.
При том что даже для интеграции его платного решения нужно хоть немножко да шарить, хотя бы уровня поменять конфиг Apache/ngingx.
Как я понял мораль статьи, она в том, что можно не вслепую придумывать потребности может выстрелит, может нет, а проверять потребности по статистике гугла.
Грубо говоря, не закупиться слонами, а потом давать контекстную рекламу "купи слона" и пытаться угадать с ключевиками "купить большое домашнее животное". А сначала обнаружить тренд в Гугле, что люди ищут "купить слона", а там в выдаче фигня и уже под это дело открыть магазин слонов.
А если люди ищут не "купить слона", а "купить удава", то сменить идею на магазин удавов вместо магазина слонов, который никто не ищет.
В общем, чтобы идея проистекала из того, что люди уже ищут без нашего участия, но у нас есть причины полагать, что мы хорошо вклинимся в эту выдачу (например, потому что текущая выдача не содержит решения проблемы совсем или все они сложнее чем можем сделать мы).
С идеями же не так сложно их придумать (в кейсе автора он тупо взял то, что ему было нужно самому) как отфильтровать стоящие внимания. Потому что 99% идей нужны другим людям только в воображении автора.
Ничего, что в том же ангуларе из коробки есть prerender во время сборки, есть живой ssr рендер через облачные функции, на крайний случай, есть еще npm библиотеки, которые так же соберут index.html под каждую страницу из роутов
Кому нужен этот сервис из поста? лет 5 назад, наверное, это было актуально, сейчас же все делается из коробки за три нажатия
$220К в месяц на индексации сайтов для Google