#11-15 URL-редиректы для SEO. Экспресс-правка

'#6. Тексты : texts';

'Express_ChapterController_actionView';

'#express_chapter_view';

<p style="text-align: right;">автор: <a title="Go to Author Page" href="https://www.searchenginejournal.com/author/vpetr/">Vahan Petrosyan</a></p>
<p>Перенаправления для SEO следует использовать правильно, потому что они влияют на то, как веб-сайты сканируются и индексируются Google.</p>
<p>В то время как большинство людей думают о перенаправлениях как о знаке в интернете, указывающем на обход, происходит гораздо больше, и удивительно интересно это обнаружить.</p>
<p>Продолжайте читать, чтобы получить всесторонний обзор перенаправлений и правильного их применения для технического SEO.</p>
<h2>Что такое перенаправление?</h2>
<p>Перенаправления веб-сайта сообщают браузерам и поисковым системам информацию о URL и том, где найти веб-страницу.</p>
<p>Перенаправление URL включает код, реализованный для определенного URL или группы URL, так что пользователь (или поисковая система) отправляется на другую страницу по сравнению с фактическим URL, который был введен или нажат.</p>
<p>Перенаправление может быть установлено как:</p>
<ul>
<li>Временное перенаправление: 302, 303, 307, 308.</li>
<li>Постоянное перенаправление: 301.</li>
</ul>
<h3>Когда использовать перенаправления</h3>
<p>Основные причины использования перенаправлений:</p>
<ul>
<li>Отдельная страница или весь домен был перемещен (изменен URL).</li>
<li>Для использования сокращателей URL или &laquo;красивых&raquo; URL.</li>
<li>Миграция сайта (например, с HTTP на HTTPS).</li>
</ul>
<p>С точки зрения SEO перенаправления URL важны, потому что:</p>
<ul>
<li>Перенаправление вперед авторитета всех ссылок, указывающих на страницу, которая была перемещена или удалена.</li>
<li>Избегание ошибок 404 страница не найдена (хотя иногда лучше оставить 404).</li>
<li>Перенаправления могут быть реализованы для группы или для всего домена, но часто их нужно устанавливать индивидуально, чтобы избежать проблем.</li>
</ul>
<p>При использовании RegEX для групповых перенаправлений это может привести к неожиданным результатам, если ваша логика не безупречна!</p>
<h3>Типы перенаправлений</h3>
<p>Существует три основных типа перенаправлений:</p>
<ul>
<li><strong>Перенаправления Meta Refresh</strong> устанавливаются на уровне страницы, но обычно не рекомендуются в целях SEO. Существует два типа перенаправлений Meta Refresh: отложенное, которое рассматривается как временное перенаправление, и мгновенное, которое рассматривается как постоянное перенаправление.</li>
<li><strong>Перенаправления Javascript</strong> также устанавливаются на стороне клиента и могут вызвать проблемы с SEO. Google выразил предпочтение HTTP-серверным перенаправлениям.</li>
<li><strong>HTTP-перенаправления</strong> устанавливаются на стороне сервера и являются лучшим подходом в целях SEO &ndash; мы рассмотрим подробнее ниже.</li>
</ul>
<h2>Что такое код состояния HTTP Response?</h2>
<p>Браузеры и веб-краулеры, такие как GoogleBot, называются пользовательскими агентами.</p>
<p>Когда пользовательский агент пытается получить доступ к веб-странице, происходит следующее: пользовательский агент отправляет запрос, и сервер веб-сайта выдает ответ.</p>
<p>Ответ называется кодом состояния HTTP Response. Он предоставляет статус для запроса URL.</p>
<p>В ситуации, когда пользовательский агент, такой как GoogleBot, запрашивает URL, сервер предоставляет ответ.</p>
<p>Например, если запрос на URL выполнен успешно, сервер предоставит код ответа 200, что означает успешность запроса URL.</p>
<p>Таким образом, когда вы думаете о том, что GoogleBot достигает веб-сайта и пытается его просканировать, происходит серия запросов и ответов.</p>
<h2>HTTP-перенаправления</h2>
<p>HTTP-перенаправление &ndash; это ответ сервера на запрос URL.</p>
<p>Если URL существует по другому URL (потому что он был перемещен), сервер сообщает пользовательскому агенту, что запрос URL перенаправляется на другой URL.</p>
<p>Код ответа для измененного URL обычно представлен в виде кода состояния ответа 301 или 302.</p>
<p>Вся серия ответных кодов 3xx содержит много информации, которую пользовательский агент может по желанию использовать.</p>
<p>Пример действия, которое может предпринять пользовательский агент, &ndash; сохранить кэш нового URL, чтобы в следующий раз, когда будет запрошен старый URL, запрос был направлен на новый URL.</p>
<p>Таким образом, 301 и 302 перенаправления &ndash; это не просто знак в интернете, который говорит: &laquo;Иди сюда, не туда&raquo;.</p>
<h2>Серия статус-кодов 3XX</h2>
<p>Перенаправления &ndash; это не только два статус-кода, с которыми знакомы все, 301 и 302.</p>
<p>Всего существует семь официальных статус-кодов ответов 3xx.</p>
<p>Вот различные виды перенаправлений, доступные для использования:</p>
<ul>
<li>300 Множество выборов.</li>
<li>301 Перемещено навсегда.</li>
<li>302 Найдено.</li>
<li>303 Смотреть другое.</li>
<li>304 Не изменено.</li>
<li>305 Использовать прокси.</li>
<li>306 (Не используется).</li>
<li>307 Временное перенаправление.</li>
<li>308 Постоянное перенаправление.</li>
</ul>
<p>Некоторые из вышеупомянутых статус-кодов не существуют так долго и могут не использоваться. Поэтому, прежде чем использовать какой-либо код перенаправления, кроме 301 или 302, убедитесь, что предназначенный пользовательский агент может его интерпретировать.</p>
<p>Поскольку GoogleBot использует последнюю версию Chrome (называемую безголовым браузером), легко проверить, совместим ли статус-код, проверив, признает ли Chrome статус-код с помощью списка совместимости браузера.</p>
<p>В целях SEO следует придерживаться использования статус-кодов ответов 301 и 302, если нет конкретной причины использования одного из других кодов.</p>
<h3>301: Перемещено навсегда</h3>
<p>Статус-код 301 обычно называют 301 перенаправлением. Но официальное название &ndash; 301 Перемещено навсегда.</p>
<p><a title="301 перенаправление" href="https://shopnseo.ru/texts/spravochnik-po-seo-onlayn-torgovle-i-internetu/redirect-301">301 перенаправление</a> указывает пользовательскому агенту, что URL (иногда называется целевым ресурсом или просто ресурсом) был изменен на другое местоположение и что для будущих запросов следует использовать новый URL.</p>
<p>Как упоминалось ранее, существует еще больше информации.</p>
<p>Статус-код 301 также подсказывает пользовательскому агенту:</p>
<ul>
<li>Запросы для URL должны выполняться с новым URL.</li>
<li>Тот, кто делает запрос, должен обновить свои ссылки на новый URL.</li>
<li>Последующие запросы можно изменить с GET на POST.</li>
</ul>
<p>Последний пункт &ndash; это технический вопрос. Согласно официальным стандартам для статус-кода 301:</p>
<blockquote>
<p>"Примечание: по историческим причинам пользовательский агент МОЖЕТ изменить метод запроса с POST на GET для последующего запроса. Если такое поведение нежелательно, вместо этого можно использовать статус-код 308 (Постоянное перенаправление)."</p>
</blockquote>
<p>Для SEO, когда поисковые системы видят 301 перенаправление, они передают рейтинг старой страницы новой.</p>
<p>Перед внесением изменений следует быть осторожным при использовании 301 перенаправления. 301 перенаправление должно использоваться только тогда, когда изменение на новый URL является постоянным.</p>
<p>Статус-код 301 не должен использоваться, если изменение является временным.</p>
<p>Кроме того, если вы передумаете позже и вернетесь к старому URL, старый URL может потерять свой ранг и потребует времени для его восстановления.</p>
<p>Таким образом, главное, что следует запомнить, заключается в том, что статус-код 301 будет использоваться, когда изменение является постоянным.</p>
<h3>302: Найдено</h3>
<p>Основное, что следует понимать про статус-код 302, заключается в том, что он полезен в ситуациях, когда URL временно изменен.</p>
<p>Этот код ответа означает, что URL временно находится по другому URL, и предлагается использовать старый URL для будущих запросов.</p>
<p>Статус-код 302 перенаправления также сопровождается техническим предупреждением, касающимся GET и POST:</p>
<blockquote>
<p>"Примечание: по историческим причинам пользовательский агент МОЖЕТ изменить метод запроса с POST на GET для последующего запроса. Если такое поведение нежелательно, вместо этого можно использовать статус-код 307 (Временное перенаправление)."</p>
</blockquote>
<p>Ссылка на "исторические причины" может относиться к старым или ошибочным пользовательским агентам, которые могли изменять метод запроса.</p>
<h3>307: Временное перенаправление</h3>
<p>307 перенаправление означает, что запрошенный URL временно перемещен, и пользовательский агент должен использовать исходный URL для будущих запросов.</p>
<p>Единственное различие между статус-кодами 302 и 307 заключается в том, что пользовательский агент должен запросить новый URL с тем же HTTP-запросом, который использовался для запроса исходного URL.</p>
<p>Это означает, что если пользовательский агент запрашивает страницу с помощью запроса GET, то пользовательский агент должен использовать запрос GET для нового временного URL и не может использовать запрос POST.</p>
<p>Документация Mozilla по статус-коду 307 объясняет это более ясно, чем официальная документация.</p>
<blockquote>
<p>"Сервер отправляет этот ответ, чтобы направить клиента получить запрашиваемый ресурс по другому URI с тем же методом, который использовался в предыдущем запросе.</p>
<p>Это имеет те же семантические характеристики, что и статус-код 302 Found HTTP, за исключением того, что пользовательский агент не должен изменять используемый метод HTTP: если POST был использован в первом запросе, POST должен использоваться во втором запросе."</p>
</blockquote>
<p>За исключением того, что статус-код 307 требует, чтобы последующие запросы были того же вида (POST или GET), и что статус-код 302 может двигаться в обе стороны, все остальное идентично между статус-кодами 302 и 307.</p>
<h3>302 против 307</h3>
<p>Вы можете обработать перенаправление с использованием файлов конфигурации сервера .htaccess на Apache, файла example.conf на Nginx или с использованием плагинов, если вы используете WordPress.</p>
<p>Во всех случаях они имеют одинаковый синтаксис для написания правил перенаправления. Они отличаются только командами, используемыми в файлах конфигурации. Например, перенаправление на Apache будет выглядеть так:</p>
<ul>
<li><code>Options +FollowSymlinks</code></li>
<li><code>RewriteEngine on</code></li>
<li><code>RedirectMatch 301 ^/oldfolder/ /newfolder/</code></li>
</ul>
<p>На серверах Nginx это будет выглядеть так:</p>
<ul>
<li><code>rewrite ^/oldfolder/ /newfolder/ permanent;</code></li>
</ul>
<p>Используемые команды для указания статус-кода перенаправления сервера и команды действия различаются.</p>
<p>Например:</p>
<ul>
<li><code>Статус-код перенаправления сервера: "301" против "permanent".</code></li>
<li><code>Команда действия: "RedirectMatch" против "rewrite".</code></li>
</ul>
<p>Но синтаксис перенаправления (`^/oldfolder/ /newfolder/`) одинаков для обоих.</p>
<p>На Apache убедитесь, что модули mod_rewrite и mod_alias (ответственные за обработку перенаправлений) включены на вашем сервере.</p>
<p>Поскольку самый распространенный тип сервера &ndash; это Apache, вот примеры для файлов .htaccess Apache.</p>
<p>Убедитесь, что в файле .htaccess есть эти две строки перед правилами перенаправления, и поместите правила ниже них:</p>
<ul>
<li><code>Options +FollowSymlinks</code><br><code>RewriteEngine on</code></li>
</ul>
<p>Прочтите <a href="https://httpd.apache.org/docs/current/mod/mod_rewrite.html#RewriteEngine">официальную документацию</a>.</p>
<p>Чтобы лучше понять приведенные ниже примеры, вы можете обратиться к таблице основных элементов регулярных выражений.</p>
<table>
<tbody>
<tr>
<td>*</td>
<td>zero or more times</td>
</tr>
<tr>
<td>+</td>
<td>One or more times</td>
</tr>
<tr>
<td>.</td>
<td>any single character</td>
</tr>
<tr>
<td>?</td>
<td>Zero or one time</td>
</tr>
<tr>
<td>^</td>
<td>Start of the string</td>
</tr>
<tr>
<td>$</td>
<td>End of the string</td>
</tr>
<tr>
<td>a|b</td>
<td>OR operadn &ldquo;|&rdquo; a or b</td>
</tr>
<tr>
<td>(z)</td>
<td>remembers the match to be used when calling $1</td>
</tr>
</tbody>
</table>
<h2>Как создать перенаправления</h2>
<ul>
<li>Перенаправление одного URL-адреса</li>
<li>Перенаправить все кроме</li>
<li>Изменение каталога</li>
<li>Удалить слово из URL</li>
<li>Установить канонический URL</li>
<li>Перенаправление с HTTP на HTTPS</li>
<li>Перенаправление с старого домена на новый</li>
</ul>
<h3>Перенаправление для одного URL</h3>
<p>Наиболее распространенным и широко используемым типом перенаправления является удаление страниц или изменение URL-адресов.</p>
<p>Например, предположим, вы изменили URL-адрес с /old-page/ на /new-page/. Правило перенаправления будет следующим:</p>
<p style="padding-left: 40px;"><code>RewriteRule ^old-page(/?|/.*)$ /new-page/ [R=301,L]</code></p>
<p>Или</p>
<p style="padding-left: 40px;"><code>RedirectMatch 301 ^/old-page(/?|/.*)$ /new-page/</code></p>
<p>Единственное различие между этими двумя методами заключается в том, что первый использует модуль Apache mod_rewrite, а второй &ndash; mod_alias. Оба метода могут быть использованы.</p>
<p>Регулярное выражение "^" означает, что URL должен начинаться с "/old-page", тогда как (/?|/.*)$ указывает, что все, что следует за "/old-page/" с косой чертой "/" или без точного соответствия, должно быть перенаправлено на /new-page/.</p>
<p>Мы также можем использовать (.*), то есть ^/old-page(.*), но проблема в том, что, если у вас есть еще одна страница с похожим URL-адресом, например /old-page-other/, ее тоже перенаправит, когда нам нужно перенаправить только /old-page/.</p>
<p>Следующие URL будут сопоставлены и перенаправлены на новую страницу:</p>
<ul>
<li>/old-page/ &ndash; /new-page/</li>
<li>/old-page &ndash; /new-page/</li>
<li>/old-page/?utm_source=facebook.com &ndash; /new-page/?utm_source=facebook.com</li>
<li>/old-page/child-page/ &ndash; /new-page/</li>
</ul>
<p>Он перенаправит любую вариацию URL страницы на новую. Если мы используем перенаправление в следующей форме:</p>
<p style="padding-left: 40px;"><code>Redirect 301 /old-page/ /new-page/</code></p>
<p>Без регулярных выражений все URL с UTM-строкой запроса, например <strong>/old-page?utm_source=facebook.com</strong> (что распространено, так как URL используются для обмена в социальных сетях), окажутся как 404.</p>
<p>Даже /old-page без завершающей косой черты "/" также приведет к 404.</p>
<h3>Перенаправление всех, за исключением</h3>
<p>Допустим, у нас есть много URL-адресов вроде /category/old-subcategory-1/, /category/old-subcategory-2/, /category/final-subcategory/, и мы хотим объединить все подкатегории в /category/final-subcategory/. Нам нужно использовать правило "все, за исключением" здесь.</p>
<ul>
<li><code>RewriteCond %{REQUEST_URI} !/category/final-subcategory/</code></li>
<li>RewriteCond %{REQUEST_FILENAME} !-f</li>
<li><code>RewriteRule ^(category/). /category/final-subcategory/ [R=301,L]</code></li>
</ul>
<p>Здесь мы хотим перенаправить все под /category/ на третьей строке, за исключением случая /category/final-subcategory/ на четвертой строке. У нас также есть правило "!-f" на второй строке, игнорируя любые файлы, такие как изображения, CSS или файлы JavaScript.</p>
<p>В противном случае, если у нас есть некоторые ресурсы, такие как "/category/image.jpg", они также будут перенаправлены на "/final-subcategory/" и вызовут разрыв изображения.</p>
<h3>Изменение директории</h3>
<p>Вы можете использовать следующее правило, если вы провели реструктуризацию категорий и хотите переместить все из старого каталога в новый.</p>
<ul>
<li><code>RewriteRule ^old-directory$ /new-directory/ [R=301,NC,L]</code></li>
<li><code>RewriteRule ^old-directory/(.*)$ /new-directory/$1 [R=301,NC,L]</code></li>
</ul>
<p>Я использовал $1 в цели, чтобы сказать серверу, что он должен запомнить все в URL, следующее за /old-directory/ (т.е. /old-directory/subdirectory/) и передать это (т.е. "/subdirectory/") на место назначения. В результате он будет перенаправлен на /new-directory/subdirectory/.</p>
<p>Я использовал два правила: одно без косой черты в конце и другое с косой чертой в конце.</p>
<p>Я мог бы объединить их в одно правило, используя (/?|.*)$ в конце, но это вызвало бы проблемы и добавило бы " //" слэш в конце URL при запросе URL без косой черты с query string (т.е. "/old-directory?utm_source=facebook" будет перенаправлен на "/new-directory//?utm_source=facebook").</p>
<h3>Удаление слова из URL</h3>
<p>Предположим, у вас есть 100 URL-адресов на вашем сайте с названием города "Чикаго", и вы хотите их удалить.</p>
<p>Для URL http://ваш_сайт.com/example-chicago-event/ правило перенаправления будет следующим:</p>
<p style="padding-left: 40px;"><code>RewriteRule ^(.*)-chicago-(.*) http://%{SERVER_NAME}/$1-$2 [NC,R=301,L]</code></p>
<p>Если пример URL имеет форму http://ваш_сайт.com/example/chicago/event/, тогда перенаправление будет следующим:</p>
<p style="padding-left: 40px;"><code>RewriteRule ^(.*)/chicago/(.*) http://%{SERVER_NAME}/$1/$2 [NC,R=301,L]</code></p>
<h3>Установка канонического URL</h3>
<p>Наличие канонических URL &ndash; самая важная часть SEO.</p>
<p>Если их нет, вы можете подвергнуть свой сайт проблемам с дублированием контента, потому что поисковые системы рассматривают URL-адреса с версиями "www" и "non-www" как разные страницы с одинаковым контентом. Поэтому вы должны убедиться, что ваш сайт работает только с одной версией, которую вы выбираете.</p>
<p>Если вы хотите запустить свой сайт с версией "www", используйте это правило:</p>
<ul>
<li><code>RewriteCond %{HTTP_HOST} ^ваш_сайт.com [NC]</code></li>
<li><code>RewriteRule ^(.*)$ http://www.ваш_сайт.com/$1 [L,R=301]</code></li>
</ul>
<p>Для версии "non-www":</p>
<ul>
<li><code>RewriteCond %{HTTP_HOST} ^www.ваш_сайт.com [NC]</code></li>
<li><code>RewriteRule ^(.*)$ http://ваш_сайт.com/$1 [L,R=301]</code></li>
</ul>
<p>Косая черта в конце также является частью канонизации, так как URL с косой чертой в конце или без нее также рассматриваются по-разному.</p>
<ul>
<li><code>RewriteCond %{REQUEST_FILENAME} !-f</code></li>
<li><code>RewriteRule ^(.*[^/])$ /$1/ [L,R=301]</code></li>
</ul>
<p>Это гарантирует, что /example-page будет перенаправлен на /example-page/. Вы можете выбрать вариант удаления косой черты вместо добавления, тогда вам понадобится другое правило:</p>
<ul>
<li>RewriteCond %{REQUEST_FILENAME} !-d</li>
<li>RewriteRule ^(.*)/$ /$1 [L,R=301]</li>
</ul>
<h3>Перенаправление с HTTP на HTTPS</h3>
<p>После инициативы Google по поощрению владельцев веб-сайтов использовать SSL, переход на HTTPS &ndash; одно из наиболее часто используемых перенаправлений, которое есть почти на каждом веб-сайте.</p>
<p>Следующее правило Rewrite можно использовать для принудительного использования HTTPS на каждом веб-сайте.</p>
<ul>
<li><code>RewriteCond %{HTTP_HOST} ^ваш_сайт.com [NC,OR]</code></li>
<li><code>RewriteCond %{HTTP_HOST} ^www.ваш_сайт.com [NC]</code></li>
<li><code>RewriteRule ^(.*)$ https://www.ваш_сайт.com/$1 [L,R=301,NC]</code></li>
</ul>
<p>С его помощью можно объединить перенаправление версии с "www" или "non-www" в одно правило перенаправления HTTPS.</p>
<h3>Перенаправление со старого домена на новый</h3>
<p>Это также одно из самых используемых перенаправлений, когда вы решаете провести переосмысление и должны изменить свой домен. Правило ниже перенаправляет old-domain.com на new-domain.com.</p>
<ul>
<li>RewriteCond %{HTTP_HOST} ^old-domain.com$ [OR]</li>
<li>RewriteCond %{HTTP_HOST} ^www.old-domain.com$</li>
<li>RewriteRule (.*)$ http://www.new-domain.com/$1 [R=301,L]</li>
</ul>
<p>Оно использует два случая: один с "www" версией URL и другой &ndash; "non-www", потому что любая страница по историческим причинам может иметь входящие ссылки на обе версии.</p>
<p>Обработка перенаправлений с использованием плагинов может немного отличаться от обсуждаемого выше.</p>
<h2>Рекомендации по перенаправлениям</h2>
<h3>1. Не перенаправляйте все сломанные URL-адреса 404 на главную страницу</h3>
<p>Это часто происходит, когда вы слишком ленивы, чтобы исследовать ваши URL-адреса 404 и сопоставить их с соответствующей целевой страницей.</p>
<p>В соответствии с Google, они все еще обрабатываются как 404.</p>
<blockquote>
<p>Да, это не лучшая практика (сбивает с толку пользователей), и мы все равно обрабатываем их как 404 (они являются мягкими 404), поэтому пользы от этого нет. Это не критически сломано/плохо, но дополнительная сложность без видимой причины &ndash; вместо этого создайте лучшую страницу 404.<br>&ndash; Джон (@JohnMu) 8 января 2019 года</p>
</blockquote>
<p>Если у вас слишком много таких страниц, вам следует подумать о создании красивых страниц 404 и вовлечении пользователей в дальнейший просмотр или поиск чего-то другого, чем то, что они искали, отображая поле поиска.</p>
<p>Google настоятельно рекомендует, чтобы содержимое перенаправленной страницы было эквивалентно старой странице. Иначе такой редирект может быть сочтен мягким 404-кодом, и вы потеряете рейтинг этой страницы.</p>
<h3 data-sourcepos="1:1-1:53">2. Правильное перенаправление на мобильные страницы</h3>
<p data-sourcepos="3:1-3:263">Если у вас разные URL-адреса для настольных и мобильных веб-сайтов (например, &laquo;example.com&raquo; для настольных компьютеров и &laquo;m.example.com&raquo; для мобильных устройств), вы должны убедиться, что пользователи перенаправляются на соответствующую страницу мобильной версии.</p>
<p data-sourcepos="5:1-5:14"><strong>Правильно:</strong></p>
<div class="code-block ng-star-inserted">
<ul>
<li><code class="code-container no-decoration-radius" role="text">example.com/sport/ &rarr; m.example.com/sport/
</code></li>
</ul>
</div>
<p data-sourcepos="11:1-11:16"><strong>Неправильно:</strong></p>
<div class="code-block ng-star-inserted">
<ul>
<li><code class="code-container no-decoration-radius" role="text">example.com/sport/ &rarr; example.com
</code></li>
</ul>
</div>
<p data-sourcepos="17:1-17:139">Также вы должны убедиться, что если одна страница является 404 на настольном компьютере, она также должна быть 404 на мобильном устройстве.</p>
<p data-sourcepos="19:1-19:138">Если у вас нет мобильной версии для страницы, вы можете избежать перенаправления на мобильную версию и оставить их на настольной странице.</p>
<h3 data-sourcepos="1:1-1:39">Как использовать мета-обновление</h3>
<p data-sourcepos="3:1-3:109">Существует возможность выполнить перенаправление с помощью тега мета-обновления, как показано в примере ниже:</p>
<div class="code-block ng-star-inserted">
<ul>
<li><code class="code-container no-decoration-radius" role="text">&lt;meta http-equiv="refresh" content="0;url=http://example.com/new-page/" /&gt;
</code></li>
</ul>
</div>
<p data-sourcepos="9:1-9:96">Если вы вставляете этот тег в /old-page/, он немедленно перенаправит пользователя на /new-page/.</p>
<p data-sourcepos="1:1-1:74">Google не запрещает этот редирект, но не рекомендует его использовать.</p>
<p style="padding-left: 40px;" data-sourcepos="3:1-3:106">Тип редиректа мета-обновления должен просто работать. Мы не рекомендуем его использовать по двум причинам:</p>
<ul>
<li style="list-style-type: none;">
<ul data-sourcepos="5:1-7:0">
<li data-sourcepos="5:1-5:75">UX (он сохраняет страницу в истории браузера, насколько мне известно)</li>
<li data-sourcepos="6:1-7:0">Время обработки (нам нужно проанализировать страницу, чтобы увидеть ее).</li>
</ul>
</li>
</ul>
<p style="padding-left: 40px;" data-sourcepos="8:1-8:85">Как только он будет обработан, он будет работать так же, как и любой другой редирект.</p>
<p style="padding-left: 40px; text-align: right;" data-sourcepos="10:1-10:40">&ndash; Джон (@JohnMu) 2 марта 2018 года</p>
<p data-sourcepos="12:1-12:155">По словам Джона Мюллера, поисковые системы могут не распознавать этот тип редиректа должным образом. То же самое верно и в отношении JavaScript-редиректов.</p>
<h3>4. Избегайте цепочек перенаправлений</h3>
<p>Это сообщение отображается, когда у вас неверно настроено регулярное выражение и в результате возникает бесконечный цикл.</p>
<p><img class="img-fluid" src="https://static.shopnseo.ru/uploads/mceu_48291906511704957363480.webp" alt="бесконечный цикл перенаправлений" width="1024" height="574" style="display: block; margin-left: auto; margin-right: auto;" loading="lazy"></p>
<p>Обычно это происходит, когда у вас есть цепочка перенаправлений.</p>
<p>Предположим, вы давно перенаправили страницу 1 на страницу 2. Возможно, вы забыли, что страница 1 перенаправлена, и решили перенаправить страницу 2 обратно на страницу 1.</p>
<p>В результате у вас получится правило:</p>
<ul>
<li><code>RewriteRule ^page1 /page2 [R=301,NC,L]</code></li>
<li><code>RewriteRule ^page2 /page1 [R=301,NC,L]</code></li>
</ul>
<p>Это создаст бесконечный цикл и вызовет ошибку, показанную выше.</p>
<h2>Заключение</h2>
<p>Знание того, что такое перенаправления и в какой ситуации требуется конкретный код состояния, является фундаментальным для правильной оптимизации веб-страниц. Это ядро понимания SEO.</p>
<p>Многие ситуации требуют точного знания перенаправлений, например, при переносе веб-сайта на новый домен или создании временного URL-адреса для удержания веб-страницы, которая вернется под своим обычным URL-адресом.</p>
<p>Хотя с плагинами возможно многое, плагины могут быть неправильно использованы без правильного понимания того, когда и почему использовать тот или иной тип перенаправления.</p>

