Comments 9
… или взять next.js и иметь все это из коробки
Next.js я упомянул в материале. Да, он бы тоже подошел. Но он много чего навязывает в архитектуру проекта. Не показался достаточно удобным. С его интеграцией в проект, нужно было бы переписать куда больше кода. Next больше подходит для написания проекта с нуля. Но даже тогда, я бы воздержался скорее всего, так как хотелось получить гибкий инструмент не влияющий на архитектуру, так как «сегодня» это может быть ReactSnap или Next.js, а «завтра» появится еще что то кардинально новое и еще более удачное и удобное. И при использовании ReactSnap «сегодня» мы «завтра» абсолютно спокойно готовы переехать на что то иное, без переписывания кода со старого подхода на новый из за отдельного инструмента (тем более когда это касается только SEO, было бы печально что то кардинально переписывать..). Одним словом, в какой то мере это возможно конечно дело вкуса, но всё же хотелось учесть и вышеописанное.
В качестве бэкенда используется Magento2 также как и в некоторых других проектах Россельхозбанка?
Как заставить контент вашего Single Page Application работать на вас в поисковых выдачах и приносить клиентов?
Необходимо
- SPA — вконце не зря слово application/приложение. Т.е. уместно на этой технологии делать странички (или div-обёртки) где будет происходить непосредственно взаимодействие юзера с вашим продуктом, где есть богатый UI-функционал. Например, онлайн-фотошопы, олайн эксель-таблицы, всякие софт-фоны, игры, конструкторы, личные кабинеты, дашборды, монстро-формы, формы-визарды, сложный блок фильтров и т.д.
- Там где ценность — это контент (лендинги, карточка товара, блоги) — уместно делать эти странички статическими или генерируемыми на сервере. И дальше уже затачивать их под seo, и продвигать максимально.
Так вот, приложения и не должны быть seo-френдли или индексироваться. Это не их задача. На них как раз должны редиректить обычные контентные seo-френдли странички с кнопками/ссылками типа «войти», «калькулятор», «подать заявку», «запустить» и т.п.
Что же делать, если у Вас уже есть готовый SPA, либо просто отточенный архитектурный подход, нарушать который ради SEO было бы кощунством?
Сделать главную страничку (или несколько) по старинке, чтоб отдавалась с сервера. Её затачивать под seo. А на ней все эти кнопки\ссылки которые будут редиректить каждая на свой SPA, или на конкретный раздел в SPA, или на крайний случай запускать div-попап в котором этот SPA.
Добрый день.
Благодарю за подробное изложение подхода. Не могу с ним не согласиться так как он пока еще достаточно часто имеет место на многих интернет-ресурсах. Но в нашем случае под приложением понимается весь сайт целиком. Весь интерфейс включая главное меню, навигацию по всем страницам и так далее. У нас приложение — это не набор форм, которые можно вынести в отдельный блок или попап. И пытаться разделять тут ценность на контент и юзабилити-функционал, будет некорректно.
То, как разработан наш сайт — это современный и ныне распространенный подход реализации интернет-ресурсов несомненными плюсами которого являются: общая кодовая база для всех частей интерфейса (фронтенд), будь то форма или страница, общий подход к построению и навигации по интерфейсу, максимально возможная гибкость настройки любой из частей интерфейса (так как всем в итоге управляет react, без каких либо дополнительных разделений зон ответственности), жёсткое архитектурное разделение того за что отвечает фронтенд, а за что бекенд, и много чего еще.
Соответственно минусами представленного вами подхода будет как раз то самое разделение фронтенда на части, что повлечет за собой крайне заметную фрагментацию в процессах анализа, разработки и поддержки проекта (ну и конечно фрагментацию самой кодовой базы проекта).
В нашем случае нам куда проще описать, к примеру, ту же главную страничку, как часть общего интерфейса и именно в таком формате и осуществлять её поддержку, нежели выносить точечно её (и не только) за пределы общего интерфейса со всеми вытекающими.
И предложенный вами способ и наш текущий (если мы всё-таки ведем речь именно о spa-сайте), на самом деле в конечном счёте являются лишь необходимой мерой для корректной индексации. Но при этом, опять же оговорюсь, что, когда (если) поисковые роботы научатся корректно индексировать js, мы в нашем проекте просто исключим последний шаг сборки (пререндер) продакшн версии приложения (и пару условных переменных из кода). Это всё что нужно будет сделать для отказа от этой необходимой для SEO меры. Любые иные способы реализации SEO и инструменты, потянут за собой необходимость проведения куда большего объёма работ.
Сейчас у себя мы имеем хорошо проработанный отточенный и понятный процесс ведения разработки. Бекенд-разработчики делают необходимый серверный функционал и предоставляют фронтенд-разработчикам к нему доступ через API, фронтенд-разработчики реализуют на react интерфейс и клиентский функционал сайта используя предоставленный им функционал API. У фронтенд-разработчика не когда не возникнет кейса, при котором ему придется идти в какой-либо html-шаблон бекенда на веб сервере или что-то подобное, чтоб поправить что-то на какой-либо вынесенной за пределы приложения странице (так же как и бекендеру не когда не придется думать о подобном). И это просто отлично. Каждый занять исключительно своим делом на своем языке программирования в своем фреймворке в сугубо своей зоне ответственности.
Благодарю за подробное изложение подхода. Не могу с ним не согласиться так как он пока еще достаточно часто имеет место на многих интернет-ресурсах. Но в нашем случае под приложением понимается весь сайт целиком. Весь интерфейс включая главное меню, навигацию по всем страницам и так далее. У нас приложение — это не набор форм, которые можно вынести в отдельный блок или попап. И пытаться разделять тут ценность на контент и юзабилити-функционал, будет некорректно.
То, как разработан наш сайт — это современный и ныне распространенный подход реализации интернет-ресурсов несомненными плюсами которого являются: общая кодовая база для всех частей интерфейса (фронтенд), будь то форма или страница, общий подход к построению и навигации по интерфейсу, максимально возможная гибкость настройки любой из частей интерфейса (так как всем в итоге управляет react, без каких либо дополнительных разделений зон ответственности), жёсткое архитектурное разделение того за что отвечает фронтенд, а за что бекенд, и много чего еще.
Соответственно минусами представленного вами подхода будет как раз то самое разделение фронтенда на части, что повлечет за собой крайне заметную фрагментацию в процессах анализа, разработки и поддержки проекта (ну и конечно фрагментацию самой кодовой базы проекта).
В нашем случае нам куда проще описать, к примеру, ту же главную страничку, как часть общего интерфейса и именно в таком формате и осуществлять её поддержку, нежели выносить точечно её (и не только) за пределы общего интерфейса со всеми вытекающими.
И предложенный вами способ и наш текущий (если мы всё-таки ведем речь именно о spa-сайте), на самом деле в конечном счёте являются лишь необходимой мерой для корректной индексации. Но при этом, опять же оговорюсь, что, когда (если) поисковые роботы научатся корректно индексировать js, мы в нашем проекте просто исключим последний шаг сборки (пререндер) продакшн версии приложения (и пару условных переменных из кода). Это всё что нужно будет сделать для отказа от этой необходимой для SEO меры. Любые иные способы реализации SEO и инструменты, потянут за собой необходимость проведения куда большего объёма работ.
Сейчас у себя мы имеем хорошо проработанный отточенный и понятный процесс ведения разработки. Бекенд-разработчики делают необходимый серверный функционал и предоставляют фронтенд-разработчикам к нему доступ через API, фронтенд-разработчики реализуют на react интерфейс и клиентский функционал сайта используя предоставленный им функционал API. У фронтенд-разработчика не когда не возникнет кейса, при котором ему придется идти в какой-либо html-шаблон бекенда на веб сервере или что-то подобное, чтоб поправить что-то на какой-либо вынесенной за пределы приложения странице (так же как и бекендеру не когда не придется думать о подобном). И это просто отлично. Каждый занять исключительно своим делом на своем языке программирования в своем фреймворке в сугубо своей зоне ответственности.
Sign up to leave a comment.
SEO-оптимизация сайта на React или как добиться конверсии от поисковиков если у вас Single Page Application