Комментарии 93
Хотя согласен что не хватает продолжения и счастливого конца )
Или, как сделали мы, просто выдаем гуглу и компании голую страничку, со всеми данными, которые надо скормить поисковику. Да и вид можно сделать такой, чтобы поисковик доволен остался.
А рекомендует это гугл или нет, это не важно, пока это работает.
Как я уже сказал ранее, мы решили не делать SSR не потому что мы не можем, а по тому что Google сам отказался это этого метода. И мы решили попробовать скормить наш сайт без SSR. И выяснили что на сегодняшний день лучше все-таки использовать SSR.
Не для разных User-Agent, а для разных _escaped_fragment_=. Мы так делали, всё отлично индексируется разными поисковиками. Более того, сайт давно мёртв, а ссылки всё ещё в индексе :-)
И что? Он как работал так и будет работать. Причём работает он не только с гуглом. А если гугл когда-нибудь и выпилит его поддержку — ничего не сломается.
У меня есть сайт на angular работающий на данном способе. Но сейчас, с приходом react'а, я предпочитаю пререндерить страницу не только для SEO, но и для пользователей (что имеет свои плюсы). При этом например метод с _escaped_fragment_ не понимали боты соц. сетей и для них приходилось городить определение по user-agent'у на уровне nginx'a и перенапрявлять на тот же _escaped_fragment_.
В общем я за простоту, особенно если спека помечена как deprecated)
https://webmasters.googleblog.com/2015/10/deprecating-our-ajax-crawling-scheme.html
Кроме того, не стоит забывать, что гугл — не единственный поисковик.
{
«status»: 301,
…
}
Зачем этот костыль? Есть же стандартные коды состояний HTTP.
я вот тоже не понял, вначале подумал, что фронтенд полностью независим от друпала, у них просто общая база, но потом увидел, что весь контент все же отдает друпал через апи. В таком случае для Angular хватило бы просто статической странички в паблик-папке (не знаю, как точно в друпале это сделано, думаю, так же как и у всех остальных фреймворков)
<script>
window.initialData = {};
</script>
Но естественно на каждую страницу не хочется в бекэнде прописывать какие данные должны быть в хтмл. Я решил эту проблему путём проверки вида запроса при обращении к странице, если запрос ajax — значит это реальный пользователь ходит туда сюда по сайту, если запрос get — значит это поисковик, соотвественно когда это поисковик, я запускаю phantomjs он идёт по этому же адресу (по user agent исключаем рекурсию) и ждём скажем 3 секунды, после этого ответ отдаём гуглу. По идее за три секунды все ajax'ы должны были отработать.
Если данные передавать уже вшитыми в страницу, тогда эта страница будет очень долго отдаваться. Весь смысл перехода на JS пропадает.
А если все на ассемблере переписать, то ваще быстро будет.
Вовсе нет. Если данные отдельно подгружать, их можно закешировать как статику и положить в CDN. Что мы собственно и сделали.
В этом случае клиент практически мгновенно получает страницу, которая подгрузит данные с ближайшего географически распределенного кэша. Что также значительно снимает нагрузку с основного сервера.
Мы уже экспериментировали с тем методом, что Вы описали. Вот допустим здесь, одна из самых нагруженных наших страниц. Все комментарии загружаются прям в страницу, и потом отрисовываются через angularjs.
Это разрешение поисковым роботам на доступ к адресам вида /v1/*
Этот префикс мы используем для REST API.
Если запретить api в robots.txt то Google бот не сможет загрузить данные для странички.
Я вот, полагал, например, что сферический бот в вакууме, он да — при заходе на сайт ищет все ссылки и пытается их открыть, честно учитывая то что в robots.txt,
Но когда у поисковиков пошёл тренд на поведенческие факторы, SPA, AJAX и т.п. я представлял себе, что они со своей стороны открывают страницу неким юзер-агентом приближенным к полноценному, которому, разумеется до robots.txt нет дела, если часть контента получается через AJAX.
Да, это проверенная информация. Google Search Console ругается на это, если заблокировать, и страницу на предпросмотре показывает без данных.
На каждый запрос пользователя на новую версию вы внутри делаете https запрос на старую версию, чтобы вытянуть информацию по редиректам?
При этом у вас response time для PHP в районе 70ms. Сколько времени из этого занимает https-запрос к старому бекенду за редиректом?
Верно, каждый запрос пользователя посылает запрос на старый backend. Единственное что, первый запрос делается с node.js для того чтобы отработать HTTP status code. Остальные запросы будут уходить с клиента.
Сколько времени занимает https-запрос я сказать не могу, т.к. мы все это кэшируем в CloudFlare, и запрос на прямую не проходит. А он там уже по своему распределяет кэш по миру.
Как результат, яндекс и гугл проиндексировали все страницы, которые предполагались. Сайтик, который строит сайтмап автоматом, тоже без проблем это прожевал.
За основу для прототипа брали вот эту репу github.com/erikras/react-redux-universal-hot-example
А как вы в версии без JS сделали авторизацию?
После недели тестирования трафик на сайт упал на 30%
После отката трафик вернулся?
Тут стоит отметить, что если использовать CNAME записи, то замена сервера произойдет мгновенно. Запись A будет рассасываться по DNS до 48 часов.
С чего бы это? Сколько ни вдумываюсь — не понимаю, в чём эффект: у каждой записи свой TTL (который подействует при следующем обновлении), откуда же у вас уверенность, что CNAME обновляется быстрее?
На сколько показывает моя практика, при использовании cloudflare, CNAME изменения применяются практически мгновенно, по сравнению с ALIAS. При открытой консоли приложения, можно увидеть что пользователи перестают обращаться к сайту.
Если делать тоже самое с ALIAS, при том же TTL, то это занимает какое-то время.
Мы тоже вставляем meta tags динамически через js. Попробуйте рисовать странички быстрее 5 секунд, я думаю это поможет.
У нас все странички рисуются одинаково, разница лишь во времени отрисовки. И какие-то страницы все-таки попали в индекс, во всеми meta tags.
Статья и комментарии кажутся очень любопытными даже спустя год. Расскажите, чем кончилась эта история? И какие лучшие практики для корректного индексирования SPA удалось сформулировать с тех пор? И в общем случае, и в случае конкретно вашей конфигурации?
В конце концов мы добавили Prerender.io, и после того как убедились что трафик идёт как прежде и Гугл индексирует нас — заменили Drupal на nodejs.
К этому времени angularjs 1.6 устарел и мы переписали фронтенд на react.
Затем мы поняли что существует gatsbyjs и заменили REST бэкенд на простую генерацию статики.
Жить стало намного проще и я уволил себя с этой компании и пошёл работать в другую :)
Опыт перехода сайта на Single Page Application с упором на SEO