- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу

В 2023 году 36,9% всех DDoS-атак пришлось на сферу финансов
А 24,9% – на сегмент электронной коммерции
Оксана Мамчуева

Все что нужно знать о DDоS-атаках грамотному менеджеру
И как реагировать на "пожар", когда неизвестно, где хранятся "огнетушители
Антон Никонов
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Есть на странице блок, в котором будет текст. Текста может быть много. По идее, логичнее было бы сделать скроллбар справа и все дела. Но мне говорят, что скролл очень плохо влияет на последующую раскрутку и хотят, чтобы я сделал постраничный вывод.
Т.е. в базе изначально просто текст, без всяких идентификаторов (за которые можно было бы зацепиться). Я так себе представил, что можно теоретически посчитать слова в тексте и выводить на каждой странице по X слов... как это будет выглядеть, и оправдано ли это вообще - не представляю... да, ещё... при постраничной навигации ID самой страницы обычно кладётся в GET. Т.е. URL приобретает вид: file.php?page=4. Кто как думает, реально ID страницы спрятать в POST? Потому что там всё делается аяксом и GET в принципе недопустим.
И про скролл. Он действительно тормозит раскрутку? Я просто реально не понимаю... Имеется в виду не общий скроллбар, а скролл отдельного элемента (к примеру DIVа) на странице. Т.е. конструкция такого вида:
Всем спасибо за ответы.
Скролл нет, кол-во текста на странице возможно, "простыни" ПС не очень жалуют.
Судя по вашему отношению к контенту на вашем сайте, сайт ГС ? :)
Кто как думает, реально ID страницы спрятать в POST?
Будут те же проблемы, что и у сайтов на фреймах - страниц много, адрес один, трудно ссылаться на конкретные страницы. Скролл ничего не тормозит - это элемент дизайна, если уместен - ставьте.
edka
Я из вашего ответа не понял ничего... какой ГС? Что значит "скролл нет"?... Можно более конкретно написать? :)
Просто часто в таких блоках прятали большие сео-тексты, потом за это стали наказывать. В общем-то, не за скролл, а за поисковый спам.
Как уже выше сказали - "простыни" не есть гуд.
Наличие скролла как такового на продвижение не влияет, главное, чтобы текст на странице был более читабельный.
Насчет аякса и GET - погуглите, но не разу не слышал, чтобы они были несовместимы.
А вот передача номера страницы POST'ом - не вариант... Сами потом запутаетесь, какая страница у вас сейчас открыта, и ПС ничем хорошим на такие манипуляции не ответит... Все-таки, если делать постраничку, то только GET'ом
А почему бы не загружать весь код, а аяксом обновлять при прокрутке?
ЗЫ... Сори, не могу конкретно сформулировать свои мысли. Надеюсь меня поняли)
А почему бы не загружать весь код, а аяксом обновлять при прокрутке?
ЗЫ... Сори, не могу конкретно сформулировать свои мысли. Надеюсь меня поняли)
Для ПС это всеравно будет простынь :)
Т.к. весь контент будет уже загружен на одной странице и ею проинексирован.
Я понял всех...
А как тогда реализовать? Предположим имеется текст в базе в виде HTML. Беру, убираю HTML-разметку, получаю голые слова. К примеру их Y штук. И на странице будет X слов. Соответственно количество страниц равно Y/X. Это понятно. Но текст будет браться из базы единым запросом. Что ж его теперь, на клиенте парсить что ли?? Или принцип постранички в этом случае вообще не такой? Мне бы хотя бы пример сайта, где такое реализовано... ибо я реализовывал постраничку, но там имелась чёткая структура - X записей по Y записей на каждую страницу, X/Y страниц и запрос типа SELECT * FROM table WHERE param = value LIMIT X, Y. Как-то так... а вот с таким видом постранички ни разу не встречался...
mark2011
На вскидку могу предложить такие варианты:
1. Когда добавляете статью в систему (через админку) сделать несколько полей для текста, чтобы админ сайта сам разбивал на фрагменты, и отслеживать длину фрагмента, чтобы не превышала максимальную. После ввода записываете в базу фрагменты отдельными записями, связывая их по доп. ключу и при постраничном выводе отображать соответствующий фрагмент.
2. Если админ сайта ленивый и не хочет вручную разбивать статью на фрагменты, то можно принудительно разбивать текст на фрагменты и хранить опять же в виде отдельных записей в БД. Но здесь возможны проблемы, особенно, если админ любитель оформления текста (часто использует <span>, <font> и т.д.), то деление на фрагменты может разрезать эти теги... да и слова может разрезать... так что, если необходим такой вариант, то придется продумать систему фрагментации текста...
Это на вскидку, так сказать пришло в голову без лишних размышлений
Для ПС это всеравно будет простынь :)
Т.к. весь контент будет уже загружен на одной странице и ею проинексирован.
То что подтянуто аяксом поисковик не увидит. Он JS не понимает.
--
Хранить HTML разметку в базе это не верно в корне. Только если отдельная новость, "Куском".