Перемещение страницы в WordPress — контрольный список

В этом году я перестраивал один из контент-сайтов на WordPress. Не считая ошибок Google, которые появлялись в течение некоторого времени (например, те, из-за которых некоторые из подстраниц полностью исчезли в Google), не было никаких падений в позиции и того же органического трафика, который достигает около 500 тысяч. сеансов в месяц . По этому поводу я решил опубликовать краткое резюме мероприятий.

Я перевернул новую версию сайта 22 марта 2019 года, и трафик был практически постоянным, несмотря на изменение структуры некоторых URL-адресов. Ниже вы можете увидеть график трафика за полный месячный период с 5 марта по 5 апреля, чтобы период ошибок Google (заметный на этой конкретной странице с 7 по 10 апреля) нас не беспокоил.

1. Подготовительная работа

Краткий список мероприятий:

• готовим рабочую версию страницы
• контентный анализ, включая статистику посещений + перевод
• выбор темы

На время работы над рабочей версией страницы я установил noindex на вкладке « Настройки» -> «Чтение ». Это была версия, доступная по следующему адресу: nazwastrony.iq.pl (веб-сайт IQ по адресу IQ.pl, и я предоставляю партнерскую ссылку для регистрации для желающих).

Существуют различные способы защитить себя от доступа роботов и пользователей к данному сайту, и в этом случае я решил, что этого будет достаточно для короткого периода работы. Если бы это был один из основных веб-сайтов, где систематически вносятся основные изменения, я бы выбрал отдельный домен с набором запрещенных прав доступа в файле .htaccess (так называемая блокировка htpass), чтобы на него могли попасть только люди, которые знают данные доступа. Тогда не было бы необходимости использовать noindex , фотографию которого можно легко забыть при перемотке страницы.

В старой версии сайта использовалась авторская CMS, созданная много лет назад, поэтому я начал с перемещения всего контента. Некоторые записи были устаревшими , а у некоторых не было большого шанса получить трафик от поисковых систем, и при этом они не были достаточно качественными, чтобы заинтересовать читателей. Поэтому я решил удалить их . Только одна из этих записей соответствовала перенаправлению 301 на его текущий аналог, что я и сделал на следующем этапе работы над сайтом с помощью плагина Redirection . Добавлю, что этот плагин имеет много полезных опций, он регулярно обновляется, и даже сейчас я вижу, что последнее обновление произошло 3 дня назад. Однако я помню временные ошибки, которые были исправлены в последующих обновлениях.

После тщательного анализа всех записей и перемещения их в новую версию страницы моя работа над ней была продлена из-за неправильного выбора темы . К сожалению, это общая проблема, поскольку, на первый взгляд, графическая тема выглядит хорошо и гибко, она может иметь мало общего с гибкостью. Версия, которая мне понравилась, была доступна как в бесплатной, так и в платной версии. У первого вообще не было возможности настраивать цвета, хотя после оплаты покупки оказалось, что один из дополнительных элементов можно отключить только на подстраницах, а на главной странице — обязательно. Конечно, все можно изменить в коде, но речь шла не о том, чтобы я часами играл с темой, а о том, чтобы максимально эффективно перемещать страницу и чтобы я не потерял сохраненные изменения при каждом обновлении темы. Не писать больше об этой теме, я напишу, что я снова начал поиск, и на этот раз я быстро нашел мотив, который потребовал всего несколько косметических изменений и выглядел намного лучше, чем предыдущий.

2. Структура URL — оставить прежнюю или перестроить?

Что нужно подумать:

• была ли старая структура адекватной и стоит ли пытаться ее сохранить?
• Или, может быть, воспользоваться этой возможностью, чтобы настроить совершенно новую структуру адресов?
• Какой плагин я должен использовать, чтобы перенаправить все измененные URL-адреса?

Первая дилемма, с которой я столкнулся, была связана со структурой URL-адресов, потому что не было возможности полностью сохранить старую структуру. Старая структура была следующей:

• статическая подстраница: www.domena.pl/podstrona.php
• подстраница родительской категории: www.domena.pl/kategoria-nadrzedna.php
• подкатегория: страница www.domena.pl/podkategoria.php
• подстраница записи: www.domena.pl/kategoria-nadrzedna/wpis.php ИЛИ www.domena.pl/podkategoria/wpis.php (в следующей части статьи я напишу, почему в этом случае было доступно 2 типа форматов адресов)

