Это была тема, которая возникла в центре общения веб-мастеров Google, когда кто-то задал следующий вопрос:
“Каково будет влияние, если A /B-тест выполняется во время запуска крупномасштабной миграции URL-адресов? Все старые URL-адреса должным образом перенаправляются на новые URL-адреса 301, но Googlebot иногда перенаправляется на тестовые URL-адреса во время миграции.… может ли это повлиять на то, как передаются сигналы, и потенциально увеличить время, в течение которого сайт видит волатильность?”Мюллеру было что сказать в ответ на этот вопрос, дав гораздо более пространный ответ, чем он обычно делает на подобных тусовках.
По словам Мюллера, лучше воздержаться от проведения больших наборов A/B-тестов во время миграции сайта.
Во время миграции сайта Google попытается понять, какова общая картина с веб-сайтом.
Чем лучше Google сможет понять, что происходит с сайтом, тем проще будет перенести все алгоритмические сигналы со старого сайта на новый.
Если во время миграции сайта выполняется “необычный” A / B-тест, то Google потребуется больше времени, чтобы понять, что происходит.
Мюллер настоятельно советует владельцам сайтов предоставлять как можно более чистый сигнал во время миграции сайта.
В частности, он рекомендует проверить следующие вещи:
- Убедитесь, что все URL-адреса со старого сайта перенаправляются на новую версию.
- Убедитесь, что нет ошибок обхода URL-адресов, которые должны быть доступны.
- У вас нет ничего заблокированного robots.txt это не было заблокировано robots.txt раньше.
- Все это поможет обеспечить сигналы, необходимые Google для эффективной обработки миграции сайта.
Еще раз — дайте четкий сигнал о том, что вы совершаете простой переход с одной версии сайта на другую. В противном случае обработка займет намного больше времени.
Ниже вы можете ознакомится с текстовой версий ответа Мюллера.
“Я не знаю, вызовет ли это большие проблемы в общей картине. Обычно, когда вы проводите A / B-тестирование, это небольшая группа URL-адресов внутри веб-сайта, это не значит, что все URL-адреса вашего веб-сайта выполняют это A / B-тестирование, где иногда мы видим один URL, а иногда нас перенаправляют на другой.
Для небольших наборов URL-адресов я не вижу в этом проблемы. Для больших наборов A / B тестов я бы постарался свести это к минимуму, насколько это возможно. Причина в том, что, особенно при миграции сайтов, когда вы переходите на другой домен, когда вы меняетесь в пределах того же домена, когда вы переходите на HTTPS, с помощью этих вещей мы пытаемся понять, какова общая картина с веб-сайтом.
Перемещается ли веб-сайт с одного домена на другой? Например, веб-сайт переходит на Битрикс. И чем яснее мы сможем получить представление о том, что здесь на самом деле происходит, тем яснее мы сможем применить своего рода алгоритм для перемещения всех сигналов, которые у нас есть с этого веб-сайта, на новую версию этого веб-сайта.
Итак, если во время миграции сайта вы проводите какое-то необычное A/B-тестирование, и иногда мы видим перенаправления в одном направлении, а иногда мы видим перенаправления при миграции сайта, то это, безусловно, может сбить нас с толку и может задержать общий переход с одной версии на другую.
Поэтому, особенно когда дело доходит до миграции сайта, чем чище вы сможете это настроить, тем больше вы сможете убедиться, что все URL-адреса перенаправляются на новую версию, что у вас нет ошибок обхода с URL-адресов, которые должны быть доступны, что у вас нет вещей, заблокированных robots.txt которые не были заблокированы по robots.txt раньше, все эти вещи.
Чем чище вы сможете сделать, тем больше вероятность, что мы сможем сказать: “О, очевидно, что это переход отсюда сюда, поэтому нам даже не нужно беспокоиться обо всех деталях, мы можем просто все перетасовать”.
В то время как если мы посмотрим на это и скажем: “Ну, может быть, это ход, или, может быть, они делают что-то необычное, может быть, нам следует потратить немного больше времени, чтобы выяснить, что именно здесь происходит”. Это может в конечном итоге привести к тому, что миграция сайта займет значительно больше времени, чем это действительно необходимо”.
Услуги WRP по переносу сайтов на HTTPS
- Подобрать SSL-сертификат, соответствующий потребностям вашего бизнеса;
- Помочь получить сертификат: организовать переписку с центрами сертификации, подготовить CSR-файлы с «анкетными данными» вашей компании;
- Установить SSL-сертификат на ваш сервер;
- Настроить ваш сервер для работы по протоколу HTTPS;
- Протестировать ваш сайт, выявить и устранить небезопасные элементы;
- Оповестить о переходе вашего сайта на HTTPS поисковые системы Google и Яндекс в панелях управления Google Search Console и Яндекс Вебмастер;
- Настроить переадресацию с HTTP на HTTPS-версию сайта;
- Помогать консультациями в ходе переноса и в течение 1 месяца после него.
Работы по переносу потребуют от 1 до 3 дней чистого времени. Их стоимость составит не менее 15 000 рублей.
Компания «WRP». Золотой сертифицированный партнер 1С-Битрикс с подтвержденными компетенциями «Композитный сайт», «Коробочная версия», «Интеграция с 1С». С 2006 года «WRP» внедрила более 200 проектов.
Откладывая перенос сайта на HTTPS, вы каждый день теряете покупателей. Закажите перенос сейчас!
