Для описаний товаров:
1. Логично сделать вывод свойств по группам (см карточку товара в маркете)
2. Сделать группы макросов, которые на основе типовых свойств (обычно для разных категорий сеты этих свойств разные) с простейшей логикой статейных генераторов для генерации описания товара на момент его добавления а базу ИМ (само собой с проверкой уника в рамках бд магазина)
Само собой, это описание формируется и вставляется в карточку только в случае, если у товара описания нет, либо оно короче какого-то минимума (этот лимит Вы сами для себя определите) - тогда имеющийся текст можно надстроить сгенерированным.
Естественно, формируя макросы, надо постараться предусмотреть, чтобы результат их работы был читаемым, а не УГ :))) это зависит от пользователя, а не от инструмента, посему сразу отвергать по причине автогенерации - в корне не верно, ибо сама по себе автогенерация вреда не несет, только от рук все зависит
Headless browser ссылки не кликает обычно, слишком ресурсоемко писать такой скрипт и не требуется => нет никакой зависимости, как закрывать блоки, и раскрываются они или нет.
Сокрытие через css display:none вреда не принесет. Только что Гугл грозится такой текст игнорить. Но это и логично.
Хотя в свете mobile-first index часть контента в космос.
Если мучает паранойя - разводите сайты на разные версии и админьте параллельно. Как разные сайты. Но опять же для Гугла минус часть контента.
Лучше проработайте структуру так, чтобы контентных блоков, которые надо прятать - просто не было. А технические (доп навигация и т.п.) - ну и пусть игнорятся, прячьте их спокойно.---------- Добавлено 26.08.2018 в 00:13 ----------postavkin, про css flexbox слышали? Это чтоб ваши теги шли по коду и в адаптиве «взаде», а на десктопе «впереде», так сказать... 2018 год на дворе, а вы все творите сайты на технологиях 10летней давности...---------- Добавлено 26.08.2018 в 00:17 ----------Апокалипсис не прав в том, что js в нормальной ситуации должен срабатывать после First draw, что бне быть совсем Render blocking, а в этом случае у мобильного юзера на глазах страница будет биться в конвульсиях, перестраиваясь по мере выполнения js. Хорошо ли это? Однозначно нет. И да, не у всех флагманские модели смартфонов, имеет права браузер на мобиле и потупить.
Ответ для ТС
Идея делать ВСЕ ссылки через редирект - откровенно плохая. Это как минимум частичная потеря link juice
Вам бы сделать механизм, чтобы :
1. при смене url целевого урл его старый адрес сохранялся в базе роутинга, в паре с новым урл
2. Эта же база проверялась на другие url, у которых уже конечным был старый урл и в них конечный урл обновлялся на новый актуальный
3. Крон-скрипт пробегал все таблицы сайта, где есть урлы (таблицы меню, контента с перелинковкой в html и т.п.) и обновлял старый урл на новый
4. Готовил вам отчет с рекомендацией подать на Переобход (Яндекс) и на Fetch as Google всех затронутых страниц/урлов. Для ускорения учета. Ну либо хотя бы подать туда старый и новый урлы как минимальное воздействие.
Может стоит посмотреть в сторону организации навигации ? Что у доров она проще и сконцентрирована вокруг продвигаемых терминов, без распыления смысла? И грузятся эти доры скорее всего быстро через headless browser, в отличие от сложных отягощенных js’ом и стилями сайтов
Гугл говорит не об ответе сервера, а о блокировке доступа к файлам или папкам, их содержащим, например, через robots.txt или по user-agent / ip в htaccess например
Ответ сервера 304 (файл не изменен) интерпретируется браузером как команда взять файл из локального кеша. Бот это не использует и прогружает все, до чего ему разрешено доступаться.
Например, некоторые cdn могут лочить доступ к файлам сами по себе для некоторых вариантов проксирования страниц
Не нужно делать мобильную версию, нужно делать адаптивный сайт через css only решения. По мнению google.
Но есть условие - по потоку html кода до вызова библиотеки jquery никаких скриптов с использованием jquery быть не должно. Лучше всего весь код даже самый локальный - вынести в один файл отдельный с вызовом по контексту и подключать его в подвале перед </body> после библиотеки jquery и других подключаемых библиотек (хотя их, если не с CDN - тоже лучше включить минифайенными в свой файл в начало)
Ну и вызовы всего js должны идти уже после DomContentLoaded события. Иначе матюки останутся...
Это и к вопросу Skf относится - делайте onload-обертки с отложенной загрузкой некритичных внешних скриптов (lazyload)
А вы подумайте хорошенько, как еще они (вктрэкер) могут получить данные о пользователе (чисто технологически, с учетом недоступности кук одного сайта другому сайту).
Ооо продвижение годы назад тоже рассказывало.
Для директного лендоса (где на позиции заведомо пофиг) использовать можно. Для сайта под поисковый трафик - слать подальше. Ибо слушать продажников - кто ж вам правду то скажет?!
Сам Гугль продвигал в свое время boilerplate removal алгоритм (автор вроде работает на них теперь), одной из частей которого является выявление и отбрасывание последовательностей ссылок (читай - элементов навигации) для дальнейшей работы с «очищенным» основным контентом.
Насколько этот алго реально используется - не известно, но в инете вайтпейперов и реализаций пруд пруди разных. Так что точно можно сказать, что отличить нафигацию от основного контента даже без семантической разметки поисковики способны и скорее всего как минимум могут присваивать разную весовку, в том числе делегируемую, разным частям страниц.
Есть такие понятия, как critical path css (минимально необходимый набор css для отображения конкретной страницы, чтобы избежать fouc), которые можно и заинлайнить; корректная последовательность инициации js (чтобы была возможность унести их в подвал), а плагиныеще и смерждить или грузить с cdn. На github много разного на эту тему, но везде нужен рашпиль...
Это конечно работа квалифицированного специалиста.
В этом случае и gps не фырчит, и сайт реально отрисовывается быстрее, что на пф должно сказаться позитивно.
Не пробовал плагина этого к wp, про него ничего не скажу.
