SEO блог – PrjSoft Статьи и новости по SEO

Назначение файла robots.txt

К основным функциям выполняемым файлом robots относятся:

1. закрытие служебного и конфиденциального контента от индексирования в поисковиках
2. закрытие страниц с похожим или дублированным контентом от индексации

Закрытие страниц от индексации естественно не означает, что она закрыта для просмотра, кроме того, это не означает даже, что страница не появится в поисковой выдаче, так как может быть найдена по ссылкам. Просто робот не будет загружать содержание этой страницы и в кэше поисковика ее тоже не будет.

Закрытие служебной информации для wordpress

WordPress 3.0 имеет три служебных каталога и в соответствии с первой функцией файла robots их надо закрыть от индексации:

Disallow: /blog/wp-admin/
Disallow: /blog/wp-includes/
Disallow: /blog/wp-content/

В представленном примере блог располагается в каталоге “blog” сайта.

Кроме перечисленных служебных каталогов в недрах страниц блога запрятаны ссылки еще на два служебных файла, расположенных в корневой директории блога – xmlrpc.php и wp-login.php, их тоже надо закрыть:

Disallow: /blog/wp-login.php
Disallow: /blog/xmlrpc.php

Теперь служебная информации закрыта.

Борьба с дублированнием контента

Практически на каждой страницы блога есть ссылка на trackback URL для данной страницы – url_страницы/trackback/. Этот URL в конечном итоге с помощью временного перенаправления 302 указывает на url_страницы. Есть небольшая вероятность, что поисковик может связать содержание с этим url, поэтому раньше я закрывал эти url:

Disallow: /blog/*/trackback

Теперь же я это делать перестал – результат я скоро проверю.

При включенном режиме постоянных ссылок при задании удобного URL wordpress все равно генерирует также стандартную ссылку с “?p=”. Я перестал закрывать эти ссылки, так как они перенаправляются постоянным редиректом 301 на удобный URL и, кроме того, wordpress указывает атрибут сanonical в ссылке на читаемый URL.

WordPress группирует посты по датам, категориям и меткам и при этом создается дублирование контента. В случае ценности таких группировок, закрывать их в роботе не надо, поисковик разбирется сам. В маленьком и не очень часто обновляемом блоге вреда от этого больше чем пользы. Поэтому я закрываю все группировки роботом:

Disallow: /blog/2009/
Disallow: /blog/2010/
Disallow: /blog/2011/
Disallow: /blog/tag/
Disallow: /blog/category/

RSS ленты и комментарии

RSS ленты (фиды) закрывать не надо, так как они способствуют быстрейшей индексации блога и не создают дублированного контента. Комментарии это дело вкуса – я не закрываю.

Созданный файл robots.txt

User-agent: *
Disallow: /blog/wp-login.php
Disallow: /blog/wp-admin/
Disallow: /blog/wp-includes/
Disallow: /blog/wp-content/
Disallow: /blog/xmlrpc.php
Disallow: /blog/2009/
Disallow: /blog/2010/
Disallow: /blog/2011/
Disallow: /blog/category/
Disallow: /blog/tag/

p.s. 1.04.2012
нашел еще группировку которую можно закрыть, если есть только один блоггер: /blog/author/

Технологии машинного перевода ведущих поисковиков

В последнее время на многих сайтах появилась ссылка: “просмотреть английскую версию”, которая пользуясь технологией переводов Google осуществляет дословный перевод текста. Yandex сейчас использует технологию Promt. Для английской версии моего сайта, перевод Google выглядел лучше. Сравнить результаты работы технологий можно, набив в поисковых системах адрес страницы www.design-sites.ru/en/.

Дублированный контент и переводные тексты

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

Перспективы поиска на разных языках

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

Рекомендации Google по созданию многоязычных сайтов

Сегодня (15.03.2011) проверил официальную информацию по отношению Google к многоязычности на сайте.
В настоящее время Google рекомендует следующее:

• Использовать для навигации и контента один язык
• Блокировать страницы, полученные с помощью машинного перевода в robots.txt
• Делать перекресные ссылки со страницы на одном языке на соответствующую страницу на другом
  языке
• Использовать в url признак языка (ru, en, и.т.д.)

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

Ответ Google на запрос в Москве

Ответ Google на запрос в Красноярске

На тот же запрос, заданный из Красноярска, начиная с четвертой позиции идет локальная выдача из Красноярска, то есть выдачи по Москве и Красноярску отличаются.

Видимо я поспешил насчет удаления блока адресов – сегодня 11 декабря я повторил эксперимент. Теперь я вижу и геозависимую выдачу и блок адресов одновременно. Я даже стал сомневаться – может так всегда и было. В любом случае привожу картинки, чтобы больше никогда не сомневаться.

Гео выдача Google в Москве + блок адресов

Гео выдача Google в Красноярске + блок адресов

Еще интересней картина получается, если задать город, отличный от автоопределяемого.

Гео выдача Google из двух городов

Из всего этого напрашивается вывод, что для проверки ранжирования по гео запросам в Google, лучше просто вводить в строку поиска город.

Выдача по геозависимому запросу с названием города

После некоторых колебаний я выложил программу – анализатора перелинковки сайта в сеть (обычно такие программы идут как shareware). Буду рад вопросам и комментариям к ней.

Назначение программы

Инструмент предназначен для проверки ссылочных весов страниц сайта или нескольких связанных между собой сайтов.
Ссылочный вес используется поисковыми системами при ранжировании страниц сайтов в поисковой выдаче.
В программе сылочный вес называется как PageRank, так как алгоритм его расчета был запатентован Google, но в целом результаты проверки могут быть отенесены и к другим поисковым системам, в частности к Яндексу.

Принцип действия

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

Техническая реализация

Программа написана в виде макросов рабочей книги excel. Для сканирования веба анализатор запускает браузер IExplorer в автоматическом режиме.

Инструкция по применению

Для запуска программы нужно открыть книгу (файл анализатора) с помощью excel и разрешить выполнение макросов в ней. После этого нужно последовательно выполнять инструкции для каждого шага работы (step1, step2…)

Возможные неполадки и их разрешение

Программа зависает при сканировании веба, сканирование неожиданно останавливается.

Так как программа сканирует веб с помощью браузера, то активное содержание страниц сайта может вызвать сбои в ее работе. Для разрешения проблем рекомендуется отключить выполнение активного содержания в браузере IExplorer (на время выполнения программы). Для этого надо открыть IExplorer, зайти на вкладку безопасности в свойствах обозревателя и поотключать все, что только возможно.

Скорость сканирования мала, картинки на страницах сайта долго грузятся.

Отключить показ картинок в браузере IExplorer. Зайти в свойствах обозревателя на вкладку “дополнительно” и убрать галочку с пункта “Показывать изображения”.

Для прогноза частоты запросов в Yandex и Google используют соответствующие инструменты Yandex и Google. В зависимости от настроек эти инструменты могут дать достаточно большой разброс чисел (в несколько раз). Панели веб мастера Google и Yandex предоставляют статистику показов сайта по запросам, на которых он находится на достаточно высокой позиции. При сравнении этой информации в принципе можно сделать вывод о том, какие настройки нужно задавать в инструментах статистики для правильной оценки частот запросов.

Определение частоты запроса в регионе для Yandex

Для определения частоты запроса в Yandex в конкретном регионе нужно зайти на вкладку “по словам” и в двойных кавычках написать требуемое ключевое сочетание или слово, например “теплые полы”. Затем нужно уточнить регион. Искомая частота появится внутри фразы “Что искали со словами «теплые полы» — 2403 показа в месяц”.

Определение частоты запроса в регионе для Google

Инструмент подбора ключевых слов Google не дает данных о частоте запросов по регионам РФ, но если создать акаунт adword (бесплатно), то этот инструмент дает данные по запросам в России. Для правильной оценки частоты запроса по РФ нужно выбрать целевым регионом Российскую Федерацию и русский язык, тип соответствия – “точное”. Количество просмотров в РФ появится в графе целевого региона. Я думаю, что, если теперь помножить число показов Google в РФ на частное от деления показов в регионе РФ для Yandex к показам в РФ для Yandex, с большой долей вероятности мы получим оценку числа показов Google в регионе.

См. также: Сервисы анализа и подбора запросов, аналитика аудиторий поисковиков
Проверка индексации и отображения сайта поисковиками

Рассмотрим пример этих директив, взятый из файла .htaccess для некоторой cms. В качестве справочника будем смотреть на официальное описание работы mod_rewrite.

Options +FollowSymlinks
RewriteEngine On

RewriteCond %{HTTP_HOST} ^example\.ru$ [NC]
RewriteRule ^(.*)$ http://www.example.ru/$1 [L,R=301]

RewriteBase /

RewriteRule ^\.htaccess$ [F]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !\.(.*)$

RewriteCond %{REQUEST_URI} (.*)/$
RewriteRule ^(.*)/?$ /?$1&%{QUERY_STRING}

RewriteCond %{REQUEST_URI} !\.(.*)$
RewriteCond %{REQUEST_URI} !(.*)/$
RewriteRule ^(.*)$ /$1/ [R=301]

Options +FollowSymlinks переопределяет поведение сервера для символических ссылок. Обычно символические ссылки уже разрешены в файле конфигурации сервера httpd.conf, но если это не так, то эта директива необходима для работы mod_rewrite.
Второй строчкой идет “RewriteEngine On”. Когда она включена все дальнейшие директивы тоже выполняются, установка ее в off отключает выполнение всех нижележащих директив. RewriteEngine не наследуется и поэтому ее надо включать во всех файлах httaccess, в которых имеются директивы mod_rewrite. Следующие две директивы перенаправляют запрос с нашему сайту (example.ru), набранный без префикса “www” к нашему же сайту, но с префиксом “wwww”. Флаг [L] в RewriteRule приводит к отказу от обработки следующих RewriteRule, а флаг [R=301] делает внешнее перенаправление с помощью 301 редиректа. “http://www.example.ru” явно указывает префикс перенаправления. Далее в нашем примере идет директива “RewriteBase /”. Такая установка отменяет базу перенаправления по умолчанию – физического адреса директории, где лежит файл htaccess. Tак как физический адрес обычно не совпадает с URL, то она обычно необходима. Следующая одиночная директива “RewriteRule ^\.htaccess$ [F]” запрещает доступ к файлу, совпадающему с регулярным выражением “^.\htaccess$” с помощью флага [F]. Смысл регулярного выражения в скобках: ^ – начало строки; \. – символ точка, так как точка является специальным символом, то его экранируют; $ – конец строки. Следующая цепочка из трех директив “RewriteCond” отменяет перенаправление, если в запросе набран путь к файлу или директории, или путь содержит точку. Следующая директива “RewriteCond %{REQUEST_URI} (.*)/$” разрешает перенаправление для адресов, оканчивающихся на “/”. Следующая за ними “RewriteRule ^(.*)/?$ /?$1&%{QUERY_STRING}” помещает путь обращения, удовлетворяющий перечисленным условиям в строку запроса. То есть, если будет набран запрос “http://www.example.ru/15/?m=1″, что относительно корня сайта равно “15/?m=1″, мы получим “/?15&m=1″. В этой директиве представлена хитрая игра знаком вопроса. В первом случае он является специальным символом в регулярном выражении и означает “один или ноль символов”. Во втором появлении он означает начало строки запроса. Последние три директивы перенаправляют все запросы, не имеющие точки внутри и не оканчивающиеся на “/” на тот же URL, но с “/” на конце. Так как редирект здесь также внешний, то цепочка перенаправлений будет выполнена вновь уже для этого URL. Вообще говоря, это не совсем правильно и здесь правильнее было бы явно указать вместо слэша http://www.example.ru/ – RewriteRule ^(.*)$ http://www.example.ru/$1/ [R=301].

Рассмотрим основные возможности определения обратных ссылок, предоставляемые поисковыми системами.

Yahoo

Операторы “linkdomain:someURL”, “link:someURL”. Если набрать их в строке запроса, переводят yahooo в режим “site explorer” и показывают ссылки на данный URL.

Оператор “linkdomain:someURL -site:someURL” (см. примечание в конце статьи). Если набрать его в строке запроса, выдает результат в главной выдаче Yahoo. Такой режим удобен тем, что можно опустить неважные результаты.

Google

Оператор “link:someURL” дает очень небольшое подмножество ссылок. Панель вебмастера Google также не дает всех ссылок. Значительно большего результата можно добиться, используя команду “allinanchor:someKeyword”, если, например, вместо someKeyword ввести URL своего сайта.

Yandex

Единственный, хотя и довольно полный, способ получить обратные ссылки от Yandex это панель вебмастера.

AltaVista

Чтобы узнать в AltaVista обратные ссылки, нужно просто набрать URL сайта в строке запроса, можно также добавить исключение показа ссылок с самого сайта с помощью оператора “-host:SiteURL”. То есть, запрос должен выглядеть как “SiteURL -host:SiteURL”.

Alexa

Чтобы получить обратные ссылки с помощью Alexa, нужно в строке запроса набрать URL сайта и, после того как появится строчка с информацией о сайте, нажать на гиперссылку c числом найденых ссылок. Или можно просто набрать URL в браузере – “http://www.alexa.com/site/linksin/siteURL”, где “siteURL” – это URL сайта без префиксов http и www.

Для сравнения количественных и качественных оценок получения обратных ссылок был взят сайт с содержанием на двух языках – английском и русском, расположенный в зоне RU. Следующая таблица иллюстрируют полученные данные.

Для анализа полученных ссылок использовалась операция пересечения множеств – знак “*”, и объединение множеств – знак “+”.

*Примечание от 7.01.2011. В декабре 2010 yahoo отключил API для поиска обратных ссылок. Связано это с тем, что yahoo постепенно отдает управление своей выдачей microsoft (bing). В настоящее время bing уже управляет выдачей yahoo в США и Канада. К началу 2012 года процесс перехода будет окончен и для других стран. Тем не менее для РФ выдача пока еще контролируется yahoo. Работает и оператор linkdomain, но применять его надо не на главном сайте yahoo, а на российском яхо, по адресу http://ru.yahoo.com/.

Перспективы развития сервисов обратных ссылок

Выход из игры Yahoo как главного поставщика обратных ссылок освободит дорогу набирающим популярность частично (opensiteexplorer.org) или полностью платным ( majesticseo.com) сервисам получения обратных ссылок.

p.s. Пользуйтесь нашим инструментом экспресс анализа сайта для доступа к сервисам обратных ссылок

Организация индекса поисковиков на примере Google (по материалам статьи Сергея Брина и Лэрри Пейдж).

Каждый документ в глобальной сети получает свой docID.
Имеется однозначное соотвествие между контрольной суммой url документа и его docID.

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

Репозиторий представляет собой файл, содержащий полный html код для каждого docID.

Индекс документов содержит указатель на код html в файле репозитория, контрольную сумму документа, статус документа и другую статистику. Для документов, которые уже проиндексированы, также записывается их title.

Словарь содержит все различные слова в Вебе, их число равно нескольким миллионам.

В списке вхождений содержится позиция каждого слова в документе, а также ряд характеристик слова. Есть две разновидности вхождений: мнимое (fancy) вхождение и явное (plain).
Мнимое вхождение используется для title, URL, анкоров и мета тегов. Явное во всех остальных случаях. Анкоры представляют собой текст ссылок на наш документ в других документах.
Для явного вхождения указывается позиция слова и начинается ли слово с заглавной буквы, а также относительный размер шрифта. Для мнимого вхождения указывается заглавная буква и позиция. Для вхождения в анкор поле позиции делится и половина используется для указания на документ, в котором стоит ссылка на наш документ.

Мне кажется, что при такой структуре поле позиции явным образом ограничивает как длину индексируемого документа, так длину анкоров и число ссылок на наш документ, содержащее данное слово. В оригинале для документа 12 бит, для анкора по 4 бита на позицию и число ссылок, для просто мнимого вхождения – 8 бит на позицию. В статье говориться, что если слово стоит в документе далее чем на позиции 4096, то используется число 4096. Также говорится, что структура базы будет меняться.

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

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