ГлавнаяРазноеWordPress SEO, базовая оптимизация

WordPress SEO, базовая оптимизация

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

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

Из этой статьи вы не узнаете о методах наращивания ссылочной массы, о правильной оптимизации текста страниц, а так же о многих других составляющих SEO. О чем же здесь будет идти речь? Об основах, о базовой оптимизации, подготовке WordPress для дальнейшей, так сказать «тонкой», настройки.

Отвечая сразу на вопрос «А что это такое вообще — базовая оптимизация?»: базовая оптимизация — это такая полезная штука, которая позволит вам сэкономить кучу времени, ресурсов и сил в дальнейшем в независимости от выбранной вами стратегии оптимизации и продвижения.

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

Не мудрствуя лукаво перейдем к сути.

Ссылки

Пермалинки или ЧПУ

По умолчанию (Настройки → Постоянные ссылки) WordPress дает постам адреса, например, в виде ?p=123. Не слишком информативная запись, не так ли?

Настройка постоянных ссылок

Настройка постоянных ссылок

Не мучайте посетителей и поисковые системы — придайте смысл своим ссылкам и повысьте значимость ключевых слов, которые вы в них используете. Я, к примеру, предпочитаю использовать такой вид:

Категория и название записи в ЧПУ

Категория и название записи в ЧПУ

Можете смело брать на вооружение, либо использовать список доступных тегов и создать свое собственное выражение.

Кириллица