Символов: 0 Слов: 0

Текст скопирован в буфер!

Текст вставлен из буфера!

VirtualityCMS

Оптимизация пагинации для SEO

Полное название	VirtualityCMS
Идентификатор ссылки (англ.)	vigbo-copy

Время чтения (мин.): 1

Слов: 93

Знаков: 1492

Описание

VirtualityCMS

Cистема управления контентом VirtualityCMS разработана индивидуальным предпринимателем в 2020-м году для создания интернет-магазинов, интеграции склада и автоматизации торгового цикла.

Обзор

Описание

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

Заключение

В целом, VirtualityCMS не рекомендуется к использованию.

Стоимость

Цены VirtualityCMS

Оплата разово от 15.500 до 135.000 рублей.

Цены КБ77

Услуга установки сайта на VirtualityCMS не осуществляется.

Полное название	Оптимизация пагинации для SEO: полное руководство по лучшим практикам
Идентификатор ссылки (англ.)	optimizatsiya-paginatsii-dlya-seo-59228

Время чтения (мин.): 18

Слов: 2587

Знаков: 34655

Описание

В этом руководстве вы узнаете, как pagination может навредить SEO, плюсы и минусы различных способов обработки pagination и как отслеживать KPI.

автор: Jes Scholz

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

Для специалистов по SEO вопрос не в том, если вам придется иметь дело с пагинацией, а в том, когда.

