улучшение формирования дескрипшена

предлагаю улучшить сабж

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

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

во вторых, в плане настраиваемости длины деска, например - N слов, плюс-минус некоторое количество слов до конца текущего предложения

нынешняя длина маловата, на мой взгляд

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

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

description влияет на позиции.

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

Вроде 255 символов было или что-то около того.

Обрезание на полуслове точно плохо влияет.

description влияет на позиции.

Если с этим еще можно поспорить. Есть мнение по поводу одной и другой позиции, в частности мне нравится этот эксперимент: http://sosnovskij.ru/keywords-description/

Обрезание на полуслове точно плохо влияет.

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

Я не против реализации этого предложения, просто как по мне - так это обычная трата времени, тем более учитывая то, что далеко не всегда первые 200-255 символов несут важные ключевые слова для страницы.

Я проводил эксперименты на десятке своих сайтов, после прописывания метатегов посещалка выросла в 1.5-3 раза.

дело в том, что деск используется при импорте в статику, если установлена галка "выводить список статей в тексте категории"

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

а тэгом description я вобще не пользуюсь

Я проводил эксперименты на десятке своих сайтов, после прописывания метатегов посещалка выросла в 1.5-3 раза.

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

Грубое обрезание текста по количеству символов более быстрое решение. Если искать конец слов/предложений и еще делать какие-то манипуляции - это замедлит процесс создания каждой отдельной статьи. Возможно на десятках текстов это не будет заметно, но при импорте тысяч и более - скорость значительно ухудшится. Так ли оно надо?

дело в том, что деск используется при импорте в статику, если установлена галка "выводить список статей в тексте категории"

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

а тэгом description я вобще не пользуюсь

Для создание короткой новости при экспорте в статику более рационально использовать расстановку тега <!--more-->. Там и количество символов можно контролировать и по чем обрезку делать (по концу слова, предложения или абзаца).

Грубое обрезание текста по количеству символов более быстрое решение. Если искать конец слов/предложений и еще делать какие-то манипуляции - это замедлит процесс создания каждой отдельной статьи. Возможно на десятках текстов это не будет заметно, но при импорте тысяч и более - скорость значительно ухудшится. Так ли оно надо?

Можно сделать опционально.

Это я понимаю, но уже сейчас во всех тонкостях настройки программы разбираюсь только я один, и увеличение количества переключателей не способствует исправлению ситуации. То же самое было с картинками: меня долго спрашивали какого лешего программа во время экспорта берет все картинки проекта, а не только те, которые используются в статьях, а я долго объяснял, что скорость экспорта при проверке сильно упадет. Сошлись на том, что нужно сделать это опционально. Я сделал, а потом появилась эта тема в разделе багов: viewtopic.php?f=6&t=1415 Пользователь в принципе не мог предположить, что причина его проблемы - активированный переключатель в настройках и я это понимаю.

А теперь скажите мне: действительно ли это такая необходимая фича ради которой я должен тратить время на разработку, а потом время на решение "проблем", которые могут появится у пользователей (и которые, как показывает опыт, обязательно появятся)?

я и не знал, что ещё тег <!--more--> снипеты регулирует в статике

тогда вопрос снят