Для начала, если вы работаете с сайтом с кириллическим контентом, то и названия у вас по умолчанию кириллические, равно как и URL. И все бы ничего, мы можем даже забыть про эстетическую сторону (http://www.mycoolbigshopoftea.com/зеленый-чай/в-пакетиках/ — «Привет, dear Василий! How are ты?»), но поисковики до сих пор понимают кириллицу далеко не так хорошо, как нам бы хотелось.

Плюс кириллические символы при перекодировании дают большее количество символов в URL, нежели латиница. Облегчать ли поисковикам и тем, кто не использует UTF-кодировку, задачу или нет — решать вам, но я бы рекомендовал воспользоваться, например, плагином Cyr to Lat Enhanced и перевести-таки кириллицу в латиницу автоматически, либо писать ссылки на английском вручную.

«Твоя моя понимать?»

Если публикуете действительно важную статью и используете транслитерацию в URL — не поленитесь и проверьте, правильно ли вас понимают основные поисковики.

Проверка транслитерации в Google

Проверка транслитерации в Google

Проверка транслитерации в Яндексе

Проверка транслитерации в Яндексе

Причем положительный результат в одном не является гарантией положительного результата в другом. К сожалению ГОСТ здесь не работает и поисковые системы используют собственное понимание транслитерации.

Определитесь с основным зеркалом

Проблема стара как сами поисковики, тем не менее она до сих пор требует внимания, так как они все так же иногда ошибаются, а терять из-за этого вес не очень-то хочется. Определяем для WordPress (Настройки → Общие) какой именно вариант представления нам нужен — с www или без.

Настройка адреса сайта в WordPress

Настройка адреса сайта в WordPress

После того как определились, обязательно проверьте результат, введя адрес с www и без оного. Если перенаправления не происходит, либо ваш хостер перемудрил с настройками, либо какой-то из плагинов вам придется удалить/переписать самому. В худшем случае допишите 301 редирект в .htaccess вручную, но не оставляйте этот момент без внимания.

Канонические ссылки

Так как канонические ссылки уже c 2009 года пользуются поддержкой таких компаний как Google, Yahoo и Microsoft, да и Yandex c 2011 года, было бы не правильно их игнорировать. К вопросу о том, что это такое: канонические ссылки — это маяки, которые показывают поисковым системам, какая из страниц с одинаковым контентом настоящая. Например для человека страницы с адресами:

  • http://somesite.ru/page/
  • http://www.somesite.ru/page/
  • http://www.somesite.ru/?p=1234

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

Для того, чтобы подсказать поисковой системе правильную ссылку и не потерять при склеивании безвозвратно ссылочный вес, проставляем канонические ссылки на каждой странице в виде такой вот записи в разделе <head>:

<link rel="canonical" href="http://ваш_сайт.ru/нужная_страница" />

Облегчить жизнь в данном плане и проставить все верно и автоматом могут такие плагины, как, например: WordPress SEO by Yoast или All in One SEO Pack.

Таксономии в разрезе WordPress SEO

WordPress по умолчанию предлагает вам таксономии с вертикальной (рубрики) и горизонтальной (теги/метки) иерархией. Не гнушайтесь использовать их на всю катушку.

Продумайте вертикальную структуру таким образом, чтобы пользователям было легко находить необходимый контент (чтобы вложенные категории были логично расставлены) и пользуйтесь тегами/метками везде, где можно, продумывайте их, чтобы не возникло ситуации «каждая метка — всего один пост, а всего нас 300».

WordPress подсказывает часто используемые на вашем сайте метки — пользуйтесь его помощью. Ну и, конечно, не спамьте ненужными метками там, где они не к месту.

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

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

Дублирование контента

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

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

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

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

Еще один шаг на пути базовой оптимизации, который вы можете предпринять — не выводить в ленты (loop) записи целиком. Используйте функцию the_excerpt() вместо the_content().

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

Усилить последний эффект вы можете путем написания в Цитату (Excerpt) краткого содержания поста, вместо его первого параграфа (как было бы, используй вы the_content() с отрезающей строкой <!--more--> в контенте).

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

Robots.txt

Данный небезызвестный файл в WordPress представлен в виртуальном виде. То есть по адресу http://ваш_сайт/robots.txt он появляться будет, но по факту на сервере такого файла по умолчанию нет.

В настройках по умолчанию WordPress предлагает только включить или выключить индексацию сайта полностью. Если же вы хотите более тонких настроек — все просто:

  • создайте физический файл в корне сайта. Никаких конфликтов не возникнет. Если физический файл существует, приоритет автоматически отдается ему;
  • или воспользуйтесь плагином, который позволит вносить расширенные изменения в виртуальный файл.

В плане работы с robots.txt помогут, например, такие плагины, как DL Robots.txt, WordPress SEO by Yoast или All in One SEO Pack.

Sitemap.xml

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

  • воспользоваться плагином (например: Google XML Sitemaps, WordPress SEO by Yoast, All in One SEO Pack), настроить и генерировать автоматически;
  • воспользоваться любым онлайн сервисом (просто вбейте в поисковике XML Sitemap), генерировать по запросу и размещать у себя;
  • написать вывод самому.

HEAD-поля

Из обычной троицы (Title, Description, Keywords) WordPress по умолчанию для постов и страниц поддерживает только Title (функция wp_title()), который воспроизводит название поста/страницы. Для всего остального вам понадобятся специализированные плагины, либо использование произвольных полей.

Помочь в данном случае могут следующие плагины:

Не будем забывать и про другие поля, которые могут помочь выделить наш сайт из серой массы конкурентов. В частности про Google+ Author Link. Создайте страницу в Google+ и разместите ссылку в раздел <head>, даже если у вас не авторский блог — достаточно крупный логотип вашей фирмы с дополнительно выводимыми информационными полями в поисковой выдаче явно лишним не будет.

И напоследок — Favicon, та самая, давно всем знакомая иконка. По умолчанию в ядре WordPress не поддерживается, поэтому размещаем в корень сайта сами и добавляем ссылку в раздел <head>, либо используем плагин, например: Heroic Favicon Generator.

HTML код

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

Проверьте и убедитесь, что на странице/посте вы используете только один заголовок H1, либо автоматический с использованием wp_title(), либо прописанный руками в контенте страницы. Данный совет также относится к категориям, архивам и к главной странице, если на сайте не используется разметка HTML5, и заголовки не разделены тегами <section>. Это зависит от выбранной темы оформления.

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

Атрибуты изображений в WordPress

Атрибуты изображений в WordPress

Сообщи всем (ping)

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

По умолчанию в WordPress прописан только один сервис — Ping-O-Matic. Для многих этого достаточно, но для эстетов я бы рекомендовал добавить пару сервисов дополнительно:

  • http://ping.blogs.yandex.ru/RPC2
  • http://blogsearch.google.ru/ping/RPC2
Настройка Ping-сервисов

Настройка Ping-сервисов

В заключение

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

Павел Карпов

Профессиональный интернет-маркетолог. С 2003 года занимается поисковой оптимизацией, маркетингом, аналитикой и веб-разработкой. Частый посетитель и докладчик на встречах пользователей и разработчиков WordPress в Москве.

Подписаться на рассылку

Подписаться → Подпишитесь на бесплатную рассылку журнала WP Magazine и получайте новости, события, подборки тем и плагинов, уроки, советы и многое другое в мире WordPress!

  • Pingback: WordPress SEO, базовая оптимизация | Планета WordPress()

  • Igor Atrahimovics

    Всё это базовые понятия, и нет никаких хитростей и особенностей 2014 года. Мало чего нового.

    • Абсолютная правда :) Как и было написано в названии — это исключительно базовая оптимизация, которую банально нужно знать и не упускать из виду при любом раскладе, будь вы хоть новичок, хоть профессионал. Для SEO хитростей и глубокого погружения пожалуйте на специализированные ресурсы и конференции. Ну или просто напишите мне — поболтаем за жизнь и последние SEO-тенденции :)

    • dima-f1

      полезность этого комментария зашкаливает))

  • Спасибо. Хороший ToDo лист для новичков.

  • Looler

    Спасибо Павел, подчеркнул для себя некоторые моменты, полезная статья, но вот вчера был на семинаре от CyberMarketing и там специально задал вопрос про alt и title у ссылок и картинок, на что получил ответ, что поисковики (по крайне мере Яндекс) на это не обращает внимания…!!! Не понятно все таки, кому и чему верить.

    • Vitaliy Ralle

      А семинар не дал ответ, какие критерии учитываются при поиске картинок?

      • Looler

        )))))) про это вообще ни одного слова ))))

    • Кхем, это кто ж такой добрый вам так ответил-то?…

      Во-первых, Виталий абсолютно прав, поиск по картинкам никто не отменял.

      Во-вторых, поисковики чем дальше, тем больше обращают внимание на поведенческие факторы. Вопрос на банальную логику — такой атрибут, как title, нацеленный в первую очередь на удобство пользователя — это плюс к поведенческим факторам или минус? ;)

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

      Это то, что приходит в голову навскидку…

  • Ivan Panfilov

    шел 2014 год.
    а проблема дублей по прежнему актуальна.

    http://wordpress.org/news/2014/05/wordpress-3-9-1/100/
    http://wordpress.org/news/2014/05/wordpress-3-9-1/1/
    http://wordpress.org/news/2014/05/wordpress-3-9-1/12/
    http://wordpress.org/news/2014/05/wordpress-3-9-1////12/
    http://wordpress.org/news/1///2013/10/wordpress-3-7-1/

    и по прежнему имеем какойто костыль перенеаправление урла на «правильный»

    • Ну, здесь я бы не стал огульно обвинять WordPress. Канонические ссылки — вещь не обязательная, но желательная. Плюс ко всему — кто знает, как вы захотите поиграться с дублями? Может у вас на разных URL разные виджеты будут висеть или кастомный код? Может быть вы хотите, чтобы в поисковике у вас все URL отображались бы специфическим образом.

      Как пример, навскидку:
      — на сайте пост во внутренней навигации везде используется по адресу http : //ваш_сайт/полное_название_категории/пост — для удобства навигации;
      — в поисковике вы хотите, чтобы было http : //ваш_сайт/короткое_название_категории(т.е. другая. может быть всего один или два символа)/пост — для того, чтобы в сниппет уместилось название/ключевики и т.д.

      Вариантов может быть море, и гибкость движка подразумевает известную свободу в выборе этих самых вариантов. Другими словами — плагины в помощь :)

  • dublin.rdf не упомянули

    • Неоспоримо :) Просто я счел, что микроразметка (Opengraph, Schema.org Microdata, Twitter Cards, Dublin Core…) — вещь специфическая, а не базовая. Потому я ограничился указанием в главе «HEAD-поля» плагинов (в частности — Add Meta Tags), которые облегчают ее использование при необходимости.

  • Владимир Петрозаводский

    Я все пони конечно но зачем favicon советовать корень класть, давайте

    css тоже в корень сайта вынесем , если уж в head добавлять то неужели до каталога шаблона сил не хватит путь прописать

    • О, здесь все просто :)

      Основная причина — многие браузеры жаждут лицезреть иконку именно в корне сайта и делают соответствующий запрос еще до того, как запросят и пропарсят код страницы на предмет явного указания ссылки на какую-нибудь вложенную папку. И если вас не смущает лишний 404 отклик для вашего сайта (вред и правда не большой, но…), то пачкать логи PHP этой ошибкой, особенно на проектах с высокой посещаемостью — не очень хорошо. Хотя в nginx, например, и можно прописать редирект, но нужно ли?

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

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

      • Если кому-то вдруг пригодится для nginx ;)

        rewrite ^/favicon.ico$ http://example.org/path/to/real/favicon.ico last;

        • Владимир Петрозаводский

          проблемы две если закинуть в корень иконку то :

          не факт что она в бекап попадет, так как зачастую из корня бекапит wp-config.php и все.

          иконка не будет меняться вмести с шаблоном , это тоже не очень хорошо.

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

          да и логи пачкать тоже не проблема

          location = /favicon.ico {
          log_not_found off;
          access_log off;
          }

          C wordpress.org вроде кусочек конфига.

          • Ну, тут даже спорить особо не с чем ) Иначе обсуждение рискует превратиться в холивар :) Скорее выскажу свое мнение.

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

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

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

            И да — можно исключать ненужное из логов, можно ставить редиректы, применять разные системы версионности данных, короче говоря — допиливать под себя сколько душе угодно :)

            Все это — частные случаи и дело собственной привычки и удобства. Как говорится — на вкус и цвет все фломастеры разные. Я же в статье через призму SEO старался донести варианты подходящие и исключительно полезные при их выполнении как можно большему количеству людей, что предполагает как можно меньшее количество действий вне админки. Максимум — работа с шаблонами через среднестатистический FTP доступ, даваемый большинством провайдеров. И то, в большинстве случаев до файлов так же можно дотянуться через внутренний редактор. :)

          • Владимир Петрозаводский

            Ну может в этом смысл и есть, но как по мне страны способ

  • alkiviad

    Очень полезно, спасибо

  • Если я иногда меняю темы — это как-то влияет на SEO?

    • Влияет, вопрос в том — как ;)

      Т.е. сам факт смены темы — событие не выдающееся, но вот сопутствующие изменения в коде страниц, в исполняемых скриптах — это да.

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

      • Большое спасибо, Павел.
        А если я сейчас буду в порядок приводить старые посты — это как-то отрицательно может повлиять?

        • Всегда пожалуйста, Владимир )

          Смотря что вы подразумеваете под «приводить в порядок». В принципе — конечно может, как отрицательно, так и положительно. Уменьшите плотность ключевого запроса, который приводил людей — и поток иссякнет. Этот как пример :) К сожалению более подробно ответить не представляется возможным без конкретики… Единственную общую рекомендацию можно дать — ориентируйтесь, все-таки, в первую очередь на своих посетителей. Если им удобно и интересно — остальное можно потом докрутить.

  • Игоремба

    Спасибо за статью!
    Про robots.txt хотел бы прочитать более подробно, ЧЕМ его заполнять и отчего это зависит. Может посоветуете что прочитать, а то я в нем не буб-бум, и вставив в него что-нибудь не так боюсь навредить.

    И т.к. в этом вопросе я некомпетентен хотелось бы услышать вас.

  • color4you

    спасибо

  • а мне можешь такую же статью написать про оптимизацию сайта на wp? а то я обленился вконец. я тебе заплачу сколько скажешь.

  • Автор статьи предлагает использовать такую структуру /%category%/%postname%/, а у блога урл https://wpmag.ru/2014/wordpress-seo/ Читал, что лучше не использовать в начале %category%, чтобы не тормозить систему. Где истина? Что соблюдение структуры важно, это уже поняли. А теперь нужно понять как ее задать.

    • Андрей, когда мы выбирали структуру для журнала WP Magazine мы до конца не знали, какие категории мы будем использовать на сайте, а со структурой /%postname%/ в то время были небольшие проблемы в плане производительности.

      На сегодняшний день этих проблем уже нет, и если мы когда-нибудь и решим поменять структуру на WP Magazine, то скорее всего это будет /%postname%/. Автор статьи (Павел) высказал свое предпочтение, и оно не обязательно должно совпадать с тем, что предпочитают другие авторы журнала :)

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

  • Да. По поводу субкатегорий точно сказать не могу, не пробовали с категориями, но это точно возможно. Пожалуй самый сложный вариант будет описать/дописать собственные правила через WP Rewrite API, ну а более легкий вариант возможно подскажет Павел :)

    Если честно то я бы не переживал по поводу архивов (категории, метки, даты, поиск), я редко встречал ситуации, чтобы именно архив попадал в выдачу поисковых систем. Дублирование все равно будет, т.к. у вас все равно будут пересекаться некоторые категории и метки. Если вас это не устраивает, вы можете закрыть их от индексации с помощью robots.txt.

    • Может быть и подскажу ;)
      Андрей, чтобы не болела голова, могу посоветовать такой плагин, как Redirection. Он позволяет создавать редиректы без влезания в .htaccess и вообще на сервер. Возможно вам подойдет такой вариант. Просто пропишите 301 редирект с site.ru/plagin/ на site.ru/wordpress/plagin заодно убедитесь по счетчику в этом плагине, что мало какая птица долетает до таких ссылок ) Обычно они нигде не светятся по умолчанию.

  • Дмитрий Игоревич

    Очень крутая статья,спасибо

  • Андрей

    Здравствуйте! Везде пишут что нужно использовать %category%/%postname%! Я на одном из сайтов использую просто %postname%. Как лучше прописывать?

    • Доброго времени, Андрей. Все зависит от логической структуры вашего сайта. Есть у вас там разделы с подразделами — пользуйтесь указанием категорий, чтобы не писать простыню в ссылке каждого поста и чтобы облегчить навигацию пользователям. А в случае, если у вас посты независимые логически, либо категории не несут в себе смысловой нагрузки (например /blog/ и это единственная категория, или /texts/, или /articles/ — логично, что там лежит контент, текстовый и т.д.), не используйте.

  • Aim

    Т.е. если Doctype HTML5, то присутствие в каждом анонсе, которые заключены в тег — это нормально?

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

      • Кузьмичева Мария

        Павел, подскажите пожалуйста, а что лучше для сайта при написании новых статей создавать новые СТРАНИЦЫ или новые ЗАПИСИ? Или в этом вообще нет разницы для SEO-оптимизации?

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

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

  • Pingback: Базовое SEO для WordPress - Karpov.Expert()

  • Кузьмичева Мария

    Павел, подскажите пожалуйста, а что лучше для сайта при написании новых статей создавать новые СТРАНИЦЫ или новые ЗАПИСИ? Или в этом вообще нет разницы для SEO-оптимизации?

    • Ответил ниже на тот же вопрос ;)

      • Кузьмичева Мария

        СПАСИБО БОЛЬШОЕ!