В определенный момент роста веб-сайтам необходимо разделить контент на несколько составных страниц для юзабилити (UX).

Наша задача – помочь поисковым системам сканировать и понимать взаимосвязь между этими URL-адресами, чтобы они индексировали самую релевантную страницу.

Со временем лучшие практики SEO для обработки пагинации эволюционировали. На протяжении всего пути многие мифы выдавали себя за факты. Но больше нет.

Эта глава:

Развенчает мифы о том, как пагинация вредит SEO.
Предложит оптимальный способ управления пагинацией.
Рассмотрит неправильно понятые или несоответствующие методы обработки пагинации.
Исследует, как отслеживать влияние пагинации на KPI.

Как пагинация может повредить SEO

Вы, наверное, слышали, что пагинация вредна для SEO. Однако в большинстве случаев это происходит из-за неправильной обработки пагинации, а не из-за самой пагинации.

Давайте рассмотрим предполагаемые недостатки пагинации и способы устранения SEO-проблем, которые она может вызвать.

Пагинация вызывает дублирование контента

В некоторых случаях пагинация может привести к дублированию контента, например, если у вас есть как «Смотреть все» страницу, так и пронумерованные страницы без правильного rel=canonical или если вы создали страницу=1 в дополнение к вашей корневой странице.

Однако при правильной реализации SEO-ориентированной пагинации дублирования контента не будет. Даже если ваши теги H1 и meta одинаковы, фактический контент страниц отличается.

