SEO на странице: веб-структура в WordPress (категории, URL-адреса и ссылки)

1. Шаг 1: Дружественные URL и .htaccess
2. Шаг 2: Давайте забудем о мультикатегоризации
3. А теги?
4. Шаг 3. Реализация наших URL на основе категорий
5. Но не все идеально: классическая проблема «страница не найдена»
6. Шаг 4. Некоторые правила, чтобы понять нашу тему
7. Мы не можем позволить себе ссылаться на все всегда.
8. Хорошо пометить связь сообщений с их категориями и тегами
9. и, наконец, избегайте всех возможных ссылок на вторичные URL-архитектуры, которые обрабатывает WordPress.
10. И это все, что я должен сказать ...

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

Как всегда, мы перейдем от основ к деталям ...

Шаг 1: Дружественные URL и .htaccess

Это важный момент любой разработки PHP с дружественными URL. WordPress при его установке по умолчанию не будет использовать эту систему. Это то, что мы можем проверить при просмотре, увидев, что наши страницы выглядят как "/? P = 123" вместо "/ my-dear-and-nice-post".

Я не буду особо интересоваться, как активировать дружественные URL-адреса, поскольку это довольно просто: просто зайдите в администраторе в «Настройки»> «Постоянные ссылки» (постоянная ссылка - как wordpress вызывает дружественный URL-адрес) и выберите в своей структуре сообщений нечто иное, чем опция «По умолчанию». Если все пойдет хорошо, в вашем проекте будет создан файл .htaccess, и все внутренние URL-адреса WordPress будут обновлены.

Примечание для программистов. Это обновление важно для тех, кто воспроизводит код или выполняет расширенные темы. Любое изменение URL-адресов, которое вы вызываете с помощью кода, не приведет к обновлению базы данных, если вы не примените это обновление URL-адресов. Чтобы спровоцировать это в плагинах у нас есть функция flush_rewrite_rules но для небольших изменений всегда будет быстрее перейти в Настройки >> Постоянные ссылки и вернуться к сохранению.

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

Предотвращение существования сети в нескольких доменах / поддоменах одновременно

Это типичная проблема. Я устанавливаю свой веб-сайт на mibonitodominio.com, и получается, что я могу получить к нему доступ через mibonitodominio.com и www.mibonitodominio.com. Это не слишком проблематично в SEO, так как поисковые системы настолько привыкли к такого рода проблемам, что не ставят много недостатков, чтобы делать это неправильно. Проблема возникает из-за возможной потери ссылок между версиями. Когда у нас есть веб-сайт с двумя разными типами URL, мы не знаем, какой из них будет считаться действительным со стороны Google, а что хуже, мы не знаем, какие из них будут ссылаться на те, которые упоминают нас. Хотя Google признает, что сеть одинакова, у нас нет доказательств того, что ссылки, которые ведут на ту или иную версию сети, учитываются при размещении одного и того же документа. Что мы знаем, так это то, что, как правило, если на нашей странице есть дублированный контент, и мы отправляем ссылки на обе версии, в результате мы теряем авторитет в этом контенте. Так что лучше всего не искушать алгоритм и не помещать в него простые вещи: это видят только веб!

Поэтому нам нужно выбрать только один из двух адресов для нашего сайта. Для меня лично использование 3W в новом домене касается моего носа. Мы должны знать, что наш реальный домен - это тот, который появляется ни перед чем, и это «www». является поддоменом этого основного домена, поэтому мы фактически предоставляем два разных адреса поисковым системам для нашего сайта. В прошлом для того, чтобы серверы знали, о чем их просят, был принят обычай инициировать часть сети с помощью «www» (World Wide Web), оставляя основной домен для более важных или просто блокирующих доступ. Но когда мы используем домен непосредственно для размещения веб-сайта (99,9999% случаев), это больше не имеет никакого смысла.

Поэтому для меня правильный адрес всегда должен быть без www. Но мы уже знаем, на что похож мир. Я также встречал клиентов, которые говорят вам, что вы сделали неправильный веб, потому что он не начинается с www ... поэтому я дам вам различные способы устранения дублирующих сайтов с помощью htaccess:

Удалить любой поддомен из домена:

# удалить субдомены RewriteCond% {HTTP_HOST} ^ [a-zA-Z0-9 -_] + \. mibonitodomain \ .com $ [NC] RewriteRule ^ (. *) $ http: // mibonitodomain / $ 1 [R = 301, QSA, L]

Удалить только если поддомен www

