Вешаем новый сайт на старый домен — как не потерять позиции в CEO?

Question

[ssyukin]

Всем привет! Суть вопроса проста, а решения - нет.
Есть сайт на joomla - простой, не современный и т.п. Домену порядка 5 лет. По данному сайту в поисковой выдаче есть неплохие позиции.
Сделали новый сайт на bitrix с большим каталогом, совсем другой структурой и т.п. (повторить структуру старого было не возможно). Вешать сайт планируем на старый домен.
Какой алгоритм замены сайта будет наименее плачевен с точки зрения потерь в поисковой выдаче?
Были предложения:
- повесить новый сайт на другой домен (созвучный), погонять какое-то время (~пол года), при этом не отключая старый. Затем перенести новый сайт на старый домен.
- повесить новый сайт на старый домен, а старый сайт оставить на поддомене типа "old.site.ru". Но будет ли робот индексировать страницы в выдаче если мы добавляем поддомен?
Оба варианта кажутся бессмысленными, поэтому прошу помощи и совета.
Наверняка тема изъезжена, на всех попытках где-то что-то почитать/узнать ответ один - "потери будут и с этим ничего не сделать, если только не будет 100% совпадение урлов нового и старого сайта". Понимаю что потери будут, но возможно есть способ хоть насколько-то их уменьшить!
Заранее, спасибо!!!

Answer 1

[Виктор Таран]

301 на новые урлы, но потеря будет окол 40% трафика
тут вы ничего не сделаете.
соответственно новая структура сайта войдет в индекс поднимится и через месяца 2 у вас пойдет прирост показателей.

Comments

[Евгений Николаев]

Не знаю о какой просадке 40% трафика Вы говорите, прочитайте мой ответ в частности. Стабильный рост и трафика и позиций по подавляющему числу проектов на всех этапах.

[Виктор Таран]

угу и ни о какой капитализации запроса вы тоже не слышали.

[Евгений Николаев]

Виктор Таран,
>>угу и ни о какой капитализации запроса вы тоже не слышали.

А что Вы конкретно имеете ввиду?

[Виктор Таран]

у вас новое семантическое ядро, а следовательно вы или перенесли контент, или создали новый на старые ключевики. В следствие этого у вас появилось две релевантные страницы
первая у которой уже есть вес, и вторая новая более качественная но без веса, собственно какую из них выдавать в поиск?
https://devaka.ru/articles/cannibalization

Answer 2

[Антон]

Ходили вы в гипермаркет сколько себя помните, знаете где что лежит, все полки\стеллажи всегда на одном месте, а тут бац, пришли, все распихали по новому, где что лежит - непонятно, и вы какое-то время будете гулять, изучать, запоминать, и по началу вас будет трясти, мол, -"какого хрена"?
Вот тут так же.
Единственное, что тут можно сделать, это если страницы на старом сайте отвечают тому же контенту, что и на новом, тогда я бы сделал у инфоблока поле redirect_from, и пихал туда урлы старых страниц, а в самом компоненте проверял эту переменную и редиректил бы с 301 хедером на новый текущий, если кто-то посетил страниц\ урл из redirect_from
Хотя бы сравнить с аналогией выше и повесить на стеллажи бумажки с подсказками (Искали бухлишко? Оно теперь налево через 3 стеллажа)

Comments

[ssyukin]

Антон, спасибо!
И кстати да, я забыл немаловажный момент: страницы со старого сайта на новый мы перенесли практически полной копией (заголовки, текста, цифры и т.п.)

[Антон]

ssyukin, Трясти будет все равно, ничего не поделать

[Одиночка Айс]

Переадресация должна быть в htaccess, а не в коде сайта.

[Антон]

Одиночка Айс, и почему же?

[Одиночка Айс]

Антон, 1. отработает быстрее, 2. не стоит смешивать логику работы сервера и сайта. Понятное дело, что пытаетесь сделать для удобства админа, но так делать не стоит.

[Антон]

Одиночка Айс, Разница во времени будет столь несущественна, и в данном случае, подошло бы больше для какого-нибудь портала а-ля госуслуги, который и так валится от любого чиха.
Ну и, не вижу ничего плохо в том, чтобы засунуть 1 метод или 3 строчки кода, чтобы осуществить сие, как минимум, будет эстетичнее, а не чертова сосиска из правил в htaccess.
Само собой понятно, что как бы нужно отделить мух от котлет, и было бы правильнее, но это не такая большая потеря, и уж тем более - это битрикс, там невозможное возможно, хуже уже и так некуда.