Джон Мюллер подтверждает, что дублирование тегов title и description для пронумерованных страниц не является проблемой, если они использовались случайно на совершенно разных страницах. Это нормально и ожидается для paginated series.

Пагинация создает тонкий контент

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

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

Пагинация снижает силу сигналов ранжирования

Верно. Пагинация приводит к тому, что внутренняя ссылка на авторитет и другие сигналы ранжирования, такие как обратные ссылки и социальные акции, распределяются по нескольким страницам.

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

Пагинация тратит бюджет сканирования

Верно, если вы разрешаете Google сканировать пронумерованные страницы. И есть некоторые случаи, когда вы хотите использовать этот бюджет.

Например, для Googlebot путешествовать по пронумерованным URL-адресам, чтобы добраться до более глубоких страниц контента.

Часто неверно, когда вы устанавливаете параметр обработки параметров пагинации в Google Search Console в значение «Не сканировать» или устанавливаете запрет в robots.txt, в случае, если вы хотите сохранить свой бюджет сканирования для более важных страниц.

Управление пагинацией в соответствии с лучшими SEO-практиками

Использование индексируемых ссылок якоря

Чтобы поисковые системы могли эффективно сканировать пронумерованные страницы, на сайте должны быть ссылки якоря с атрибутами href, ведущие к этим URL-адресам пагинации.