До сих пор мне было трудно анализировать трафик на подстраницах Google родительских категорий или подкатегорий, а также всего дерева категорий, поскольку они имели одинаковую структуру адресов и, кроме того, все адреса имели расширение .php. Конечно, это можно сделать окольным путем, но, учитывая, что я переезжал до начала сезона, я мог позволить себе частично изменить URL-адреса и этот вид теста. При изменении всей структуры у меня будет страх, что позиции не удастся стабилизировать до пика интереса к этой теме. По сути, это первая подобная ситуация, потому что я обычно фокусировался на массовых перенаправлениях 301 , даже если вся структура изменилась, но я выбрал время для внесения таких изменений по-другому. На этот раз я немного опоздал, так что это был последний звонок для такого рода работ на сайте, чтобы не пришлось ждать с ними несколько месяцев.

Когда речь идет о статических подстраницах, они не имеют большого значения с точки зрения SEO, поэтому мне было все равно, изменились адреса или нет, и в этом посте мы не будем беспокоиться. Что касается дерева категорий, я планировал исключить только расширение, и поэтому категория будет иметь адрес в форме www.domena.pl/kategoria-przedarial, в то время как подкатегория — адрес в форме www.domena.pl/podkategoria При этом, однако, было бы очень интересно включить его в псевдоним самой подкатегории, но БЕЗ родительской категории . Я протестировал 4 разных штекера, и ни один из них не работал. Наконец, я решил использовать следующую структуру, содержащую полный путь к подкатегории, т.е.

• подстраница родительской категории: www.domena.pl/kademia-wadrzejna (отказаться только от расширения .php)
• подкатегория подстраница: www.domena.pl/category-private/category (отписаться от расширения и добавить родительскую категорию в URL)

В этой категории больше не было полостей, поэтому эта структура казалась мне идеальной.

Чтобы перенаправить дерево категорий, я использовал плагин Redirection, упомянутый выше, который позволяет, среди прочего группировка перенаправлений. Отдельные группы содержат перенаправления на новую структуру родительских категорий (удаление расширения) и подкатегорий (создание верхней категории и полости подкатегории, а также удаление расширения), а отдельные — другие неактивные подстраницы, такие как прежняя подкачка страниц.

Безусловно, большая часть трафика всегда генерировалась подстраницами с записями, поэтому я хотел ничего не менять на них. Проблема в том, что в старых записях у меня был небольшой беспорядок и до определенного момента псевдоним подкатегории добавлялся к адресу записи, а со временем — к родительской категории. Прежде всего, мне пришлось установить структуру по умолчанию для записей на вкладке « Настройки» -> «Прямые ссылки », которая должна была содержать псевдоним из родительской категории и псевдоним из названия сообщения, включая расширение .php. Возможно, некоторые читатели зададут здесь вопрос — почему расширение и почему именно? Если честно, мне все равно нравится, если подстраницы записей имеют какое-либо расширение в отличие от дерева категорий, а .php был просто в старой структуре (в течение нескольких лет), поэтому это было наиболее удобно.

Были еще записи, которые — из-за уже упомянутых ошибок и несоответствий — отличались друг от друга и не могли быть «урегулированы» с одним глобальным параметром. По некоторым причинам я решил использовать Permalink Manager для этого , в котором я мог бы редактировать все адреса удобно и любым способом без увеличения количества перенаправлений. Поэтому я изменил те, чья структура не была совместима с глобальным набором (с подкатегориями в псевдониме), хотя в конечном итоге я собирался перенаправить другие, но после сезона. Я также использовал плагин No Category Base (WMPL), чтобы избавиться от адресов постоянного элемента «category» (или другого в случае измененного имени).

Фактически, несколько ошибок, которые я сделал во время перестройки этого сайта, были результатом того, что я привык копаться в коде или настройках, а также имел давление, чтобы быстро перейти к цели. В последние годы я сосредоточился на более концептуальной работе, и я поручил этот вид работы на аутсорсинг или оставил партнера по команде. Главным образом по этой причине я решил использовать возможность вспомнить все и сделать все сам. Я уверен, что люди, которые систематически работают на нескольких страницах в WordPress, найдут меньше плагинов, чтобы получить тот же эффект. Тем не менее, я справился с этим и подумал, что стоит поделиться этой информацией, особенно с менее продвинутыми пользователями веб-мастеров / seo.

3. Переместить страницу

Фактически, я понял пункт 2 только после переезда, но решил сначала описать его из-за некоторых сложностей. Чтобы окончательная версия страницы работала, я сделал следующее:

