Идеальный движок с точки зрения SEO.

Группы можно сводить в категоризированный справочник :)

с 32 уровнями вложенности достаточно комфортно можно разместить около миллиона групп :)

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

Попробуем разобраться, как определяются статьи, относящиеся к данной. Как их определяет человек? Скорее всего по тематике. Но тематика будет формироваться на основе нескольких ключевых слов/фраз, правильно? Например, если статья по уходу за растениями, то можно выделить несколько слов ("уход", "сохранение", "полив", "прополка" и т.д.), которые опишут данную тематику. Если будут использоваться управляемые словари, которые будут связывать между собой ключевые слова с тематикой, тогда вопрос выбора тематики отпадает - система сама может определить, как какой теме относится статья, используя в качестве ключевого фактора большее вхождение ключевых слов из статьи в конкретную запись из словаря.

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

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

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

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

1. Он может *не уметь* пользоваться advanced search, *не хотеть*, сайт может не предоставлять продвинутый поиск пользователю (а только простой) и т.д. Но даже если он умеет, то

2. Это *его* результат поиска. Качественно другое отношение к блокам ссылок (будут это ссылки по теме, или выборка документов по тегу) - если выборка рекомендована редакцией сайта, владельцем сайта.

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

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

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

Если статьи, относящиеся к определенному тэгу, все равно отбирются редактором, то почему бы редактору при выборе статей по теме просто не воспользоваться внутренним поиском?

Я этом случае мы к статье привязываем только статьи которые уже были.

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

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

В своё время я тоже писал подобный движок. Привожу список полей для каждой контентной страницы:

Parent page - родительская папка (выбераем в виде выпадающего списка)

URL - УРЛ который потом обрабатывался с помощью mod rewrite (текстовое поле)

Title - Тайтл странички (текстовое поле)

Keywords - ключевые (текстовое поле)

Description - описание - (текстовое поле)

Author - (текстовое поле)

Replay To - (текстовое поле)

Revisit After - выппдающий список (1 Day 2 Day 3 Day 4 Day 5 Day 6 Day 7 Day 1 Week 2 Week 3 Week 4 Week 1 Month 2 Month 3 Month 4 Month 5 Month 6 Month 7 Month 8 Month 9 Month 10 Month 11 Month 12 Month )

Expires - время жизни странички (не реализовал планировал сделать календарик с выбором даты)

Distribution - выпадающий список (Global / Local)

Robots - выпадающий список (INDEX,FOLLOW / NOINDEX,FOLLOW / INDEX,NOFOLLOW / NOINDEX,NOFOLLOW)

Content language - выпадающий список (ru /en)

Pragma - (No-Cache / Cache )

Generator - (поле заполнялось автоматически назнанием движка)

H1 - то что будет заполняться для тега H1.

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

Footblock - Такой же абзац в конце странички

maintext - основной текст странички

Вообщем на то время я думал что для поисковиков хорошо когда вот так:

<html>

<head>

метатеги

</head>

<body>

<h1>Заголовок</h1>

UpBlock

maintext

Foorblock

</body>

</html>

Не притендую на то что это идеально, но может подтолкнет топикстартера на хорошие мысли и идеи.

У нас тоже так все. Только маленькая фича: если мета-данные не указаны, то они берутся от родителя. Если у родителя не указаны - буруться у более старшего предка и т.д. к корню. Таким образом получается, что "Untitled" нигде не встретится (мета-данные для корня обязателны к заполнению).

почему бы не заполнять метатеги каждой страницы автоматом, исходя из ее содержимого? Если движок для новостей, статей, каталога компаний - вообще все просто: краткое описание в Description и Keywords, название статьи (иль другого чего) в Title, H1 и URL... и т.д.