Убедитесь, что ваш сайт использует <a href="your-paginated-url-here"> для внутренней пересылки на пронумерованные страницы. Не загружайте пронумерованные ссылки якоря или атрибут href через JavaScript.

Кроме того, вы должны указать отношение между URL-адресами компонентов в серии пагинации с помощью атрибутов rel="next" и rel="prev".

Да, даже после печально известного твита Google о том, что они больше не используют эти атрибуты ссылок.

Однако вскоре после этого Илья Григорик, инженер по поиску в Google, дал разъяснение по этому вопросу. Он сказал, что хотя Google больше не использует эти атрибуты ссылок для определения релевантности страниц, они все еще могут быть полезны для других целей, таких как навигация для пользователей и помощь поисковым системам в понимании структуры сайта.

Илья Григорик также сказал, что использование атрибутов rel="next" и rel="prev" не повредит рейтингу вашего сайта в Google. Поэтому, если вы хотите использовать эти атрибуты для улучшения навигации и взаимодействия с пользователем, вы можете это сделать без каких-либо опасений.

Google не единственный поисковый движок в городе. Вот как Bing относится к этому вопросу.

«Мы используем rel prev/next (как и большую часть разметки) в качестве подсказок для обнаружения страниц и понимания структуры сайта. На данный момент мы не объединяем страницы в индексе на основе этих ссылок, и мы не используем prev/next в модели ранжирования.»