[Евгений Николаев]

Одиночка Айс, 1. не факт что быстрее, чем 5 строчек на php
2. Можно и так и так решить
Удобство админа. 1 фиг через 1-2 месяца удалять эти строчки после реиндексации как не нужные, и тому же админу нужно вспомнить где именно он их прописал(хуже если он уволился и искать другому).

[Одиночка Айс]

Евгений Николаев, неужели? Запустить систему, подключиться к бд, найти нужные страницы и правила. Наверняка еще кучу запросов выполнить придется, прежде чем доберемся до нужных правил редиректа.

[Евгений Николаев]

Одиночка Айс, массив хранится прямо в файле index.php

>>Наверняка еще кучу запросов выполнить придется, прежде чем доберемся до нужных правил редиректа

Если и хранить в базе это целый всего 1 запрос(причём достаточно оптимальный - 1 адрес в условии и 0/1 возвращаемых результатов, а Вы что там на несколько запросов собираетесь хранить?). Но я бы не стал хранить в бд(если только не более 1500 страниц), так как код через несколько месяцев предполагает удаление, а так ещё и из базы таблицу нужно будет удалять

[Одиночка Айс]

Евгений Николаев, то бишь массив забивается руками? 0_о и каким чудом его править клиенту/SEOшнику?

[Евгений Николаев]

Одиночка Айс, никогда не давали эту работу клиенту, это работа по seo которую выполняла наша студия.
Максимум иногда порсили клиента ссылки из индекса собрать, для этого ему нужно было в яндекс найти site:его_адрес_домена и одну за ондной скопировать а потом прислать нам exel таблицу где одна колонка старая ссылка а другая новая ссылка.
Обращаю Ваше внимание мы тогда занимались Joomla и работали с сегментом эконом клиентов, поэтому если клиенту было лень или он что то не понимал, мы выставляли ценник 5000 рублей за эту работу(до 500 страниц) и занимались этим 2-6 часов. А если и это не устраивали, то просто не выполняли seo работу по склейке, и вот уже это не так хорошо было для seo о чём разумеется предупреждали.

В конечном счёте получали массив типа <?php $ar = array(array("old"=>"/stariy_link","new"=>"/noviy_link")); далее $link = false; foreach ($ar as $one) {if ($one["old"] == $_SERVER["REQUEST_URI"]) {$link = $one["new"];}}
if ($link) {здесь_переадресация на $link;exit;}

Всего делов.

Ещё раз обращаю внимание до 1500 ссылок прямо в файл index.php свыше - в таблицу базы, поскольку для файла уже дофига.
Почему 1500? Да не почему, можно и до 500 считать, чисто по ощущениям размер файла уже приличный будет если больше, и зачем всю эту работу давать интерпретатору php по разбору кода если это уже работа для базы. К тому же свыше 1500 ссылок не очень удобно потом всё эту удалять, когда скролом сложно найти конце этой информации.

[Одиночка Айс]

Евгений Николаев, понятно) так исторически сложилось у вас, в общем))

[Евгений Николаев]

Одиночка Айс, :)

Answer 3

[Евгений Николаев]

Здравствуйте!
Проделывал примерно следующее:
вставлял в файл который отвечает за rewrite код в котором:
1)есть массив старых url которые проиндексированы поисковиками
2) есть массив новых url для новой версии сайта
3) если адрес контента на новом сайте совпадает с старым например /contacts/ тогда в массивах эти URi не виксируются
4)Далее проверка если в массиве текущий URL есть (сравнение с $_SERVER["REQUEST_URI"]) тогда переадресация так header("location: /новый_uri",301,true);exit; иначе продолжается загрузка новой cms

В случаи bitrix такой код можно разместить в файлах /bitrix/modules/main/include/prolog_before.php и /bitrix/header.php

Таким образом и пользователи пришедшие из поиска по старым ссылкам попадут на актуальный адрес размещения контента и поисковики поймут где находится теперь контент.
Многократно испытано - позиции как правило только росли.

По поводу нужно ли вешать новый сайт для начала на новый домен: если вы используете значительное число текстов в старого сайта то точно нет. Если проведена полная уникализация - нужно уже по обстоятельствам, возможно даже есть смысл временно оставить старый сайт на поддомене old.domen.ru - но полагаю у Вас как и у всех используются старые тексты, поэтому ответ - на тот же домен.