Да, конечно. Для ПС pdf файл - веб документ и страница сайта - веб документ.
Вбиваете в поиск запрос как реализовать редирект в htaccess и смотрите как это делается.
Нужно всё привести в порядок, потому что уже сами начинают путаться в тех сущностях, которые насоздавали и теперь вынуждены точечно редиректить.
Если изначально всё сделать правильно, ничего не придётся редиректить.
Но могут по незнанию возникнуть, поэтому лучше разобраться и понять, чем не понимать и иметь перспективу всплывающих проблем.
Тогда вполне годится как общность (т.е. как родительский раздел).
rel="canonical" - это уже отдельная тема. Тут может быть множество дополнительных настроек и условий в виде каноникалов и редиректов. Я вам разъясняю общий принцип в реализации структуры т.е. я даю основу и вектор в котором развиваться.
Как и насколько вы можете быть правы в контексте уже заданных условий - это надо более детально погружаться, разбираться, прикидывать варианты, согласовывать, возможно что-то частично переделывать и редиректить - это уже работа и эту работу необходимо делать вам.
В формате форумного ответа я могу только обзорно посмотреть и помощь разобраться в каком отдельном теоретическом вопросе. Его практическое применение может быть весьма многообразно.
Структурно может работать и так как правильно, и так как частично правильно.
Правильно сначала сделать структуру в виде mind карты, затем по ней определить правила URL адресации и сформировать рабочий концепт в котором будет понятно и обосновано, где какие разделы/категории/страницы и какие рабочие сущности за это отвечают.
Когда перед глазами полная картина, вот тогда от общего к частному можно и нужно решать этот вопрос.
А не правильнее ли сделать изначально страницу с конкретной экскурсией так?
https://frenchkiss-events.ru/programmy-18/korolevskiy-shokolad-18/
Если мы рассматриваем данный вопрос в самом общем контексте и вы предлагаете такой вариант, то вы должны четко ответить - уровень /programmmy-18/ - это что за раздел?
Если это общий раздел, то почему в алиасе используется цифра 18?
Если этот уровень определяет признак (а не общность) конкретной страницы (и поэтому там цифра 18-ать), то вам нужно означится тем, а что тогда будет выводить адрес https://frenchkiss-events.ru/programmy-18/ сам по себе и здесь возникает ещё больше вопросов.
Разъясняю на отстранённом примере.
Допустим, вы продаете груши. У вас есть сорта груш, как конечные страницы (именно сорта, а не штуки):
- Виктория
- Видная
- Северянка
Допустим, вы определили и решили, что вам нужно сделать сортировку по цвету плода.
Допустим, Виктория - красный цвет, Видная - желтый, а Северянка может быть и красным и жёлтым.
Так вот, если мы следуем правилу
Получится следующее:
/красные/Виктория
/желтые/Видная
/желтые/Северянка
/красные/Северянка
получается, что в данной логике возникает дубль страницы Северняка, потому что Северняка может давать и красные плоды и желтые. Какую страницу тогда ранжировать?
Как быть, если мы допустим, не может разделить Северянка на раздельные страницы Cеверняка - красные и Северняка - жёлтые?
---
Ответ мы можем создать новую сущность, которая будет объединять все сорта. Назовём её очевидно - груши.
Тогда у нас структура раскладывается в следующую картинку.
/груши/Виктория
/груши/Видная
/груши/Северняка
и в разделы /красные/ и /желтые/ мы лишь вкладываем ссылки, которые ведут на общий раздел груши.
т.е.
/красные/ -> /груши/Виктория, /груши/Северняка
/желтые/ -> /груши/Видная, /груши/Северняка
Тогда дубля не будет.
Снова возвращаемся к рекомендации Яндекса,
И мы ему полностью удовлетворяем, потому что у всех сортов будет общий раздел Груша.
Является ли логически сорт дочерним элементом общей раздела Груша? Да, является. Значит название общего раздела найдено удачно.
Задача решена.
Так и с остальными структурами сайта - определяем логически принадлежности, формируем общности и выстраиваем структуру так, чтобы она функционально решали подобные задачи. Было чётко, обоснованно и не формировало дубли.
Да, я обратил внимание на эту особенность, это значит как такового рабочего кластера для https://frenchkiss-events.ru/programm/ не будет и данный уровень будет не более, чем служебной сущностью.
Для людей делайте
В данном случае - это лучше, чем 404 и лучше, чем два адреса с пересекающейся релевантностью.
Это верно. Но нас чаще всего интересует главным образом реакция Метрики.
И если, скажем, в первые 15 секунд совершаются целевые действия и Метрики их фиксирует как неотказ, то субъективное мнение отдельно вебмастера здесь уже не играет роли. Словом, мы в контексте того, то именно Метрика считает неотказом, а вебмастер воспринимает это как неотвратимую данность.
Т.е. таким образом можно определить (т.е. программно реализовать) условия, чтобы скролинг до конца страницы не считался отказом?
Спасибо! Это важная и очень полезная подробность. Благодарю за информацию.
Очень интересная подробность.
Роман, такой вопрос. А зачем в инструментах API давать вебмастерам возможность искусственно влиять на данный статус?
Ведь это прямое указание на то, как этим можно манипулировать.
Не должна ли система сама определять ценность посещения, исходя из содержания пользовательских действий?
Если вы хотите накапливать у себя явные маркеры неестественной накрутки, то можете не имитировать.
Эффективный смысл накрутки в том, чтобы имитировать подобие естественных заходов, а в естественной среде заходы многообразны.
Сделали сайт https://frenchkiss-events.ru/ . Правильная ли структура страниц?
Программы ведут на https://frenchkiss-events.ru/programms/, а конкретная на https://frenchkiss-events.ru/programm/korolevskiy-shokolad-18/
то есть страница с programmS, а другая с programm
Это на первый взгляд может показаться неправильным, но на самом деле в этом есть свой смысл.
Programms и programm - это разные сущности с разными задачами.
Programms - родительский раздел категорий.
programm - родительский раздел конкретных страниц.
Конкретные страницы вложены в programm на случаи, если конкретная страница может быть представлена одновременно в нескольких категориях (такое бывает).
Но я бы сущность 'programm' назвал лучше 'excursion' (экскурсия) и все конкретные страницы вкладывал в этот раздел.
Тогда не было бы пересечений и встречающихся дублей, как здесь
https://frenchkiss-events.ru/programm/programma-villivonka/
Было бы
https://frenchkiss-events.ru/excursion/programma-villivonka
либо
https://frenchkiss-events.ru/excursion/villivonka
если вам в url-е не нужно словно programma.
В итоге все 600 переходов будут отфильтрованы Яндексом по поведенческому признаку.
Вопрос - в знании как это правильно сделать.
Купить софт, прокси, настроить сервер и даже реализовать шаблон по ТЗ для выбранного ПО - это копейки по сравнению с тем, сколько нужно вложить в наработку того, чтобы это давало нужный эффект.
Главные затраты уйдут в многочисленные рабочие итерации (обучение, эксперименты, смену подрядчиков для изготовления и поддержку шаблона, платные консультации и т.д.) когда вы как жемчуг будете намывать необходимые для работы данные и решения. Закладывайте как минимум пол года на этот процесс.
Эта тема наскоком не берется.
