Официальный сайт движения «Москва без Лужкова!»
Главная Новости Москвы Наши новости Популярное
  • Новости
  • Новости
  • ВХОД В ЛИЧНЫЙ КАБИНЕТ
    логин
    пароль
       
    Новости

    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» как возможную категорию. Он оценивает по порядку в своем списке возможных 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, которая имеет много способов использования, кроме блогов: структуры страниц, пользовательские посты, пользовательские таксономии, различные плагины и т. Д.

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

    Это то, что мы можем проверить при просмотре, увидев, что наши страницы выглядят как "/?
    Что происходит, когда предмет доступен сразу в нескольких категориях?
    Цыпленок в "/ animals / chick" или в "маленькие вещи / цыпленок"?
    О мне делать?
    А теги?
    Что должен делать WordPress, когда мы называем «/ animals / small»?
    Как это решить?
    Какие варианты у нас остались?
    Это все SEO, что можно сделать с помощью блога?

     

    Найди свой район!

    Восточный

    Западный

    Зеленоградский

    Северный

    Северо-Восточный

    Северо-Западный

    Центральный

    Юго-Восточный

    Юго-Западный

    Южный

    Поиск:      


     
    Rambler's Top100
    © 2007 Движение «Москва без Лужкова!»