А даст ли яндекс?
Т.е. есть сайт, делаем по нему запрос, показать ссылки, получаем:
Результат поиска: страниц — 1 244, сайтов — не менее 357
Тыкаем на ссылку страницы номер 8 внизу вот этой первой страницы, получаем:
Результат поиска: страниц — 1 237, сайтов — не менее 89
При этом фактически то я знаю, что цифра: сайтов — не менее 357 более или менее похожа на правду.
И совсем непонятно, по какому поводу он куда-то хренакнул 3 из 4-х ссылок. Т.е. судя по первой странице, физически он их знает, но судя по следующим, показывать их не хочет.
Насколько я знаю, ХМЛ отдается такой же как на основной выдаче. Так что получить реальную картинку не получится.
Если же ориентироваться, что яндекс показывает только те ссылки, которые он учитывает в настоящий момент, то тут вообще затея становится полностью нецелесообразной, т.к. еще выкачать базу не успеем, а яндекс успеет поменять алгоритм учета ссылок.
Эксперимент действительно не очень корректен, т.к. уже давно поисковики заявляли, что содержание невидимых пользователю элементов не влияет на ранжирование, если нужное слово не присутствует в видимой части документа.
Для написанного однозначно SSI. В момент создания в потенциальных местах ставим строку:
<!--#include virtual="radv/toprekl.inc"-->
В radv/toprekl.inc вписываем сначала (неразрывный пробел)
И не забываем поменять .htaccess в тот момент когда надо начать парсить SSI инструкции.
minaton,
Евген,
Или же разумная оценка качества своих текстов:), при этом не исключено, что завышенная.
Написано хорошо, но, в основном, с точки зрения человека, оперирующего деньгами клиента и, возможно, получающего от количества переходов. При повышении СТР таким образом, примерно аналогично падает конверсия.
Если вы человеку сразу написали цену, то он не попрется к вам на сайт, эту цену просто посмотреть. Хотя если на сайте есть какой-то эксклюзив, то, возможно, такое и хорошо работает.
========
Написал, а потом понял, что нужна еще оговорка:
то, что описано возможно не плохо работает и конвертируется в темах без конкуренции. Когда там 1-2 объявления и в основной выдаче всякий хлам.
Возможность подправить не только текст, но и урл, куда отправлять посетителя.
Наиболее эффективно в объявлении:
1. Полностью введенная пользователем фраза (при неоходимости преобразованная в правильную с точки зрения русского языка БЕЗ исправления грамматических ошибок).
2. Цена (полностью соответствующая тому, что на сайте, лучше по телефону объяснить, где собака зарыта)
3. Бренд - если есть, если нет, но ОЧЕНЬ хочется продвижения бренда - то можно рассмотреть вариант, но лучше обойтись без него - места мало.
4. Особенность, которую ожидает потребитель:
Правильно:
- от производителя
- охлаждает идеально (кондиционер)
- множество навороченных функций (мобильник для тинейджера)
- очень мягкое и впитывающее (полотенце из бамбука)
Не правильно:
- на 20% больше функций (кондиционер)
- множество навороченных функций (мобильник для делового человека)
- на 70% гигроскопичнее хлопкового (полотенце из бамбука)
Ну и по уму переход должен идти на страницу, которая сделана именно под эту фразу, с обязательным ее использованием и возможно некоторой корректировкой текста (обычно совсем небольшой). Правда под яндекс такое делать напряжно (как и п.1), из-за их особенностей по созданию кампаний. В этом отношении бегун с его возможностью отправлять с каждой фразы на НУЖНУЮ страницу и делать нужное описание выглядит более удобным. Яндекс же считает, что это спамят его поисковик, а не повышают конверсию продаж.
В яндексе конечно можно делать тоже самое, но число кликов и перезагрузок страниц там получается просто дикое - лично мне приходится обходиться компромисами.
Однако доверчивость оптовых заказчиков - просто на высшем уровне. Все представляют, что такое лесной бизнес в России. Как только речь заходит о постоянных поставках, сразу идет требование показать СВОИ СОБСТВЕННЫЕ лесопилки и склады.
Vladimir_Rublin
Варианты возможны всякие, по мелочи, но до хрена. С учетом того, что скрипту дается право писать, что-то, то там сразу появляются проблемы. Доступ к клиентскому скрипту имеет любой, поэтому увидеть внутренности можно без проблем. Если уж PHPBB регулярно вскрывают (а сколько он уже в разработке), то с самопальным клиентом надо быть очень осторожным.
Мы просто сейчас запускаем подобную вещь и именно с клиентской частью и именно с кэшированием (правда там кэшируется несколько с другими целями). Мы два месяца не можем выпустить готовый продукт, т.к. постоянно находятся какие-то дыры в безопасности (внешне проект был готов в начале мая). И это при том что проект на перле, который несколько более удобен в плане безопасности, чем ПХП.
Затрахаешься писать проверку, ту ли информацию выдает клиент, что необходимо. А с тем количеством "умников", что у нас есть, без проверки никак нельзя.
Плюс при ресурсоемкой генерации контента могут случаться накладки, при этом черт его знает, когда он обратится следующий раз. Мы использовали активацию скрипта клиента с основного сервера, когда он будет готов. При этом скрипт только активируется, и сам генерирует запрос на основной сервер, после чего и получает нужные данные.
Сравнивать подобные вещи вообще нереально. Все зависит от кривости рук программиста. Разница в ресурсоемкости скриптов может отличаться очень круто. Т.е. в зависимости от степени оптимизации время на обработку может раста как в виде N*ln(N), а может запросто быть и N^2 или N^3. И не посмотрев, что до этого писал программист и как оно работает, практически невозможно даже близко прикинуть сколько потребуется ресурсов.
Решение с кэшем на самом деле не такое уж и простое. С точки зрения снимания ресурсоемкости с сервера - да, но с точки зрения усложнения клиента, и главное его безопасности, начинаются большие вопросы. Плюс еще и на сервере требуется кучу всего дописывать, иначе можно получить еще как минимум один вид неприятных последствий.
Кстати если заморачиваться с кэшем в подобных проектах, то реализация должна быть сделана по другому, а не как описывается выше.
