Jaa

Набор инструментов для поисковой оптимизации IIS

  • Artikkeli

Поисковая оптимизация (search engine optimization, SEO) - один из тех важных аспектов, которые следует учитывать при проектировании любого Интернет-сайта. Весомый процент Интернет-трафика создается для сайтов за счет поисковых систем, и использование приемов поисковой оптимизации поможет ощутимо увеличить этот трафик.

Аналогично, маленькие ошибки могут существенно повлиять на релевантность поисковых запросов содержимому вашего сайта, и пользователи "не найдут" ваш сайт даже тогда, когда должны были бы. Среди таких ошибок: множество гиперссылок на сайте, приводящих к одному и тому же контенту, неработающие ссылки на страницах, неправильно подобранные заголовки, описания и ключевые слова, большие объемы данных во ViewState, некорректная разметка и т.д. Зачастую эти ошибки легко исправить - но основная сложность в том, как обнаружить и идентифицировать их в рамках сайта.

Представляем набор инструментов для поисковой оптимизации IIS

Сегодня мы выпускаем первую бета-версию нового бесплатного набора инструментов для поисковой оптимизации IIS (IIS Search Engine Optimization Toolkit), который облегчит задачи анализ вашего сайта для проведения поисковой оптимизации, а также поможет обнаружить и исправить ошибки в нем.

Установить набор инструментов для поисковой оптимизации вы можете с помощью Установщика веб-платформы Microsoft; я уже писал о нем в своем блоге на этой неделе. Осуществить установку вы можете посредством WebPI, щелкнув по ссылке "install now" на домашней странице набора инструментов для поисковой оптимизации IIS.

После установки в оснастке администрирования IIS7 появится новый раздел "Search Engine Optimization" (поисковая оптимизация), в котором будет доступно несколько соответствующих инструментов:

Инструменты Robots и SiteMap позволяют вам создать и поддерживать в актуальном состоянии файлы robots.txt и sitemap.xml для вашего сайта, чтобы помочь поисковым системам узнать, по каким ссылкам им стоит следовать для обхода страниц сайта, а по каким - нет.

Инструмент Site Analysis позволяет обойти сайт так же, как это делают поисковые системы, и затем проанализировать его на основе множества различных правил, которые помогут обнаружить в нем проблемы с поисковой оптимизацией, легкостью просмотра и производительностью.

Использование набора инструментов для поисковой оптимизации IIS

Посмотрим, как мы можем использовать этот набор инструментов для быстрого обнаружения проблем с поисковой оптимизацией на том или ином сайте. Чтобы не смущать никого, "натравливая" этот инструментарий на его сайт, я решил вместо этого опробовать его на одном из своих собственных сайтов - www.scottgu.com. Этот сайт я написал много лет назад (последнее обновление было, кажется, в 2005-м году). Если вы установите набор инструментов для поисковой оптимизации IIS, то сможете указать ему для анализа мой сайт и воспроизвести описываемые ниже шаги для более углубленного понимания анализа проблем с поисковой оптимизацией.

Откройте инструмент Site Analysis

Начнем мы с запуска оснастки администрирования IIS (inetmgr) и выбора в дереве на левой панели корневого узла (имени компьютера - в данном случае "Scottgu-PC"). После этого в секции "Search Engine Optimization" справа выберем иконку "Site Analysis". Запуск инструмента Site Analysis на уровне компьютера, как в данном примере, позволяет вам использовать этот инструмент для любого удаленного сервера (запусти мы его на уровне открытого в дереве сайта, мы смогли бы осуществить анализ лишь для локальных сайтов, выполняющихся на соответствующем сервере).

После запуска инструмента Site Analysis экран будет выглядеть, как на рисунке ниже; в окне будут показаны все сохраненные отчеты по ранее выполненному анализу сайтов. Поскольку мы запускаем этот инструмент в первый раз, список сохраненных отчетов у нас пуст. Щелкнем по ссылке действия "New Analysis…" в правой части окна, чтобы создать новый отчет с результатами анализа:

После выбора действия "New Analysis…" появится диалог, как на рисунке ниже, в котором мы можем задать название отчета, а также то, какой сайт и насколько глубоко мы хотим исследовать.

Мы назовем наш новый отчет "scottgu.com" и настроим обход сайта, начиная с URL https://www.scottgu.com и далее до 10,000 страниц с этого сайта (внимание: если вы не видите поле ввода "Start URL", то это потому, что вы не выбрали корневой узел с названием сервера в дереве на левой панели оснастки администрирования IIS и вместо этого открыли инструменты поисковой оптимизации на уровне сайта - отмените создание отчета, вернитесь и выберите корневой узел с названием сервера, после чего уже запускайте инструмент Site Analysis).