# удаляем www RewriteCond% {HTTP_HOST} ^ www \ .mibonitodomain \ .com $ [NC] RewriteRule ^ (. *) $ http: // mibonitodomain / $ 1 [R = 301, QSA, L]

Добавление www в домен, в котором их нет:

# add www RewriteCond% {HTTP_HOST} ^ mibonitodomain \ .com $ [NC] RewriteRule ^ (. *) $ http: //www.mibonitodomain/$1 [R = 301, QSA, L]

Добавьте интересующую вас часть (заменив mibonitodominio.com своей) перед частью «RewriteCond» вашего htaccess.

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

Устранение "/" в конце URL

Еще один неприятный аспект, который иногда случается, заключается в том, что мы позволяем WordPress создавать URL с символом «/» в конце. Это то, что происходит во многих WordPress, так как панель постоянных ссылок предлагает вам создать этот тип URL-адресов (проверьте страницу Настройки> Постоянные ссылки, и вы увидите, как предлагаемые URL-адреса автоматически заканчиваются на "/").

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

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

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

# удалить / конец URL RewriteCond% {REQUEST_FILENAME}! -d RewriteRule ^ (. +) / $ / $ 1 [R = 301, L]

Примечание: будьте осторожны, чтобы не добавлять это перед изменением URL-адресов и удалением папки «/» в конце, иначе ваши страницы перестанут работать, так как htaccess перенаправит на страницу без «/», и WordPress будет понимать их только с «/» в конце ,

Шаг 2: Давайте забудем о мультикатегоризации

Категории: мало и очень хорошо продумано

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

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

Например, если у меня есть «цыпленок» в категории «животные», то ясно, что мой окончательный URL должен быть что-то вроде «/ animals / chick».

Но когда по какой-то причине я думаю, что категория «мелочи», если я классифицирую свою цыпочку в обеих категориях одновременно, это когда я не знаю, как создать URL. Цыпленок в "/ animals / chick" или в "маленькие вещи / цыпленок"? Понятно, что оба одновременно я не могу оставить его, потому что это будет дублированный контент ... что мне делать?

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

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

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

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

Это сделало бы нашу любимую цыпочку теперь такой URL-адресом:

"/ животные / маленький / цыпленок"

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

А теги?

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

Шаг 3. Реализация наших URL на основе категорий

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

Мы снова возвращаемся в «Настройки»> «Постоянные ссылки» и настраиваем WordPress для работы так, как мы хотим:

• Мы указываем, что наша структура сообщений: "/% category% /% postname%"
• В категориях мы теперь указываем, что URL - это «./», что заставит WordPress удалить ужасную папку «/ category» из наших URL.
• В тэгах я оставляю это на ваше усмотрение, в зависимости от того, как мы их используем, формулы или другие могут иметь больше смысла

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

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

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

- "/ животные / маленький / цыпленок".

Попробуй это! Это просто ...

Но не все идеально: классическая проблема «страница не найдена»

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

Проблема в том, что с URL-адресами, которые я предлагаю, вы можете ошибиться при выполнении этого обнаружения. Давайте посмотрим, URL-адреса категорий ("/ animals" и "animals / small") не слишком отличаются от почтовых, особенно если мы смешиваем сообщения, связанные с более низкими или более высокими категориями.

Пример:

Представьте, что вы создаете пост под названием «Pequeños» и включаете его в категорию «животные». Что должен делать WordPress, когда мы называем «/ animals / small»?

Я скажу вам, что он делает:

Он оценивает по порядку в своем списке возможных URL-адресов и обнаруживает, что сообщения могут иметь этот URL-адрес, поэтому ему никогда не удается оценить «/ animal / pequenos» как возможную категорию.

Как это решить?

Основа проста: мы должны избегать того, чтобы WordPress мог понять, что сообщение имеет тот же URL-адрес, что и категория, поэтому мы должны немного различать URL-адреса.

В категориях мы немного привязаны, потому что, поскольку администратор позволяет нам редактировать только вашу предыдущую папку (которую мы удалили, указав ее как «./»), мы не можем ничего сделать, чтобы отличить эти URL-адреса от URL-адресов постов.

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

Какие теги добавить в конец URL-адреса публикации

Там идет больше к вкусам или убеждениям каждого из них. Я просто указываю некоторые варианты, которые вы можете выбрать, и какие преимущества будет иметь каждый из них:

