- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу

Что делать, если ваша email-рассылка попала в спам
10 распространенных причин и решений
Екатерина Ткаченко
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Внедряем на сайте фильтры для товаров, но возник спор относительно правильности расположения страниц - результатов поиска.
В данный момент выбираем между:
1 - все результаты в папке "search", она скрыта от индексации в robots. Пример "/search/?filter=312;318;824".
2 - при выборе фильтра "цвет, размер, форма, стиль .. " пользователь переходит на страницу, урл который совпадает с урлом основной посадочной страницы + выбранные фильтры. Пример "/postelnoe-belje/iz-hlopka?filter=312;318;824". С этой страницы, естесственно, meta rel canonical на "/postelnoe-belje/iz-hlopka"
Второй вариант выглядит интереснее, но смущает тупость Яндекса, который может решить, что эти стриницы - дубли.
И самое важное! Даст ли плюс по ПФ категории "/postelnoe-belje/iz-hlopka" хождения по урлам вида "/postelnoe-belje/iz-hlopka?filter=312;318;824" по сравнению с вариантом хождения в папке "search"?
Можете посоветовать как бы Вы сделали и почему?
Здесь сразу важно принципиально отличать два понятия:
1) Целевые страницы (как элементы структуры) которые могут быть заданы комбинациями свойств категории/товара.
2) Пользовательские фильтры образованные либо контекстным поиском, либо опционально (с помощью переключателей) в режиме пользовательских сессий.
Так вот, 2-ой вариант, который может формироваться многообразием пользовательского выбора - эти страницы всегда нужно запрещать и для индексации, и для обхода. Canonical к ним конечно прописать можно, но бессмысленно, если мы их исключаем из зоны внимания поисковых роботов.
Второй вариант выглядит интереснее, но смущает тупость Яндекса, который может решить, что эти стриницы - дубли.
Если вы оставите открытыми для индексации, то это будут дубли. Помним, что canonical - это лишь рекомендация, а не строгая инструкция, поэтому надеяться на то, что Яндекс всё правильно поймет - не стоит.
И самое важное! Даст ли плюс по ПФ категории "/postelnoe-belje/iz-hlopka" хождения по урлам вида "/postelnoe-belje/iz-hlopka?filter=312;318;824" по сравнению с вариантом хождения в папке "search"?
В данной логике - да, даст, ибо сигналы буду накапливаться на текущем адресе, таким образом вы будут дифференцировать позитивные сигналы по всему рабочему кластеру, а не сваливать всё в /search/.
даже если в robots закроем фрагмент "?filter="?
1) Целевые страницы (как элементы структуры) которые могут быть заданы комбинациями свойств категории/товара.
даже если в robots закроем фрагмент "?filter="?
robots запрещает индексацию, но не блокирует учёт пользовательских действий - эту разницу также важно хорошо понимать.
Вопрос лишь по комбинации фильтров, по которым не стоит делать отдельную посадочную.
Вот их в индекс не нужно тащить ни под каким соусом, ибо это всё равно нечёткие дубли составленные из комбинированной информации Яндекс наверняка выплюнет их из индекса.
Если вы оставите открытыми для индексации, то это будут дубли
1. Это не будут дубли ни логически, ни контентно... и даже (ненужный и вредный в контексте задачи) canonical c 99% вероятности будет Яндексом пригнорирован, потому что контентно страица фильтра на категорию и нефильтра - разные
2. Закрывать страницы фильтров от индексации - идеологически неправильно, если на них есть запосы с ненулевым спросом
Второй вариант выглядит интереснее
"Оба хуже!" (с). Самым нормальным (и требующим отдельного внимания и труда) будет вариант "2+", в котором
- всем страницам фильтров даны вменяемые и уникальные мета (ну и текст на странице - желательно)
- страницы фильтров с ненулевыми запросами на них (естественно) индексируются и имеют постоянный, не меняющийся от погоды на Марсе URL (без цифровых иднтификаторов параметров фильтра, которые могут меняться в процессе жизни), при этом формат URL в общем-то неважен, и /search/?filter= и /postelnoe-belje/iz-hlopka?filter= не принципиальны ни для людей ни для ПС (кроме момента, справедливо выше отмеченного Антонием).
Но я, по привычке "подстелить соломки от альтернативно-одаренных", избавился бы вообще в URL индексируемых (читать "нужных для бизнеса") фильтов от GET-параметров, чтобы избежать последствий от действий идиота, которы не глядя засунет в robots Disallow: /?. В битриксе, скажем, к их фильтрам есть пожелания всякие, но вот URL делают почти хорошо: просто непараметризованный URL, только к длине есть претензии, если параметров реально много
2. Закрывать страницы фильтров от индексации - идеологически неправильно, если на них есть запосы с ненулевым спросом
Нет на них никаких запросов, это адреса сформированные последовательностью пользовательского фильтра.
- всем страницам фильтров даны вменяемые и уникальные мета (ну и текст на странице - желательно)
По-моему ты не понимаешь о чём идёт речь, либо о чём-то другом. Когда пользователь составляет наборные свойства в фильтре - это может быть превеликое множество адресов в сессии.
Может быть так:
?filter=312;318;824
а может быть так:
?filter= 318;312;824
а может так:
?filter= 318;824;312
где переменные в фильтре могут указывать лишь на порядковый выбор в переключателях, а результат выдачи может быть даже тот же самый. НЕчего подобным страницам делать в индексе.
Никакие уникальные мета там ловить не нужно, и уж тем более тексты. Это не страницы, это лишь рабочий эпизод, где будут выводиться наборные комбинации из товаров, которые есть в базе.
Нет на них никаких запросов, это адреса сформированные последовательностью пользовательского фильтра.
Не, не поругаемся. Прям таки уверен, что на них нет запросов? Я не видел структуру фильтров пациента, но более чем уверен, что цвет-страна происхождения-размер там есть
Может быть так:
?filter=312;318;824
а может быть так:
?filter= 318;312;824
а может так:
?filter= 318;824;312
А это уже вопрос к разработчикам, не понимать разницу между комбинациями и сочетаниями и не проводить нормирование данных - это сигнальчик
Это не страницы, это лишь рабочий эпизод, где будут выводиться наборные комбинации из товаров, которые есть в базе
Это срез товарной матрицы, который может иметь физический смысл (не видя параметов, точнее сказать не могу)... хотя есть вероятность, что в фильтре действительно бессмысленные параметры. но тут вопрос - а нужен ли такой фильтр вообще?