– Frédéric Dubut (@CoperniX) 21 марта 2019 года

Дополните rel="next"/ "prev" ссылкой на себя rel="canonical". Таким образом, /category?page=4 должен ссылаться на /category?page=4.

Это правильно, так как пагинация изменяет содержимое страницы, и поэтому это основная копия этой страницы.

Если URL-адрес имеет дополнительные параметры, включите их в ссылки rel="prev" / "next", но не включайте их в rel="canonical".

Например:

<link rel="next" href="https://www.example.com/category?page=2&order=newest" />
<link rel="canonical" href="https://www.example.com/category?page=2" />

Делайте это, чтобы указать четкую взаимосвязь между страницами и предотвратить потенциальный дублированный контент.

Общие ошибки, которых следует избегать:

Размещение атрибутов ссылки в контенте <body>. Они поддерживаются поисковыми системами только в разделе <head> вашего HTML-кода.
Добавление атрибута rel="prev" к первой странице (также известной как корневая страница) в серии или атрибута rel="next" к последней. Для всех других страниц в цепочке должны присутствовать оба атрибута ссылки.
Будьте осторожны с каноническим URL-адресом вашей корневой страницы. Скорее всего, на странице ?page=2 атрибут rel=prev должен ссылаться на каноническую страницу, а не на ?page=1.

