EAMann
  • 0
Гуру

Внедрение Pillar Posts; Длинные посты уже обработаны как страница?

  • 0

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

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

У меня есть серия статей, которые я планирую написать в течение следующего месяца или около того о XML-RPC API, встроенном в WordPress. Это замечательная система, но скудно документированная… так что я собираюсь собрать исчерпывающую документацию по методу.

Дело в том, что мои документы будут охватывать примерно 5-6 различных постов. Я хочу, чтобы этот контент отображался в моем блоге, когда он будет опубликован (раз в неделю), но я также хотел бы, чтобы вся серия повторялась в виде статической страницы на сайте. Статическая страница будет разбита на отдельные страницы (используя <!--nextpage--> для разделения разделов), чтобы каждый пост содержался в другом разделе.

Как мне сделать так, чтобы избранный контент был как отдельными сообщениями в блоге, так и отдельной статической страницей? Я рассматриваю здесь как удобство использования, так и SEO… дублирование контента — огромный минус, поэтому простая работа по копированию и вставке обеих версий на сайт не является моей целью.

Моей первой мыслью было бы разработать собственный тип записи для таких функций с собственной пользовательской таксономией. Каждое «сообщение» будет отдельной функцией (настраиваемый тип сообщения) и будет принадлежать серии (настраиваемая таксономия). Затем каждый пост может быть включен в петлю при публикации, а также на странице архива серии.

Итак, мой вопрос (и причина, по которой я помечаю это как вики): как бы вы поступили в этой ситуации?

Share
  1. Когда я читал ваш пост, я представлял почти то же самое, что вы прописали в конце:

    Моей первой мыслью было бы разработать собственный тип записи для таких функций с собственной пользовательской таксономией. Каждое «сообщение» будет отдельной функцией (настраиваемый тип сообщения) и будет принадлежать серии (настраиваемая таксономия). Затем каждый пост может быть включен в петлю при публикации, а также на странице архива серии.

    Единственная разница заключалась в том, что я думал «Страницы» вместо «Функции» в основном потому, что в своем вопросе вы упомянули «Страницы», но «Функции», вероятно, даже лучше.

    Так что ваши инстинкты уже на месте, ИМО в любом случае.

    • 0
    • Как я на самом деле это делаю: пользовательская таксономия, называемая «серией»… сообщения могут быть в серии и будут упорядочены по дате (в обратном хронологическом порядке). Пользовательский тип поста/страницы под названием «Серия» — каждый пользовательский пост/страница просто отображает каждый пост в соответствующей таксономии «серии» в обратном хронологическом порядке. Сообщения по-прежнему публикуются, но к ним легко получить доступ как к «страницам» на статической странице архива серии.

      • 0
  2. Вы можете создать статическую страницу с собственным циклом, вызывающим только сообщения, принадлежащие вашей серии. Или, что гораздо проще, создайте пользовательскую таксономию «ряд» и используйте для цикла the_content() on( ) вместо./series/xml-rpc/ the_excerpt()

    • 0

Оставить ответ

You must login to add an answer.