После нажатия кнопки "Ok" в приведенном выше диалоге инструмент Site Analysis запросит URL https://www.scottgu.com, проанализирует возвращенные данные в формате HTML и затем начнет обход сайта так же, как это бы делала поисковая система. Мой сайт содержит 407 различных ссылок, но у инструмента Site Analyses ушло всего 13 секунд, чтобы обойти их все и проанализировать загруженный по ссылкам контент.

После завершения обхода сайта откроется окно с итоговой информацией отчета, где вкратце будет описано, что было найдено в результате анализа. Ниже вы можете увидеть, что на моем сайте было найдено более 700 разного рода нарушений (ой-ой):

Мы можем щелкнуть по любому из элементов списка нарушений, чтобы узнать более детальную информацию по ним. Посмотрим на некоторые из этих нарушений.

Просмотр информации по нарушениям "description is missing"

Выше вы могли заметить, что на моем сайте нашлось 137 нарушений вида "The description is missing" ("отсутствует описание"). Щелкнем дважды по правилу, чтобы узнать о нем побольше и увидеть детальную информацию по отдельным нарушениям. При этом откроется новая вкладка запроса, в которой автоматически отфильтрованы только нарушения вида "отсутствует описание" (внимание: при желании вы можете сами настроить фильтры запроса, а также выгрузить результаты в Excel для дальнейшего еще более углубленного анализа):

Дважды щелкнув по любому из нарушений, увидим окно с более детальной информацией. Для каждого нарушения показывается, в чем именно проблема, а также рекомендации по исправлению:

На рисунке вверху вы можете увидеть, что я забыл добавить элемент <meta> с описанием к моей странице с фотографиями (а также ко всем прочим страницам). Поскольку на моей странице с фотографиями сейчас есть лишь изображения, поисковая система никак не сможет узнать, что именно содержится на этой странице. Описание длиной от 25 до 150 символов могло бы объяснить, что она содержит альбом моих фотографий, а также дать дополнительную контекстную информацию.

Вкладка "Word Analysis" ("анализ слов") зачастую может быть полезна, когда дело касается текста описаний. На этой вкладке отображается информаций о странице (ее заголовок, ключевые слова и т.д.), а также список всех слов, использованных в ее HTML-тексте, вместе с числом повторений каждого слова. Здесь вы также можете увидеть все словосочетания из двух и трех слов, повторяющиеся на странице. Кроме того, здесь вы сможете увидеть текст, использованный на других страницах для ссылки на эту страницу - и вся эта информация может вам очень пригодиться при составлении текстов описаний:

Просмотр информации по нарушениям "URL is linked using different casing" ("ссылки на страницу отличаются регистром")

Теперь посмотрим на нарушения "URL is linked using different casing". Для этого мы можем вернуться на итоговую страницу отчета и дважды щелкнуть по строке, соответствующей этим нарушениям:

Поисковые системы подсчитывают количество страниц в Интернете, которые ссылаются на тот или иной URL, и используют полученное число как часть исходных данных для алгоритма, с помощью которого они определяют релевантность информации, доступной по этому URL. Это означает, что если 1000 страниц ссылаются на URL страницы, на которой обсуждается определенная тема, то поисковые системы сочтут содержимое страницы с этим URL намного более релевантным, чем страницы, содержащей информацию на ту же самую тему, но на URL которой ссылаются лишь 10 других страниц.

Чего очень многие люди не осознают, так это того, что поисковые системы регистрозависимы в том смысле, что рассматривают написание одного и того же URL в разных регистрах как различные URL. Это значит, что ссылки на /Photos.aspx и /photos.aspx зачастую будут восприниматься поисковыми системами не как один и тот же URL, а как разные. Таким образом, если в половине ссылок фигурирует /Photos.aspx, а в другой половине - /photos.aspx, то поисковые системы не будут считать страницу с фотографиями настолько релевантной, насколько она на самом деле является (вместо этого, ее релевантность будет оценена вдвое ниже, поскольку на нее будут ссылаться два различных URL). Так что поиск и исправление мест, где используются гиперссылки, отличающиеся регисторм, является на самом деле весьма важным делом.

Выбрав строку нарушений "URL is linked using different casing", как на рисунке выше, мы увидим список всех 104 гиперссылок, использованных на сайте в разном регистре:

Если щелкнуть дважды по любой из гиперссылок, то появится окно с детальной информацией по данному нарушению с перечислением всех отличающихся регистром способов представления гиперссылки на анализируемом сайте. Обратите внимание, что в поле детализации приводятся оба варианта, отличающиеся использованием прописных/строчных букв. В данном случае я указываю URL, используя параметр запроса "AlbumId". Где-то в другом месте сайта я указываю тот же URL, но уже с использованием параметра "albumid" ("a" и "i" теперь в нижнем регистре). Поисковые системы будут рассматривать эти гиперссылки как разные, так что я не смогу добиться максимально высокого ранжирования контента, на который они ссылаются:

