Каталог статей
| Главная » Статьи » помощь веб-мастеру |
| В категории материалов: 123 Показано материалов: 93-96 |
Страницы: « 1 2 ... 22 23 24 25 26 ... 30 31 » |
Сортировать по: Дате · Названию · Рейтингу · Комментариям · Просмотрам
-
Автор: uMaster Получить ссылку
В новом окне Просмотров:[638]
Добавлено:07.10.2009
Подробнее
Эффективный способ поиска на сайте > помощь веб-мастеру
Анализируя web-сайты в сети Интернет, можно сделать только один вывод: очень нехорошая ситуация складывается с поиском по интернет-ресурсу. Реализованный поиск на web-сайте либо плохо справляется с сортировкой и обработкой пользовательских запросов, либо не работает, а иногда он вообще отсутствует.
Поиск на web-сайте нужен, поскольку он должен выполнять следующие задачи:
- обеспечивать альтернативную навигацию;
- делать доступными архивы сайта и получение информации с них;
- позволять увеличить активность посетителей на сайте, делая его более дружественным и привлекательным;
- представлять собой удобный сервис для профессионалов.
Поиск нужен не на всех сайтах. Например, в нем нет необходимости на сайтах-визитках компаний, для имиджевых проектов. В то же время для корпоративных web-сайтов он полезен. Если говорить о ресурсах средств массовой информации, то важность поиска здесь неоспорима. Для контентных проектов (сайтов, которые наполнены полезной информацией) поиск на сайте просто необходим. Для различного рода порталов поиск – это один из ключевых сервисов для пользователя.
Выбирая движок, нужно учитывать следующие факторы, характеристики и параметры:
- ранжирование. Нужно определиться с тем, какие сайты должны занимать верхние уровни, а какие должны быть отранжированы по релевантности, а также по зоне;
- поддержка документов различных форматов. Безусловно, поисковые системы анализируют документы в распространенном формате html, но не следует забывать о текстовых документах в форматах pdf, doc;
- скорость обновления. Если речь идет о новостном web-сайте, то очень важно, чтобы время публикации новости, а также время, когда она попадает в индекс, были минимальными. Кроме того, поисковый индекс должен обновляться не реже одного раза в день;
- учет всех разделов web-сайта;
- подавление дублей с помощью навигационной обвязки. Если говорить о новостной ленте, то часто одна и та же новость дублируется в разных разделах web-сайта. Реализованный поисковик должен уметь выявлять и группировать такого рода дубли;
- расширение запросов;
- высокое качество сниппетов. Если поисковая система реализована грамотно, то она должна выделять качественный сниппет, который доступен для понимания широкой аудитории пользователей;
- морфология. В том случае, если на web-сайте есть возможность выбора языка или используется не один язык, тогда поисковая система должна дополнительно эффективно определять язык запроса пользователя на сайте.
Перед тем, как организовать поиск на web-сайте, полезно знать, какие есть виды поисковых систем для установки на интернет-ресурсе:
1. Крупные поисковые системы. Они подходят в том случае, если нет необходимости управлять ранжированием.
2. Поиск по web-сайту, что встроен в CMS.
3. Средства реляционных систем управления базами данных. Данный вид поиска очень удобен для разработчиков сайта. Они характеризуются тем, что есть ограничение на количество документов, по которым осуществляется поиск, кроме того, каждый из документов должен находиться в БД (базе данных).
4. Внешний поисковый сервис. Этот вид поиска характеризуется тем, что данные представляются в определенном формате – xml. Внешний поисковый сервис заходит на web-сайт снаружи. Недостатком такого вида поисковой системы является то, что они не выделяют мета данные, что связаны с документом.
5. Другие поисковые продукты. Как правило, возникает сложность с их настройкой. Данный вид поисковых систем может быть свободным и коммерческим.
Организация поиска на web-сайте невозможна без оценки его качества. Чтобы осуществить контроль, необходимо оценить полноту и точность поиска – это формальные оценочные параметры, что может использовать разработчик. Качество поиска определяется отсутствием дублей и прочего навигационного «мусора», временем появления документа в поисковом индексе. Следует также обратить внимание на сниппеты.
Тем разработчикам, которые раздумывают о необходимости поисковой системы, следует знать, что ее можно использовать очень эффективно необычными способами: для перелинковки web-сайтов, организации каталога, связывания между собой статей, осуществления поиска по чужим web-сайтам.
Перелинковка web-сайтов осуществляется с помощью создания словаря тематических запросов из предметной области интернет-ресурса. Термины такого словаря запросов хорошо использовать для создания соответствующих ссылок из всех документов web-сайта на поисковую выдачу по конкретному запросу.
Организовывая поиск на web-сайте, следует знать о таких новых возможностях как кластеризация результатов поиска, эффективные интерфейсные решения. Как пример, можно назвать Quintura, которая не является пассивной, а активно предлагает пользователю варианты выдачи на его запрос, учитывает все пожелания, затем, анализируя найденную информацию, снова предлагает варианты выдачи. Еще одной инновационной возможностью является реферирование документов поисковой выдачи, возможность показа краткой выдачи.
Выбирая поисковую систему для собственного сайта, следует, в первую очередь, ориентироваться на круг задач, требуемых решения, а также предоставляемые ею возможности.
-
Автор: uMaster Получить ссылку
В новом окне Просмотров:[800]
Добавлено:05.10.2009
Подробнее
Кэширование сайта > уроки
Наверняка, передвигаясь по Интернету вы замечали, что одни сайты работают быстрее других. В некоторых случаях это не очень заметно и критично, в других - просто кошмарно - мне как-то попался сайт, на котором каждая страница грузилась минуты по три (специально замерил!), причем он отнюдь не был чем-то гигантским... С другой стороны браузера - у веб-мастеров - тоже возникают кучи проблем: серверу постоянно не хватает ресурсов, посетители жалуются на недогруженные страницы, трафик тратится непонятно на что... Разумеется, не существует единого универсального рецепта, позволяющего решить все эти проблемы, но существуют некие механизмы, позволяющие более или менее снизить их остроту. И одним из таких механизмов является кэширование.
Кэш находится посередине между посетителем сайта и вашим сервером и при грамотной настройке позволяет с одной стороны снизить нагрузку на сервер, т.к. будет отдавать файлы вместо него, а с другой - ускорить получение файлов посетителем, т.к. как правило, находится значительно ближе к нему физически. Под настройкой здесь подразумевается не настройка кэширующего прокси (который, в большинстве случаев к вам не имеет никакого отношения), а настройка веб-сервера.
В принципе, существует два вида кэша: первый - это кэширующие прокси-сервера, расположенные "по дороге" между посетителем и вашим сервером, а второй - это кэш браузера, который находится непосредственно на компьютере пользователя. С точки зрения веб-мастера разница между ними не очень большая, поэтому в этой заметке я буду просто говорить про кэширование.
Когда посетитель запрашивает какой-то документ, то сначала опрашивается кэш и, если прокси-сервер находит у себя копию запрошенного документа, то он решает, отдавать ли ее или запросить новую версию у вашего сервера. Если документ на прокси не обнаружен, то прокси-сервер забирает документ с вашего сервера, передает посетителю, а копию помещает в свое хранилище. И при следующем запросе отдаст (возможно, другому) посетителю уже локальную копию.
У кэширования есть свои недостатки - сложности с подсчетом статистики и показом рекламы, возможность получения посетителем устаревших страниц и т.п. Поэтому, довольно часто встречаются ситуации, когда веб-мастер либо всячески запрещает кэширование своих страниц, либо просто не обращает на кэширование внимания. И тот и другой вариант достаточно плох - в первом случае повышается нагрузка на сервер и увеличивается время получения страниц посетителем, а во втором для кэширования страниц будут использоваться настройки по умолчанию, установленные на прокси-сервере, что может оказаться еще хуже. Поэтому стоит по возможности контролировать что именно и как кэшируется, тем более, что прокси работают независимо от вас и что-то все-равно кэшироваться будет.
Для того, чтобы указать что именно можно или нельзя кэшировать используются заголовки http протокола и meta-теги в заголовке документа (не надо их путать!). meta-теги, в основном, проверяются браузером и помогают ему решить можно ли кэшировать полученный документ. http заголовки, в основном, служат для управления прокси-серверами. Я не зря написал "в основном" - дело в том, что как и в большинстве других компьютерных областей, в кэшировании во-первых нет жестких правил (недаром, все документы, регламентирующие работу Интернета называются rfc: request for comment), а есть только рекомендации, во-вторых очень многое зависит от администратора прокси-сервера, который может либо сознательно, для каких-то своих целей, либо по ошибке настроить свой прокси каким-то "хитрым" способом, в-третьих, не исключены ошибки реализации самих прокси-серверов и т.п. Так что, настраивая свой сервер на оптимальную работу с различными кэшами, вам придется задействовать сразу несколько механизмов управления, но при этом результат не будет гарантирован. Хотя в, пожалуй, 95% случаев все будет работать именно так, как вы задумали.
Первое правило. На любом, даже самом динамическом сайте всегда есть статичные файлы. Это, например, таблицы стилей, картинки навигации, логотип, страница "о компании" и т.д. и т.п. Есть полный смысл постараться загнать все это дело в кэш - от этого все только выиграют. Поэтому стоит во-первых на всех страницах использовать одну и ту же копию картинки, а во-вторых, указывать один и тот же адрес. В частности, если ваш сайт имеет несколько адресов (например, http://mycompany.ru и http://www.mycompany.ru), то есть смысл на страницах прописывать, скажем, <img src="http://mycompany.ru/img/logo.gif" mce_src="http://mycompany.ru/img/logo.gif"> На первый взгляд, экономия не очень значительная, но для популярных сайтов она оказывается вполне заметной.
meta-теги оказывают влияние на кэширование ваших страниц в браузере посетителя. В большинстве браузеров пользователь может указать как часто должна проверяться "свежесть" страниц - один раз для сессии (пока браузер не будет закрыт) или пока не истечет "время жизни" документа, или еще как-то. Браузеры являются особенно активными в отношении кэширования (что не удивительно и правильно), поэтому чаще всего здесь возникает задача запретить (или ограничить) кэширование каких-то отдельных документов. Наиболее полезными здесь оказываются теги expires и pragma no cache. Например, для регулярно обновляемой страницы новостей можно указать, скажем,
, установив дату на минут 5-10 вперед. Если же требуется кэширование совсем запретить, то стоит прописать что, по идее, должно сработать. Можно также expires установить на какую-то дату в прошлом, но ноль является более правильным решением.
http заголовки являются наиболее мощным, но и несколько более сложным в использовании инструментом.
В отношении кэширования наиболее важным является, пожалуй, expires, который как и в meta-теге указывает, когда скэшированная копия устареет. Если значение заголовка expires отличается от требуемого формата (дата по Гринвичу), то большинство прокси будут считать, что документ устарел и кэшировать его не станут. Часто для этих же целей expires устанавливается на дату в прошлом. Это не противоречит rfc2616 [ http://www.w3.org/protocols/rfc2616/rfc2616.html ], но некоторые прокси-сервера считают такой ответ неправильным, отбрасывают заголовок и применяют к документу правила кэширования по умолчанию. Поэтому, если вы не хотите, чтобы документ кэшировался, то лучше установить expires в ноль, или, скажем, на одну секунду вперед.
В http 1.1 [ http://www.w3.org/protocols/rfc2616/rfc2616.html ] появились специальные заголовки cache-control, которые позволяют более тщательно работать к кэшированием. Там есть довольно много вариантов, из которых я бы посоветовал обратить внимание на max-age, который позволяет указать количество секунд в течение которого результат считается "свежим" (очень полезно для динамических сайтов, на которых информация меняется не все время, а, скажем, раз в несколько минут); no-cache, который приказывает прокси-серверу перед тем, как отдать клиенту скэшированный документ запросить подтверждение его "свежести" у вашего сервера (это позволяет одновременно гарантировать, что результаты актуальны и пользоваться преимуществами кэширования); must-revalidate, который приказывает прокси-серверу слушаться ваших указаний насчет "свежести" документа, а не использовать свои предположения и алгоритмы.
Одним из наиболее популярных заголовков является last-modified, указывающий на время последнего изменения документа. Если этот заголовок был указан, когда документ кэшировался, то прокси, обращаясь к вашему серверу может указать в запросе "if-modified-since", и в том случае, если документ не изменился, вашему серверу достаточно отправить код 304, не пересылая сам документ.
В http 1.1 [ http://www.w3.org/protocols/rfc2616/rfc2616.html ] появился еще один полезный заголовок - etag. Он представляет из себя уникальный идентификатор документа, который генерируется вашим сервером и автоматичски изменяется при изменении документа. Таким образом значительно облегчается проверка документа на "свежесть" - достаточно просто сравнить etag'и на сервере и на прокси.
За выдачу http заголовков для статичных файлов отвечает сервер, поэтому стоит почитать его документацию и посмотреть что именно он будет говорить о разных типах файлов. В частности, для "Русского Апача" я бы посоветовал обратить внимание на директиву препроцессора epoch_expires (используется при компиляции сервера), а также на директивы charsetoverrideexpires, charsetdisableforcedexpires и cachenegotiateddocs в файле конфигурации. А заодно обратить внимание на mod_expires [ http://httpd.apache.org/docs/mod/mod_expires.html ] и mod_headers [ http://httpd.apache.org/docs/mod/mod_headers.html ].
Для того, чтобы проверить насколько хорошо ваш сайт может кэшироваться, попробуйте воспользоваться, например, он-лайновым сервисом cacheability [ http://www.web-caching.com/cacheability.html ].
-
Автор: uMaster Получить ссылку
В новом окне Просмотров:[860]
Добавлено:03.10.2009
Подробнее
Первоисточник аудитории Рунета > помощь веб-мастеру
Когда создается новостной проект, не важно какой тематики, встает одна не большая проблема – нужно откуда то брать новости для сайта. Как правило сегодня, множество проектов питаются “новостями” с англоязычных ресурсов. Например блоги в которых переводят посты на SEO тематику.
Игровые сайты, которые публикуют информацию о вновь анонсированных играх и т.д. Выкладывать информацию на русскоязычный сайт отрерайченую с другого русскоязычного ресурса совсем не интересно. Гораздо интереснее следить за развитем этой самой темы в буржунете, переводя статьи на русский язык, тем самым являясь первоисточником для русскоязычной аудитории.
Столкнувшись с такой проблемой, я сначала стал мониторить RSS ленты англоязычных сайтов, но потом заметил точно такую же особенность, то что люди в англонете уже не пишут то, что написано на другом ресурсе, поэтому возникает необходимость мониторить сразу несколько ресурсов. Подписываться на каждый – неоригинально…
Однажды… на днях ища инфу в англоблогах по nfs тематике через google blog search я наткнулся на такую штуку как google alerts, возможно вы знали о ней ранее но я узнал только не давно.
Суть достаточно проста. Вы вводите поисковый запрос, по которому необходимо отслеживать появление новых новостей в блогосфере, и новые результаты поиска предоставляются в удобном для вас виде: либо email либо rss (c помощью этих двух инструментов вы можите настроить передачу информации куда угодно, главно захотеть).
И вот как только вы подписались на какой то запрос, и англоязычный блоггер написал пост на эту тему, который затем попал в базу google blog search то вам на email либо в rss приходит результат серпа. Тоесть теперь вы экономите кучу времени, не выискивая инфу по крупицам, на формах и блогах . Вы получаете ссылки на email, читаете новость, если новость подходит, то оперативно переводите её и постите на свой ресурс.
К слову – быть первоисточником это всегда хорошо, в определённый момент вы можите получить просто коллосальный трафик, и естественно уйму ссылок с блогов и форумов на свой ресурс.
А теперь объясняю, когда вы копирываете информацию с русского сайта (то есть материал) , до вас это уже сделали сотни человек, а когда копируете информацию с например англоязычного сайта и суете в переводчик, получается , что вы первоисточник!!!Можно брать информацию не только с анлоязычных сайтов , можно брать с сайтов любой аудитории!
-
Автор: uMaster Получить ссылку
В новом окне Просмотров:[870]
Добавлено:29.09.2009
Подробнее
как заказчик должен понять SEO-оптимизатора? > помощь веб-мастеру
На дворе 21 век. Сайтов в Сети с каждой минутой больше и больше. И теперь уже мало просто создать сайт и зарегистрировать его в поисковых системах. Теперь уже надо бороться за место под виртуальным солнцем. Для достижения заветных первых мест в поисковиках Вашему сайту поможет SEO или, проще говоря, оптимизация под поисковые системы.
Оптимизация под поисковые системы - это различные методы усовершенствования веб-страниц для повышения рейтинга сайта, а также комплекс мер по продвижению сайта в сети. Легальными методами оптимизации являются: методы создания веб-страниц с оптимальной структурой и информационным наполнением; наилучший выбор ключевых слов; эффективное описание и название страницы; регистрация в каталогах; контекстная реклама; баннерный обмен, и т.д.
Необходимость продвижения сайтов породила в сети отдельную категорию людей - SEO-оптимизаторов (или просто «оптимизаторов», «раскрутчиков»). Но специфика данного вида деятельности часто вызывает при переговорах с оптимизаторами «когнитивный диссонанс». Надеюсь, данный материал поможет понять оптимизаторов и не относиться к ним с предубеждением.
Что раздражает заказчика: Ответ на вопрос о стоимости.
Частый вариант ответа: Примерную стоимость мы Вам огласим. К сожалению,
нельзя привести точную цифру цен для продвижения ресурса.
Почему
не надо раздражаться: Все зависит от многих факторов, которые, так или
иначе, формируют цены на продвижение сайта. Перед тем, как озвучить
цены, необходимо провести тщательный анализ - как на конкуренцию, так и
на общие пожелания заказчика. Заказчик должен понимать, что
оптимизация, непосредственно, зависит от многих факторов - от изменения
алгоритмов поисковых систем (на которые повлиять не сможет даже «гуру»
раскрутки и оптимизации); от конкуренции в Вашей среде; от требований к
раскрутке; от контента, дизайна и юзабилити Вашего сайта (вполне может
быть, что придется полностью переделывать контент и дизайн). Цена может
варьироваться как в меньшую сторону, так и в большую.
Что раздражает заказчика: Предупреждение о рисках.
Частый вариант ответа: Все может быть только хуже…
Почему не надо раздражаться: Степень риска при проведении оптимизации
зависит от вас. Есть три способа проведения комплексной раскрутки и
оптимизации:
«Белая раскрутка». Все делается по правилам.
Недопущение мер со стороны поисковиков по «забаниванию» и/или снижения
имиджа и репутации заказчика.
«Серая раскрутка». Использование
некоторые приемов, способных вызвать негативную реакцию у некоторой
части населения и/или отказ от регистрации некоторых каталогов
(«линкопомойки», buzz-маркетинг и пр.).
«Черная раскрутка».
Использование очень эффективных, но обманных технологий по повышению
посещаемости и количественных показателей сайта («взлет ракетой»,
подмена контента, дорвеи, переадресации, невидимый контент, клоакинг и
пр.) Риск быть полностью исключенным из результатов выдачи поисковиков.
Цена соответственно тоже отличается, в зависимости от выбора способа.
Что раздражает заказчика: Отказ от гарантий
Частый вариант ответа: Нет 100%-ной гарантии…
Почему не надо раздражаться: оптимизаторы отказываются гарантировать
результат своей работы в конкретных числовых параметрах, мотивируя этот
отказ причинами, истинность и объективность которых проверить владельцу
сайта не получается. Владелец сайта оказывается в ситуации, далёкой от
комфорта и защищенности. Он вынужден верить незнакомому исполнителю
фактически на слово.
Отказ от гарантий - это не прихоть оптимизатора. Очень многое зависит от факторов, на которые оптимизатор не может оказывать заметного влияния - это и непредсказуемость поведения поисковых машин, смены алгоритмов ранжирования, действия конкурентов, технические проблемы Сети и хостинг провайдеров, и так далее. Действительно, много причин может помешать поднять сайт на вершину по конкретному запросу, но еще больше причин может помешать посетителю сайта совершить звонок или заполнить заявку. Высокая (или непонятная) цена товара или услуги сайтовладельца, проблемы юзабилити, проблемы с маркетингом, долгое время «созревания» посетителя, перегруженные телефонные линии, недобросовестный персонал, обрабатывающий звонки или заявки - всё это может помешать посетителю позвонить, отправить заявку, и так далее.
По сути, в данном случае такая услуга, оказываемая оптимизатором, уже перерастает рамки поисковой оптимизации. Это гораздо более сложная услуга, включающая в себя анализ юзабилити сайта и, возможно, даже элементы управленческого консалтинга.
Поймите оптимизаторов - они всеми силами избегают вносить в договоры точные числовые критерии эффективности своих услуг не потому, что ленивые и не хотят работать. Есть уважительные причины:
Нежелание рисковать вознаграждением в случае непредсказуемых действий
поисковиков и других третьих лиц. Оптимизатор затратил массу времени,
оптимизируя сайт заказчика, и вдруг из-за профилактических работ на
серверах поисковика сайт клиента пропал на два-три дня из выдачи.
Заказчик на основании этого факта отказывается платить за работу.
Нежелание тратить время на лишнюю отчетность. Отчеты тоже занимают
время, и время это многие оптимизаторы считают совершенно
непроизводительным.
Невозможность точно прогнозировать результат.
По статистике примерно 8 из 10 клиентов, вначале настаивавших на количественных гарантиях, на точной стоимости услуг и отсутствии рисков, после правильно проведенных переговоров с элементами ликбеза готовы изменить свои требования. Как говорил мудрец - в диалоге рождается истина.
Сайт оптимизтрован для просмотра в брузерах:Firefox & Opera при разрешении экрана 1280x1024 пикселя.