• изменение ориентации домена на новую папку — сайт должен был оставаться на том же сервере, что было удобным и простым вариантом, поскольку было достаточно изменить настройки своего домена, чтобы направить его в другую (в настоящее время работающую) папку, не дожидаясь распространения DNS домена, что было бы необходимо переход на другой сервер;
• изменение адреса сайта в настройках WordPress — это было то, что мне нужно было сделать из PHPMyAdmin, для чего нужно было поменять в 2 местах;
• изменив версию PHP с 5.2 на 7.1 и проверив, что все работает правильно;
• фото noindex — одно из самых важных 😉
• настройка плагинов Redirection и Permalink Manager — подробности описаны в пункте 2;
• вставка кода Google Analytics (в настройках пакета «Все в одном») и Google AdSense (именно это я и сделал в плагине Advanced Ads );
• Вставка пикселя FB ;
• однократное сканирование ссылок с помощью плагина Link Checker , который я позже отключил. Он нашел неправильные ссылки;
• загрузка старого, обновленного файла robots.txt ;
• Обновление записей в файле .htaccess .

Чтобы ускорить индексацию изменений, после создания карты сайта загрузите ее в Google Search Console и, если записи удалены (без их перенаправления), проиндексируйте их с помощью этих инструментов.

4. Мониторинг ошибок, изменений в движении и позициях

Список мониторинга:

• проверка подготовленного списка TODO перед началом работ на сайте;
• мониторинг состояния индексации;
• мониторинг ошибок;
• мониторинг изменений посещаемости сайта и позиций.

Чтобы мы не пропустили ничего важного, лучше всего записать всю информацию о структуре страницы перед началом работы на сайте (для меня несколько подстраниц были созданы «вручную» из-за необычных потребностей, поэтому они не были доступны в административной панели) Настройки цели GA (при изменении структуры адреса необходимо обновить пути к цели), коды отслеживания , и если проверка владения страницей в Google Search Console была произведена путем загрузки файла на диск, необходимо сохранить его. Просто глядя на основную папку старой версии страницы , вы сможете найти дополнительные файлы, которые мы должны перенести в новую версию.

Чтобы проверить статус индексации и то, успешно ли мы внедрили перенаправления, я использую веб-сайт www.urlitor.com в сочетании с расширением Google Chrome под названием Scraper . Сначала я перечисляю адреса всех проиндексированных подстраниц, а затем массово проверяю их заголовки HTTP, инструмент немедленно показывает любые цепочки перенаправления.

Мы также отслеживаем ошибки, появляющиеся на нем, которые могут быть обнаружены некоторыми плагинами WordPress, давайте пойдем много и протестируем его, как если бы это был новый веб-сайт и как если бы нам пришлось проверять каждую деталь на нем, включая правильную работу подписки на рассылку с обновлением ссылки на политику конфиденциальности ниже . Если в прошлом несколько человек имели доступ к сайту, стоит воспользоваться возможностью предоставления разных разрешений каждому из них в WordPress.

Затем в течение определенного периода времени вы должны тщательно проанализировать трафик веб-сайта с акцентом на возможное уменьшение трафика в различных типах подстраниц. Может оказаться, что существуют проблемные типы страниц, например дерево категорий, которые, однако, были неправильно или не полностью перенаправлены или доступны по старым и новым адресам одновременно. Работа и ошибки в некоторых плагинах не могут быть предсказаны, и им нравится происходить, в частности, если несколько плагинов перезаписывают свои настройки. Для сезонных услуг лучше сравнивать органический трафик с соответствующим периодом годом ранее, а не только с прошлым месяцем или несколькими. Не следует проводить такой анализ в непосредственной близости от движущихся выходных, потому что это мешает просмотру и анализу, если годом ранее начался Праздник, например, 2 неделями ранее. Ниже приведен текущий график изменений в органическом трафике по сравнению с предыдущим годом.

Писая об анализе изменений в трафике, в частности органическом, я не могу не упомянуть анализ изменений в позициях страниц с акцентом на фразы, относящиеся к подстраницам, адреса которых изменились. На SeoStation вы можете включить отображение информации об изменениях на подстраницах , и в дополнение к групповым диаграммам стоит проверять изменения положения сразу по нескольким фразам . На приведенной ниже диаграмме показаны аннотации об изменениях подстраниц (желтые точки), и в этом случае это были кратковременные изменения между адресом категории с расширением и без него. К счастью, это не повлияло на колебания позиции.

Перемещение веб-сайта, которое в первую очередь изменило платформу (с авторского скрипта на WordPress), прошло успешно и не отскочило в результатах поиска. Мои опасения, в отношении которых я решил только частичную диверсию, не сбылись 😉