Узнать, что на сайте есть подобные проблемы, - это лишь первый шаг. Шаг второй обычно сложнее: попытаться найти все различные приводящие к этому URL пути, которые следует принять во внимание. Зачастую вы исправите одно место и думаете, что исправили всё - и вместо этого обнаруживаете, что на сайте есть еще один доселе неизвестный путь, ведущий к данному URL и также создающий проблемы с используемым регистром. Чтобы помочь вам в таких ситуациях, в выпадающем списке "Actions" справа вверху предусмотрен пункт "View Routes to this Page" ("Показать пути, ведущие к этой странице").

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

Когда у вас есть информация о конкретных нарушениях, связанных с различием в регистре написания URL, а также возможность проанализировать, по какому именно пути через сайт необходимо пройти, чтобы прийти к тому или иному варианту написания URL, то становится намного проще справляться с подобного рода проблемами.

Просмотр информации по нарушениям "the page contains multiple canonical formats" ("страница содержит несколько канонических форматов")

Исправить написание одних и тех же URL в различном регистре, как мы проделали выше, - это хорошее начало на пути к тому, чтобы повысить число ссылок на страницы. Но мы также хотим устранить ситуации, в которых одни и те же страницы могут быть получены с использованием URL, отличающихся больше, чем просто регистром букв. Для этого вернемся к окну с итоговой информацией отчета и обратимся к нарушениям вида "the page contains multiple canonical formats":

Исследуя детали отчета по этому типу нарушений, мы увидим список всех URL на нашем сайте, которые могут быть доступны с использованием нескольких "канонических" представлений:

Щелкнув дважды по любой строке в списке, мы увидим окно с детальным описанием той или иной проблемы. Заметьте на рисунке ниже, как анализатор определил, что иногда мы ссылаемся на стартовую страницу сайта как "/", а иногда - как "/Default.aspx". И хотя наш веб-сервер в обоих случаях вернет одну и ту же страницу, поисковые системы воспримут это как два различных URL - в результате релевантность соответствующей страницы с точки зрения поиска окажется не столь высокой, какой она должна быть (поскольку весовой коэффициент, соответствующий числу ссылок на страницу, окажется поделен между двумя различными URL).

На вкладке "Links" мы можем увидеть все различные варианты ссылок на URL /Default.aspx; здесь же показываются ссылки с самой страницы /Default.aspx:

Переключиться на просмотр всех мест на сайте, ссылающихся на URL "/", можно с помощью выпадающего списка в меню "Related URLs" - в этом меню в общем случае показываются все прочие варианты URL, которые в результате приводят к той же самой странице:

По аналогии с нарушениями, связанными с регистром гиперссылок, мы можем воспользовать пунктом меню "View Routes to this Page", чтобы увидеть все пути в рамках сайта, приводящие к тому или иному варианту URL. Таким образом можно "отловить" и изменить все такие проблемные места и в результате для каждой страницы всегда использовать один и тот же URL.

Заметьте: исправление проблем с написанием гиперссылок в различном регистре и их каноническим представлением для всех внутренних ссылок на вашем сайте - это для начала неплохо. Но другие сайты также могут ссылаться на страницы вашего сайта, однако обновить все ссылки на этих сайтах может быть куда сложнее. Впрочем, есть способ улучшить положение с ранжированием страниц поисковыми системами без необходимости обновлять все внешние ссылки на ваш сайт. Для этого вы можете загрузить и установить на ваш веб-сервер модуль IIS URL Rewrite (вы можете получить его бесплатно, воспользовавшись Установщиком веб-платформы Microsoft). Затем можно настроить правило URL Rewrite ("переписывание URL") для создания автоматического постоянного перенаправления запросов на корректное каноническое представление URL - в результате поисковые системы будут рассматривать их все как один и тот же URL (прочитайте статью в блоге Карлоса IIS7 и URL Rewrite: поисковая оптимизация вашего сайта, чтобы подробнее узнать, как это делается).

Просмотр информации по нарушениям перенаправления

В заключении давайте посмотрим на некоторые нарушения на сайте, связанные с перенаправлением:

Изучение правил этой категории напомнило мне то, чем я занимался несколько лет назад (я тогда перевел свой блог на другой сайт) - и что, как мне теперь кажется, было довольно глупым.