• Расширение .html

  Следуя теории, что URL-адреса являются каталогами, конечные файлы могут иметь отличное расширение. Это была довольно распространенная практика несколько лет назад. Вы добавили расширение «.html» или «.htm» в конец своих страниц и таким образом «обманули» поисковую систему, заставив его подумать, что эта страница статична (сделана вручную, а не с помощью программирования), и теоретически он имел это в виду. Правда состоит в том, что эта теория имела небольшой вес (как будто Google не знал, что существует ModRewrite), и в настоящее время для сохранения символов предпочтительно не включать никаких расширений. Но это не значит, что это неправильно. Это немного старомодно, но это правильно.

  - Настройки WordPress: "/%cacategory%/%postname%.html"
  - Тип URL: "/animales/pequenos/pollito.html"
  - Преимущества: на уровне структуры сайта это правильно, и мы не добавляем больше семантики.
  - Недостатки: устаревшие ссылки и потеря нескольких персонажей.

• Название страницы или ключевое слово

  В настоящее время многие стратегии ключевых слов SEO в блогах включают тег в заголовки в конце страниц. В подавляющем большинстве случаев это либо название сети (если применимо), либо лучшее общее ключевое слово того же типа. Поэтому, если у меня есть блог о Windows 8, я могу захотеть, чтобы все мои заголовки были «[post name] | Windows 8». Если мы будем применять эти методы, было бы не так странно, что URL-адреса также заканчивались добавленным заголовком, что решало проблему соответствия.

  - Настройки в WordPress: "/% category% /% postname% -title -writ-by-you"
  - Тип URL: "/ animals / small / chick-title-by-you-you"
  - Преимущества: URL-адрес по-прежнему актуален, без каких-либо странных вещей и поддерживает весь заголовок
  - Недостатки: потеря семантики для одновременной ставки на весь заголовок и трудности с изменением слогана через некоторое время (так как все URL будут изменены)

• ID сообщения

  Другой типичный способ решения этой проблемы - добавление идентификатора записи в конец URL-адреса, чтобы избежать конфликтов. Это также должно ускорить внутренние консультации (по идентификатору, а не по имени), хотя я не могу вас заверить на 100%. Предупреждение, только ID не будет достаточно, мы должны будем добавить что-то еще (например, «р», а затем идентификатор).

  - Настройки в WordPress: "/% category% /% postname% -p% post_id%"
  - Тип URL: "/ animals / small / chick-123"
  - Преимущества: это в меру естественно для пользователя и добавлено несколько символов
  - Недостатки: можно добавить еще меньше персонажей. Когда блог растет, это не странно, чтобы найти идентификаторы из четырех или пяти цифр.

• Символ: «_», «-» и т. Д.

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

  - Настройки в WordPress: "/% category% /% postname% _"
  - Тип URL: "/ animals / small / pollito_"
  - Преимущества: мы добавляем только персонажа для достижения дифференциации
  - Недостатки: на самом деле это техническая хитрость, которая для всех эффектов «плохая», и это может привести к тому, что при копировании ссылки некоторые пользователи удаляют ее, не понимая ее.

• Переверните предыдущие три

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

  - Настройки в WordPress: "/% category% / item-extra-% postname%"
  - Тип URL: "/ animals / small / element-extra-chick"

Как вы можете видеть, есть много вариантов - и даже больше, чем вы можете себе представить (например, с переменными даты или автора), но ни один из них не является абсолютно чистым. Жаль, что WordPress не решает эту проблему по-другому, но мы играем с инструментами, которые нам даны, и нужно сказать, что проводить оптимизацию структуры только с двумя добавлениями в файл и прикосновением к форме - роскошь. Я нашел CMS, в которых вам приходилось делать гораздо более сложные / дрянные вещи, чтобы идентифицировать URL, и мы больше не говорим об организации контента ...

Шаг 4. Некоторые правила, чтобы понять нашу тему

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

Мы не можем позволить себе ссылаться на все всегда.

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

Поэтому:

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

- Избегайте ссылок на теги из структуры страницы.

- Если мы используем категории с несколькими уровнями, мы не представляем их все в меню, только основные.

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

Хорошо пометить связь сообщений с их категориями и тегами

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

Поэтому:

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

- Давайте хорошо пометим эти ссылки тегом rel = "tag" (по умолчанию многие функции WordPress уже удаляют эти ссылки).

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

и, наконец, избегайте всех возможных ссылок на вторичные URL-архитектуры, которые обрабатывает WordPress.

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

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

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

И это все, что я должен сказать ...

Мы дали небольшой обзор того, как организовать структуру постов в WordPress, хорошо организованную для поисковых систем и пользователей. Это все SEO, что можно сделать с помощью блога? Нет, совсем нет, а тем более - с платформой Worpdress, которая имеет много способов использования, кроме блогов: структуры страниц, пользовательские посты, пользовательские таксономии, различные плагины и т. Д.

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