О гарантиях конечно речь не идёт, любые значимые изменения всегда риск. Другое дело, что задачу всё равно решать надо.
Я бы на начала параллельно развивать два сайта, и склейку выполнял уже тогда, когда новый сайт с целевым адресом появится в зоне хотя бы TOP20.
А под обратной отклейкой ты что имеешь ввиду?
Понятно, тогда создавайте второй сайт и оформляйте его под услугу изготовления и установок решеток на окна.
Результаты "топа" на второй сайт в чистом виде вы не перенесете, но склеив 301-ым редиректом релевантную страницу с новым сайтом, вы значимо поможете ему в продвижении.
В названии домена лучше использовать не конкретный вид товара/услуги (ситуация может поменять и вы возможно вновь захотите поменять профиль), а названии фирмы/компании/вашего имени (если вы - частник) - в этом случае вы сможете свободно менять содержание сайта, сохраняя хостовые хар-ки.
Смотрите, определяющий момент. Сам по себе "вес" и релевантность страницы в отрыве от домена не работает. Т.е. нельзя перенести результативность одной страницы на страницу другого домена и сохранить при этом текущую результативность.
В вашем случае вы будете работать с двумя сайтами, поэтому ваша задача вывести второй в топ за счёт ресурсов первого.
Ну как же нет, TC занимался изготовлением и установкой заборов, а теперь сменил профиль на оконные решетки.
С новым сайтом на новом домене сохранить топ вряд ли получится, даже если TC переклеить текущий топовый адрес с соответствующей страницей на новом домене.
Я неслучайно спросил про регион, если регион без сильных конкурентов, возможно TC сможет также самостоятельно справиться с топом и на новом сайте, но здесь всё равно нужно время.
В общем, да, коллеги наверняка есть и заказы можно передаваться, если они конечно не персональные.
Примерно так, только позиции по заборам TC уже не интересны, насколько я понимаю.
Но нужно уточнять какие у него планы на старый сайт по заборам, если его можно целиком и поадресно склеить с новым, то рабочая схема вырисовывается вполне конкретно. Если же будут работать два сайта, то тут больше вариантов.
Контент, расширение семантики, добавление новых кластеров, проработка коммерческих и поведенческих факторов, проработка CJM, работа с конверсионностью, работа с пользовательским фитбэком, ссылочное, работа со сниппетами и т.д.
Вов, похоже ты пропустил,
Топ региональный?
от части услуг я хотел бы отказаться,
но при этом логично было бы сменить домен, т.к. изначально я занимался заборами, и домен взял созвучный с заборами
Здесь важен принципиальный вопрос - старый с частью услуг по заборам вы оставляете в доступном для пользователей виде или целиком можно склеить с новым по решёткам, отбросив ненужное?
Совершенно верно, здесь надо также понимать, что поисковый робот для себя очищает содержание страницы от ненужной для него разметки и работает непосредственно с содержимым. Варианты <br> или <br />, а также степень влияния предупреждений на подобные ошибки в W3C индексирующему роботу глубокого безразличны.
Так что код страницы нужно конечно стараться делать чистым, но измененные правила W3C относительно отдельного синтаксиса уже точно не влияют на ранжирование, поэтому уделять такое пристальное внимание этой проблеме я бы не стал. Всегда есть куда более приоритетная очередь рабочих задач.
Поголовно - вряд ли. Есть перфекционисты, есть убеждённые ревнители кода, есть те, кто уверен, что это очень важно для ранжирования. Опять-таки, вот есть вы :)
Дело в том, что если бы этот фактор был значимым, мы бы видели чёткую статистическую корреляцию c ранжированием, однако в действительности этого не происходит, мы видим, что сайты с погрешностями в валидаторе вполне успешно (при прочих конкурентных достоинствах) занимают топы и недостатки в w3c валидаторе им не мешают.
И снова здесь не соглашусь. Метрики Web Core Vitals хоть хоть и не оправдывают себя с точки зрения какого-то точечного перфекционизма, но тем не менее, если загрузка страницы реально долгая и создаёт ощутимый дискомфорт для пользователя, пользователь в свою очередь испытывает раздражение и перестаёт пользоваться сайтов, то здесь систематические отказы и несут и прямые убытки в трафике, и в последующем влияют на ранжирование.
Так что я придерживаюсь позиции - есть значимые проблемы WCV, а есть нюансы, которыми вполне можно пренебречь.
Увы, но нет. Я сам морально за чистоту кода :) но значимого влияния это, увы, не оказывает.
Не стоит тратиться. Лучше проверьте следующим образом. Возьмите какой-нибудь небольшой город, например, Тула.
Составьте список из 20-30 коммерческих тематик. Cпарсите (или перенесите вручную) все 30-ать. Последовательно проведите валидацию. Уверен, от 80% и выше сайтов будут содержать ошибки по валидации.
Соглашусь. Чистый код - это хорошо и его надо исправлять в случае ошибок, но в моей практике также не было случаев, чтобы эти изменения давали какие-то значимые улучшения в ранжировании.
Поэтому эти задачи я отношу к 80% работ по правилам Парето.