Поначалу, когда я только создал сайт, у меня была простенькая страничка блога по адресу www.scottgu.com/blog.aspx. Спустя несколько недель я решил переместить блог на weblogs.asp.net/scottgu. И вместо того, чтобы пройтись по всем страничкам моего сайта и изменить ссылки на новый адрес, я подумал, что поступлю умнее, если изменю лишь страницу blog.aspx, чтобы она выполняла перенаправление на новый URL weblogs.asp.net/scottgu.

С точки зрения пользователя это сработало, но чего я не понимал, пока не запустил сегодня анализатор сайта, - это что поисковые системы не могут следовать по таким ссылкам. Причина в том, что моя страничка blog.aspx осуществляет перенаправление на weblogs.asp.net/scottgu. Однако движок блога на сайте weblogs.asp.net для поисковой оптимизации осуществляет второе перенаправление с адреса weblogs.asp.net/scottgu на https://weblogs.asp.net/scottgu/ (заметьте, что в конце добавляется слэш).

Если верить сообщению о нарушении правила в инструменте Site Analysis, поисковые системы не могут сопоставить адреса, если встречают два перенаправления подряд. В ходе анализа было определено, что моя страница blog.aspx перенаправляет ссылки на внешний адрес, по которому осуществляется еще одно перенаправление - при этом поисковые системы уже не могут сопоставить информацию о ранжировании страницы и другую релевантную информацию между исходным URL и конечным:

Я смог убедиться, что проблема была именно в этом, без необходимости смотреть исходный код страницы blog.aspx. Мне понадобилось лишь обратиться к вкладке "Headers" (Заголовки) в окне деталей нарушения и посмотреть на заголовок HTTP-ответа, посылаемого страницей blog.aspx. Заметьте, что URL в заголовке не содержит слэша в конце, что вынуждает Community Server (на котором расположен блог) сделать еще одну переадресацию, когда он получает запрос с таким URL:

Исправиь эту проблему просто. На самом деле я никогда бы и не узнал, что существует такая проблема, если бы инструмент Site Analysis не указал мне на нее.

Будущая поддержка автоматических исправлений

Инструмент Site Analysis нашел еще несколько нарушений и проблем с контентом в ходе обследования моего сайта. Их обнаружение и исправление довольно тривиальны - подобно тому, что было показано выше. С каждой проблемой, которую я исправляю, мой сайт становится более корректным, простым для обхода поисковыми системами, а его содержимое - более релевантным с их точки зрения. Это, в свою очередь, увеличивает объем трафика, генерируемого пользователями, приходящими на сайт по результатам поиска, что существенно повышает эффективность сделанных инвестиций. После создания и сохранения отчета он будет доступен в списке предыдущих отчетов в оснастке администрирования IIS. В любой момент вы можете из контекстного меню для сохраненного ранее отчета выбрать его повторное создание с использованием прежних настроек - это позволит вам периодически проверять, не возникли ли какие-нибудь регрессионные ошибки по мере развития сайта.

Сборка инструмента Site Analysis, доступная на данным момент для предварительного просмотра, проверят сайт по примерно 50 различным правилам. Со временем мы добавим больше правил для проверки дополнительных сценариев и возможных проблем. Кроме этого, в будущих сборках вы найдете еще более интеллектуальные возможности, встроенные в этот инструмент, с помощью которых вы сможете также проверять сайт со стороны сервера с установленным модулем URL Rewrite и набором хороших настроенных правил, учитывающих поисковую оптимизацию. Наконец, инструмент Site Analysis позволит вам исправлять некоторые нарушения автоматически, предлагая правила для модуля URL Rewrite, которые вы сможете добавить в настройку сайта непосредственно из интерфейса этого инструмента (например, для исправления проблемы с каноническим написанием, вроде использования "/" и "/Default.aspx", как было рассмотрено выше). Эти возможности сделают хорошую поисковую оптимизацию сайтов еще проще. А до той поры я рекомендую прочитать материал по приведенным ниже ссылкам, чтобы узнать, как настраивать URL Rewrite для поисковой оптимизации вручную:

Подведем итоги

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

Набор инструментов поисковой оптимизации IIS полностью бесплатен, ставится меньше чем за минуту и может быть запущен для любого существующего веб-сервера или веб-сайта. Для его использования не нужно ничего устанавливать на удаленный сервер, просто введите URL сайта - и вы получите отчет по результатам его анализа, каждый пункт которого предоставляет вам набор действий, которыми вы можете воспользоваться, чтобы незамедлительно начать улучшать ваш сайт.

Сегодня выпущена лишь бета-версия, так что если вы столкнулись с какими-то проблемами при ее использовании или хотите предложить реализовать какие-то возможности, то дайте нам знать на форуме по обсуждению набора инструментов поисковой оптимизации IIS.

Надеюсь, вы нашли для себя что-то полезное,
Скотт

оригинал статьи