yvcom, тема в разделе Гугла, при чем тут Яндекс и noindex?
Если это саджест поисковый, скрипт его генерящий живет в отдельной папке, закрытой в robots - вообще не повлияет.
Гугл не поймет. Для убирания этого хвоста в том же Yoast SEO не зря реализована отдельная опция вычищенияиз индекса подобных страниц.
Поиск битых ссылок - любым внешним софтом. Для Мака Screaming Frog, если поискать, есть куча онлайн сервисов, для Винды можно найти старый Netpeak Spider.
Для проверки текста на вменяемость есть тот же ашмановский Тургенев - онлайн сервис.
Yoast SEO - комбайн, отвечающий за все аспекты
Увы, ТЗ класса «сделайте хорошо» в 99.99% случаев до результата не доводит. Разрабов очень много, толковых единицы.
Для описаний товаров:
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.
