Разрабам
Делать сайты надо на том, на чем умеешь, что досконально знаешь.
Желательно не быть «морской свинкой» (программист Битрикс, программист Вордпресс - держите меня, это что, языки программирования такие???)
Клиенту-владельцу бизнеса
Делать надо на основании «минимум затрат к максимуму результата» (только как пропорция)
Если сео контора не смогла продаинуть сайт на ВП - значит там нет ни одного вменяемого php программиста, либо ни одного разбирающегося в технология проджекта с навыками минимального QA и в кворке их забанили.
Раз не нашли способа допилить сайт, если это конечно ДЕЙСТВИТЕЛЬНО было нужно, а не провал продвижения крылся в чем то другом. А платформа сошла за отмазу.
А значит в современных реалиях это не seo компания, а очередной разводняк.
Повторюсь, если есть нормальный знающий разработчик, дальше важна только технологическая база платформы (цмс, фреймворка), а не конкретное название. Остальное решается головой и гуглом. Если и там не забанили.
Вот я не знаю вообще Питон - за сайты на Джанго и не буду браться. Это логично.
Но и Битрикс с его логикой, помойкой в коде и файловой структуре и никому не нужными наворотами и сообществом, состоящим в основном из полуграмотных, но крайне самолюбивых граждан «программистов 1С» связываться не буду. Ни как разработчик, ни как сеошник, ни как проджект. Ну эту помойку нафиг.
postavkin, ну закрытие может и не помогает, соглашусь. Хотя и не всегда.
Но если в JS будет НОРМАЛЬНО сделанный скрипт - то есть не document.write и без влобовую прописанных url страниц, а они будут хотя бы собираться по частям - тогда все в порядке будет.
Из того, что Гугл "находит" путем "анализа" страниц - это по паттерну "похожие на url" подстроки из js, css, html сайта. Данные свежестью месяца два-три - в рамках текущего разрабатываемого проекта много раз наблюдал такие косяки индексации в аналитике. Пока интересно было и мы не пофиксили попадание такой фигни в аналитику.
Lighthouse и headless браузеры - это круто конечно, но жесть как ресурсоемко. Так что про полный рендеринг страниц ботом гугла можно не напрягаться.
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’ом и стилями сайтов