Код раздела <head> четырехстраничной серии будет выглядеть примерно так:

Первая страница:

<link rel="next" href="https://www.example.com/category?page=2″>
<link rel=”canonical” href="https://www.example.com/category">

Вторая страница:

<link rel="prev" href="https://www.example.com/category">
<link rel="next" href="https://www.example.com/category?page=3″>
<link rel=”canonical” href="https://www.example.com/category?page=2">

Третья страница:

<link rel="prev" href="https://www.example.com/category?page=2″>
<link rel="next" href="https://www.example.com/category?page=4″>
<link rel=”canonical” href="https://www.example.com/category?page=3">

Четвертая страница (последняя в серии пагинации):

<link rel="prev" href="https://www.example.com/category?page=3">
<link rel=”canonical” href="https://www.example.com/category?page=4">

Изменение элементов страниц с пагинацией

John Mueller прокомментировал: «Мы не относимся к пагинации по-другому. Мы относимся к ним как к обычным страницам».

Смысл этого в том, что Google не рассматривает страницы с пагинацией как серию страниц, объединенных в один фрагмент контента, как они ранее советовали. Каждая пронумерованная страница может конкурировать с корневой страницей за ранжирование.

Чтобы побудить Google вернуть корневую страницу в SERP и предотвратить предупреждения о «дублированных мета-описаниях» или «дублированных тегах заголовка» в Google Search Console, внесите в свой код простое изменение.

Если корневая страница имеет формулу:

заголовки и мета-описания страниц с пагинацией

Эти заголовки и мета-описания страниц с пагинацией намеренно оптимизированы ниже оптимального уровня, чтобы отговорить Google от отображения этих результатов, а не корневой страницы.

Если даже с такими модификациями пронумерованные страницы ранжируются в SERP, попробуйте другие традиционные методы оптимизации на странице, такие как:

Деоптимизация тегов H1 пронумерованных страниц.
Добавление полезного текста на страницу, но не на пронумерованные страницы.
Добавление изображения категории с оптимизированным именем файла и alt-тегом на корневую страницу, но не на пронумерованные страницы.

Не включайте страницы с пагинацией в XML-карты сайта.

Хотя страницы с пагинацией технически индексируются, они не являются приоритетом SEO для расходования бюджета сканирования.

Поэтому они не должны находиться в вашей XML-карте сайта.

Обработка параметров пагинации в Google Search Console

Если у вас есть выбор, используйте пагинацию с помощью параметра вместо статического URL-адреса. Например:

example.com/category?page=2

вместо

example.com/category/page-2

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

С другой стороны, это может потенциально привести к ловушкам для индексации, если сайт отображает пустые страницы для догадок, которые не являются частью текущей серии страниц.

Например, если серия содержит четыре страницы, URL-адрес будет выглядеть так: www.example.com/категория?страница=4.

Если Google предположит, что www.example.com/категория?страница=7 является живой, но пустой страницей, и загрузит ее, бот потратит бюджет на краулинг и потенциально заблудится в бесконечном количестве страниц.

Убедитесь, что для любых пронумерованных страниц, которые не являются частью текущей серии, отправляется код состояния HTTP 404.

Еще одно преимущество подхода с параметрами заключается в возможности настройки параметра в Google Search Console на "Paginates" и в любое время изменения сигнала Google на "Каждый URL" или "Ни один URL", в зависимости от того, как вы хотите использовать свой бюджет на краулинг. Никакой разработчик не нужен!

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

Неправильные, устаревшие или просто ошибочные решения SEO для разделенного контента

Ничего не делайте

Неправильные, устаревшие или просто ошибочные решения SEO

Google считает, что Googlebot достаточно умен, чтобы найти следующую страницу по ссылкам, поэтому ему не нужен никакой явный сигнал.

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

Хотя в этом заявлении есть доля истины, бездействие может поставить под угрозу вашу SEO.

Многие сайты заметили, что Google выбирает отсортированную страницу для ранжирования вместо корневой страницы по поисковому запросу.

Всегда есть ценность в предоставлении ясных указаний поисковым роботам о том, как вы хотите, чтобы они индексировали и отображали ваш контент.

Страница "Посмотреть все"

Страница "Посмотреть все" была задумана как содержащая весь контент каждой отдельной страницы на одном URL-адресе.

Со всеми пронумерованными страницами, имеющими атрибут rel = "canonical" на странице "Посмотреть все", чтобы объединить сигналы ранжирования.

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

