Главная

Я читал, что поисковый сервер перебирает все правила в robots.txt и останавливается на первом подходящем. Поэтому, я наивно полагал, что если разместить блок "User-agent: *" в начале файла, его правила будут использоваться в любом случае. То есть, мой robots.txt выглядел так:


Однако, случайно я обнаружил, что страница "/login" вполне доступна для индексирования (проверял в инструментах веб-мастера Google и Yandex). Оказалось, что если в robots.txt есть секция для конкретного поискового севера (например, "User-agent: Yandex"), этот сервер вообще не обращает внимания на остальные секции, в том числе и на "User-agent: *". Единственное правило, которое они обнаруживают в любом месте, это "Sitemap:" - он доступен всем и везде не смотря на строки "User-agent:". [читать дальше]

Файлы robots.txt просты как угол дома и используются со времен, когда 3" дискеты считались прорывом в технологии :) Именно по этому я думал, что в них нечего и разбираться. Так что обходился копи-пастом какого-то образца, который переходил у меня из проекта в проект уже несколько лет.

Но вот однажды, затеял я эксперимент с индексацией сайта. Выложил его в инет, добавил в "Инструменты для веб-мастеров" Google и ... увидел сообщение "Страницы вашего сайта недоступны для Google из-за огранчений в robots.txt". А файл-то был простейший, создавался он ради одной строчки "Sitemap: http://доменное имя/sitemap.xml", чтобы лишний раз указать поисковикам где искать карту сайта.

Между прочим, robots.txt кешируется Google примерно на день, так что после исправления пришлось ждать более суток. Вобщем я вздохнул и полез разбираться с темой.

Robots.txt был придуман в далеком 1994 году и был предназначен для того, чтобы указать поисковикам, что не следует индексировать на вашем сайте. [читать дальше]

"А что тут сложного?" удивитесь вы. А потом, подумав "вряд ли он ответит 'ничего' и этим закончит статью", спросите - "а в чем подвох?".

Подвох конечно есть. Но давайте сначала посмотрим, что вообще можно сделать. Самый просто вариант - ничего. Ваш сайт честно отошлет пользователю код возврата 404 и тот увидит в браузере что-то вроде:



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

Разработчики сайтов конечно понимают, что так поступать нельзя. Если это не ваш постоянный посетитель - после такого ответа вы его потеряли. Поэтому на сайте создается специальная страница, которая выводится, когда никто не знает что делать с этом странным адресом. Она имеет такой же внешний вид как и остальные страницы сайта и должна сказать посетителю "Все замечательно и под контролем! Да, вот этой информации у нас нет, но вы можете поискать здесь, или перейти вот сюда".

Вот так это, например, выглядит на сайте "сами знаете кого":



А теперь, посмотрим чуть дальше. Да, с пользователем мы разобрались. А вот что будет с поисковыми серверами? [читать дальше]

Давайте теперь посмотрим, как можно реализовать наши требования при помощи ISAPI Rewrite.

1. Работа с поддоменами
Во-первых, нужно связать наше веб-приложение с нужными доменами под IIS. Делается это в оснастке IIS, при помощи диалога "Advanced Web Site Identification", показанного на рис. 1. В нем мы дожны перечислить все варианты интересующих нас поддоменов, а именно: [читать дальше]

А теперь пришло время понять, зачем мы разбирали нелегкий жизненный путь запросов :) Вспомните, кроме всего прочего, мы хотели перенаправлять urls типа http://news.ru/fooball/. Все ли мы сделали, чтобы работать с такими запросами? Уже догадались, в чем дело? Правильно! Все, о чем мы только что говорили, реализовано в нашем веб-приложении на ASP.NET. Но для того, чтобы ему выполнить rewriting, он должен как минимум получить управление. По умолчанию IIS настроен так, чтобы передавать управление ASP.NET при запросах страниц с расширением .aspx (и еще некоторых расширений). Если же он получит запрос без расширения, то будет думать, что это каталог и попробует определить для этого пути документ по умолчанию - то есть сделает вовсе не то, что нам нужно. [читать дальше]

1. Итак, IIS передает ход ISAPI Application aspnet_isapi.dll, а тот, в свою очередь, перенаправляет запрос процессу w3wp.exe (для Windows 2003) или aspnet_wp.exe (если у вас Windows XP), которые и являются движками, для выполнения ASP.NET прилолжений.

2. Здесь картина опять повторяется. Сначала ASP.NET по очереди вызывает все модули (HttpModules), зарегистрированные для web-приложения. Для этого просматриваются секции всех конфигурационных файлов, начиная от корневого machine.config и заканчивая web.config файлом, ближе всех расположенным к вызываемой странице. Именно таким образом вызываются системные модули типа Session (поддерживающий понятие "сессия") или FormsAuthentication (выполняющий аутентификацию пользователей). [читать дальше]

Tags:

Project management | SEO | Web development

Permalink | Комментарии (2) | Post RSS

К сожалению, это не название какой-то технологии или библиотеки. Это всего-то значит, что url rewriting мы можем реализовать и сами. Сразу хочу вас успокоить, есть несколько библиотек, которые реализуют эту идею, их мы рассмотрим ниже. Но, во-первых, всегда лучше знать, по какому принципу что-то работает (помните, "знание общих принципов заменяет незнание отдельных фактов"), а во-вторых, часто для счастья нужно совсем чуть-чуть, но вот этого чуть библиотека и не позволяет. Так что посмотрим, как можно реализовать rewriting своими руками. [читать дальше]

Если вы попали на эту страницу с поискового сервера - вам не нужно объяснять зачения этих слов. Cтатья поможет вам упорядочить картину "URL rewriting, что и как я могу сделать", а так же понять, что находится в арсенале разработчика ASP.NET, плюсы и минусы основных решений.

Если же вы зашли сюда по старой памяти, давайте взглянем на слова "SEO, user and serach engine friendly urls, improving the search relevancy, protect site content". Если выражение вашего лица стало хоть чуть более заинтересованным - наливаем кофе, устраиваемся поудобнее и читаем дальше.

Для того, чтобы уйти от общих фраз, давайте сразу представим себе реальный пример: скажем, владелец домена news.ru заказал у вас разработку новостного портала. И как у нас водится - это должен быть портал всех порталов, убийца остальных новостных ресурсов и т.д. Он будет содержать десятки тысяч новостей, разбитых по категориям и темам и, естественно, должен быть вооружен последними достижениями SEO, чтобы максимально ускорить вожделенный и столь горячо обсуждаемый процесс "монетаризации".

Что нам может понадобится? [читать дальше]