Предполагается, что если у вашей серии с разбивкой на страницы есть альтернативная версия "Посмотреть все", которая обеспечивает лучшее взаимодействие пользователя, поисковые системы отдадут предпочтение этой странице перед соответствующей страницей сегмента в цепочке разбивки на страницы при включении ее в результаты поиска.

Это поднимает вопрос: зачем вам вообще нужны пронумерованные страницы?

Если вы можете предоставить свой контент на одном URL-адресе, обеспечивая хорошее взаимодействие пользователя, нет необходимости разбивать его на страницы или иметь версию "Посмотреть все".

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

Использование как rel = "next" / "prev", так и версии "Посмотреть все" не дает четкого сигнала поисковым системам и может привести к путанице у поисковых роботов.

Не делайте этого.

Используйте канонический URL-адрес первой страницы

канонический URL-адрес первой страницы

Ошибка, которую часто допускают, заключается в том, что rel = "canonical" от всех отсортированных результатов указывается на корневую страницу серии.

Некоторые недостаточно осведомленные специалисты по SEO предлагают это как способ консолидации авторитета на наборе страниц на корневую страницу, но это неправильно информировано.

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

Googlebot затем не будет индексировать страницы, которые находятся дальше по цепочке, и не будет признавать сигналы, связанные с контентом, ссылающимся на эти страницы.

Вы не хотите, чтобы ваши подробные страницы контента исключались из индекса из-за неправильной обработки разбивки на страницы.

Каждая страница в серии с разбивкой на страницы должна иметь собственный канонический URL-адрес, если вы не используете страницу "Посмотреть все".

Используйте rel=canonical неправильно, и, вероятно, Googlebot просто проигнорирует ваш сигнал.

Пагинация с тегом Noindex

Классическим методом решения проблем с разбивкой на страницы является использование тега noindex для роботов, чтобы предотвратить индексацию отсортированного контента поисковыми системами.

Полная зависимость от тега noindex для обработки разбивки на страницы приведет к тому, что любые сигналы ранжирования от отдельных страниц будут проигнорированы.

Однако более серьезной проблемой с этим методом является то, что долгосрочный noindex на странице в конечном итоге приведет к тому, что Google перестанет следовать ссылкам на этой странице.

Это может привести к удалению из индекса контента, связанного со страницами с разбивкой на страницы.

Разделение на страницы и бесконечный скрол или нажатие "Показать больше"

Разделение на страницы и бесконечный скрол

Существуют новые варианты обработки пагинации:

Непрерывная прокрутка, где контент предварительно загружается и добавляется непосредственно на текущую страницу пользователя по мере его прокрутки вниз.
Подгрузка контента после нажатия кнопки «Показать больше».

Эти подходы ценятся пользователями, но не Googlebot.

Googlebot не имитирует поведение, такое как прокрутка до конца страницы или нажатие кнопки «Загрузить больше». Это означает, что без помощи поисковые системы не могут эффективно индексировать весь ваш контент.

Чтобы быть SEO-дружественным, преобразуйте вашу страницу со непрерывной прокруткой или загрузкой большего количества в эквивалентную серию, основанную на индексируемых ссылках с атрибутами href, которая доступна даже при отключенном JavaScript.

По мере прокрутки или щелчка пользователем используйте JavaScript, чтобы адаптировать URL-адрес в адресной строке к составной пронумерованной странице.

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

Предотвращение или блокировка индексации пагинации

блокировка индексации пагинации

Некоторые специалисты по SEO рекомендуют вообще избегать проблемы обработки пагинации, просто запретив Google сканировать URL-адреса пагинации.

В таком случае вам понадобится хорошо оптимизированный XML-sitemap, чтобы страницы, связанные с помощью пагинации, имели шанс быть проиндексированы.

Существует три способа заблокировать сканирование:

Небрежный способ: добавить nofollow ко всем ссылкам, ведущим на страницы пагинации.
Более чистый способ: использовать файл robots.txt для запрета доступа к пагинации.
Способ без необходимости в разработчике: установить значение параметра страницы пагинации в «Paginates» и указать Google для индексации «No URLs» в Google Search Console.

Используя один из этих методов для предотвращения индексации URL-адресов пагинации поисковыми системами вы:

Прекратите распознавание поисковыми системами рейтинговых сигналов страниц пагинации.
Предотвратите передачу внутренней ссылочной массы с страниц пагинации на целевые страницы контента.
Помешаете Google найти ваши целевые страницы контента.

Очевидный плюс в том, что вы экономите на бюджете сканирования.

Здесь нет однозначно правильного или неправильного ответа. Вам нужно решить, что является приоритетом для вашего сайта.

Лично я, если бы хотел сосредоточиться на бюджете сканирования, сделал бы это, используя обработку пагинации в Google Search Console, так как она имеет максимальную гибкость для изменения своего решения.

Отслеживание влияния KPI на пагинацию

Теперь вы знаете, что делать, как отслеживать эффект оптимизации обработки пагинации?
Во-первых, соберите эталонные данные, чтобы понять, как ваша текущая обработка пагинации влияет на SEO.
Источники KPI могут включать:

Журналы серверных файлов для определения количества сканирований пронумерованных страниц.
Оператор поиска «site:» (например, site:example.com inurl:page) для понимания количества пронумерованных страниц, проиндексированных Google.
Отчет «Аналитика поиска» Google Search Console, фильтрованный по страницам, содержащим пагинацию, для понимания количества показов.
Отчет о посадочных страницах Google Analytics, фильтрованный по пронумерованным URL-адресам, для понимания поведения на сайте.

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

Как только вы запустите свою обработку пагинации в соответствии с наилучшими практиками, повторно посетите эти источники данных, чтобы измерить успех ваших усилий.

Персонажи

Идея текста

Сюжет

План действий

Заметки

Дополнительные поля
Дополнительные поля отсутствуют