Защита от попыток выбивания из индекса

1727
86

Как известно, украинский Интернет довольно сильно отстает от западного сегмента. Отстает он не только в хорошем смысле, но и в плохом. Распространенные на Западе методики «борьбы с конкурентами» в поиске довольно редко встречаются на Украине, и возможно этой статьи и не было, если бы за последний год с этими техниками не пришлось столкнуться 3 раза на клиентских сайтах и один раз на сайте WebPromo.

Последствия были разные: от понижения позиций до полного выпадения страниц с индекса. Как ни странно, ссылочный спам, о котором в Рунете ходят страшные легенды, играл совершенно нерешающую роль и имел значение сопутствующей проблемы. Основная проблема была вызвана попытками «доброжелателей» увеличить количество дублированного контента как на самом сайте, так и на внешних ресурсах. Если говорить о внутреннем контенте, были использованы дыры в настройках сервера и самой системе управления контентом. На данный момент в интернете есть 3 часто используемые веб-серверные платформы: Apache, ISS, NGINX. APACHE является самой уязвимой для различного рода гуру в мире хакеров, однако из-за этого представляет наименьший интерес для нас, т.к. пропатчена и заапдейтина вдоль и поперек. Как написать htaccess, прописав все SEO редиректы, и заблочить ненужные запросы, сможет рассказать каждый второй.

Основная проблема любого владельца хостинга на apache — это отсутствие htaccess как такового, что позволяет работать с любым созданным URL напрямую. Соответственно мы имеем любой готовый дубликат страниц:

  • http://site.com/index.php
  • http://site.com/index.html
  • http://www.site.com/
  • http://www.site.com/main.html
  • http://www.site.com/home.html
  • http://www.site.com/content/index.php и.т.д

«Доброжелатели» вгоняли в индекс эти страницы, и в результате получался полный дубликат главной страницы, на которую обычно продвигаются наиболее важные и наиболее конкурентные запросы.

Решение проблемы: Продвижение любого проекта должно начинаться с настройки стандартных SEO редиректов (301 редирект) с версии сайта без www на версию с www, с /index.php на главную и.т.д.

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

Создавалось несколько десятков тысяч страниц по типу http://www.site.com/?pi=1, http://www.site.com/?pi=2 и т.д., которые при помощи активного ссылочного спама вводились в индекс. В результате в поиске возникал множественный дубликат посадочных страниц.

Решение проблемы: В первую очередь закрывайте все динамические URL через robots.txt:

User-agent: *
Disallow: /*?

Так вы закроете в первую очередь все URL в которых есть «?». Но это опять же не решит проблемы. Лучшее средство — всегда возвращать 404 ответ сервера с URL, которых физически нет на вашем сайте, либо используя, мета тэг:

<meta name=”robots”
content=”noindex,follow”>

Третья проблема с дубликатом, с которой пришлось столкнуться, уже использовала внешние источники для дублирования, а именно статические proxy. Объемы, с которыми подходили к вопросу на «противоположной стороне», тоже были промышленными. Из тех, которых удалось определить – это порядка 10 тысяч proxy.

Сайты пропускались через proxy, на выходе получался URL вида http://proxy.com/sitecom/, который попадал в индекс опять же благодаря обильному ссылочному спаму.

Решение проблемы: Выпарсить список прокси из индекса allinurl: http://site,com -site: http://site,com, также можно использовать обратные ссылки по MajesticSEO, после чего IP-адреса на которых расположены proxy были закрыты .htaccess.

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

Оставить комментарий

Комментарии | 86

  • Основная проблема любого владельца хостинга на apache – это отсутствие htaccess как такового

    вот тут не понял, речь о nginx? там тоже все прекрасно настраивается, или автору попался хостинг исключительно с энжениксом и без доступа к настройкам вебсервера?

    Проясните, а то пока тянет на мысли о том что «наша вебстудия не знает как настроить вебсервер для отдачи страницы 404»

  • Сергей, проблема редиректов и генерации URL это проблема любой серверной основы, будь это apache или nginx или ISS. Просто apache это самая распространенная серверная платформа на данный момент особенно в рунете. Поэтому я и остановился конкретно на ней. Я не имел в виду, что мы столкнулись с данной проблемой и не знали как её решить. Это просто самый распространенный пример любого клиента. И опять же учитывайте тот факт, что есть CMS системы которые имеют свою систему генерации URL часто их потом начинают обрабатывать редиректами, иногда у CMS систем несколько правил генерации URL к примеру тот же WordPress, который генерирует URL к постам через post? или конкретно по category/post-name. В любом случае редиректы надо настраивать без разницы какая у вас платформа и прописан ли у вас 404 ответ сервера. Для поисковой системы domain.com/index.php domain.com/index.php?new-page это 2 разных URL которые она готова принять в индекс.

    • Меня смутила конкретно ваша фраза «Основная проблема любого владельца хостинга на apache – это отсутствие htaccess как такового» (к сожалению теги дискуса не выделяют контент так как должны)
      На хостинге с апачем нет хтассес по определению? кактак?

      по 404 проблеме: как по мне — надумана, отдавать на неправильный урл 404 ошибку — это базовая возможность. Если же в системе накручено правил в которых она сама не может разобраться, или накуртил их там криворукий человек — меры применяются соотвественно к 1 или 2. По вордпрессу не отвечу, не работаю с ним.

      по последней: опять же, не помню как давно начала работать rel=author.. но что мешало в  тексте страницы использовать абсолютные урлы и вы бы получили 10К ссылок с прокси на свой сайт)) Не уверен правда насчет санкций ПС, но идея интересная.

      • Сергей, на хостинге с apache нет htaccess файла с правильно настроенными редиректами и deny IP адресов спаммеров, а так же badbots.

        • а что мешает использовать нормальный хостинг? хостингов то с шелом и полным доступом к своему юзеру валом, делайте там все что угодно, хоть апач заново скомпиляйте. проблема с .htaccess с пальца высосана.
          и apache не самый распространенный веб–сервер и как раз в рунете и уанете тоже — http://w3techs.com/technologies/breakdown/ws-nginx/top_level_domain

          • По ссылке  — данные по распространненности nginx.
            правильная вот http://w3techs.com/technologies/overview/web_server/all
            и все верно — апач самый распространенный

          • я для рунета и уанета хотел показать, а в мире все правильно на третьем месте nginx.

          • дык 
            + там учтены только ЗОНЫ, а рунет уанет не только на ру и уа доменах сидит какбы
            + «We include only the top 1 million websites (according to Alexa) in the statistics in order to limit the impact of domain spammers» тут с ними отчасти можно согласиться, но с другой стороны — сколько вебсайтов за этим порогом в уарунете? Думаю большинство))

          • вот еще статистика http://stat.webnames.ru/?show=http&what=&date=1309464000 тенденция таже, не думаю что реальная картина особо отличается.

          • да я собсно только ЗА быстрые вебсервера, но справедливости ради стоит заметить, что статистика не учитывает тот факт, что апач или другой вебсервер может стоять бэкендом и т.п.
            Только не надо больше статистики, я готов признать что Нжинкс лидирует в уа-ру))

          • ок, не буду=)
            ну… апач на бекенде это другая история, там наверное 70-80% точно буит, многие привыкли.

          • Александр, спасибо за приведенную статистику. В данном случае видно, что доля apache хоть и меньше, но велика. К моему великому сожалению, проблема не высосана из пальца. Она насущная. Откройте 10 любых украинский сайтов проверьте наличие robots.txt а потом SEO редиректы. Вы увидите проблематику сразу же. Никто этим не занимается. Страницы попадают в индекс даже без помощи злоумышленников, тем самым понижая качество данного сайта. Цель данного поста показать, что не у всех все хорошо и стоит уделить этому время, иначе он «уделит» потом время Вам и тогда борьба с последствиями может занять не день и не два.

        • Антон, мы видимо то ли говорим о разных вещах, то ли вы меня не понимаете.
          «на хостинге с apache нет htaccess файла с правильно настроенными редиректами и deny IP адресов спаммеров,» — я честно говоря все равно не понял о чем речь, или вы считаете что на хостинге должны быть сразу конфиги для любой цмс на все случаи жизни? брррр
          У апача есть уровни конфигурирования, на мифическом типовом хостинге который мы обсуждаем — есть как минимум доступ к уровню хтассес.
          Комбинация хтассес + роботс — дает хорошие возможности по управлению  урлами и индексацией. 

          ИМХО, то что  сайт пробили по списку типа которого вы приводите — проблема не хостинга и не апача, проблема уж извините криворукого «админа» или кривой цмс. Конкретно «domain.com/?utm=» закрывается в роботс

          по последней: прикинул сейчас, очень забавно. Если на прокси наращивалось ссылочное, то указать ПС на первенство и правда довольно затруднительно. Только затраты нападающего впечатляют… можете для статистики общие данные привести какие-то? Тематика ресурса и т.д.?

          • Сергей, цель статьи — донести проблематику широкой аудитории. Когда мы первый раз столкнулись с этими техниками — был временный ступор. Не хотелось бы, чтоб у кого-то повторилась эта же ситуация, но лучше быть к этому готовым. Да на любом сервере нету настроенного htaccess или robots.txt и о том как их настроить знают не многие. Поэтому мы и акцентируем на этом внимание читателей.
            Я абсолютно с Вами согласен это проблема клиентов, администраторов(если таковые имеются), программистов(которые создавали или настраивали CMS). Кстати о закрытии динамики в robots.txt если страницы попали в индекс то закрытие через роботс не поможет.
            Через прокси работали по нам.

          • С попавшими ошибочно в индекс страницами решается уже не через роботс, а через «человечекс», путем тыкания кнопочек в центрах вебмастеров и слезных душераздирающих писем в поддержку ПС (это я излагаю чтоб понятно было широкой аудитории :)) )

            П.С. да все забываю насчет «широкой аудитории».. была же здесь уже статья насчет использования экселя, я как-то не сделал выводов.

          • Да, вот за это и спасибо!
            Статья заставила задуматься о проблеме — а решение мы и сами найдем, тем более, что диагнозы у всех разные!

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

          • Если бы все покупали DS то хостинг повайдеры были бы самые счастливые бизнесмены в мире 🙂 Но пока что все покупают шареды, по одной простой причине — это дешево и вроде бы как сайт в онлайне. Значит хватит.
             И это реальность.

          • Если бы все покупали DS то хостинг повайдеры были бы самые счастливые бизнесмены в мире 🙂 Но пока что все покупают шареды, по одной простой причине — это дешево и вроде бы как сайт в онлайне. Значит хватит.
             И это реальность.

  • Удивлен увидеть такую информацию и хорошо что хоть где-то в УАнете у нас её можно прочитать. Проблема в том что о website security пишут сейчас только на спец. блогах в буржунете, потому как там это более чем насущная проблема для каждого.
    Кстати Вы забыли упомянуть о rel=canonical, это так же помогает бороться с дублированием страниц через сторонние ресурсы.

  • Спасибо, полезная информация

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

  • А как вы обнаружили дубликаты. для создания которых использовались proxy? 

    В смысле как их найти, когда знаешь, что они уже есть понятно, а вот как обнаружили что они есть?

    • я так же бы посоветовал blekko.com вводите адресс сайта и нажимаете закладку SEO вопервых там и куча информации по ссылкам и есть закладка duplicate content — но этот метод хорош для западных сайтов.
      Так же регулярно проверяйте свой сайт через http://copyscape.com/
      Еще один совет настройте себе Google Alerts по запросам своего доменого имени и бренд нэйму. Поможет как в отслеживании спама так и в управлении репутацией.

    • я так же бы посоветовал blekko.com вводите адресс сайта и нажимаете закладку SEO вопервых там и куча информации по ссылкам и есть закладка duplicate content — но этот метод хорош для западных сайтов.
      Так же регулярно проверяйте свой сайт через http://copyscape.com/
      Еще один совет настройте себе Google Alerts по запросам своего доменого имени и бренд нэйму. Поможет как в отслеживании спама так и в управлении репутацией.

  • Просматривали ссылочное через MajesticSEO, наткнулись на пару десятков, начали искать активнее.

  • Просматривали ссылочное через MajesticSEO, наткнулись на пару десятков, начали искать активнее.

  • Статья очень понравилась , много интересной информации.

  • Если бы все эти изъяны закрывались по умолчанию повода для статьи действительно не было бы…

  • К сожалению все это не панацея, уже есть автоматизированные программные комплексы по устранению конкурентов из SERP.

  • Остается помогать Google в борьбе с не добросовестными SEO-шниками. =)

  • Вывод статьи — Мониторинг индексации рулит.
    Вывод 2 — настройка индексации входит в работы по оптимизации сайта.

    Вариант профилактики.

    К стандартным Joomlaвским настройкам htaccess а-ля

    ########## Begin — Rewrite rules to block out some common exploits

    добавляем канонизацию помеченных контекстом урлов:

    RewriteCond %{QUERY_STRING} ^utm_source=
         RewriteRule (.*) /$1? [R=301,L]

    и склейку www:

    RewriteCond %{HTTP_HOST} ^(.*).site.com [NC]
         RewriteRule ^(.*)$ http://site.com/$1 [L,R=permanent]

    плюс в зависимости от конкретных задач и cms.

    —————————————————————————
    Интересно, вот seoшники — люди умные — а всё же некоторые умудряются использовать в конкурентной борьбе заведомо проигрышные стратегии… Почему?

  • Тема поднята хорошая, полезная. И, судя по числу каментов, своего читателя статья нашла… 
    но это явно не для широкой аудитории. Я понял, что есть дырки, которые надо залатать. Но как? Как последовать совету «Выпарсить список прокси из индекса allinurl» мне не понятно. Антон, если ЦА статьи действительно широкая аудитория, я буду благодарен  за версию «для чайников».

    • Для того чтобы построить базовую «защиту» если это можно считать защитой — ничего парсить не надо, достаточно настроить правильную отдачу урлов вебсервером и закрыть ненужное в роботс.тхт
      Конкретика зависит от используемого ПО, достаточно изучить обсуждения в интернете по вашему ПО, если базовая версия прилагаемых файлов вас не устраивает.

    • Денис, я соглашусь с Сергеем, что конкретная версия «для чайника» будет зависеть от конкретной ситуации. 

      • ОК, понял. Уложу для «широкой аудитории», смысл статьи в несколько предложений: 
        Мы пострадали от дыр в сайте. В вашем они тоже наверняка есть. Вот список непонятных для вас слов, которые нужно прогуглить, чтобы понять, что делать в вашем конкретном случае.

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

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

          • Для широкой аудитории основное показать следующее:
            1. Проблема есть.
            2. Она решается.
            3. Решается программистами,  а не магией и заклинаниями. 
            В целом замечание принято, буду стараться минимизировать профессиональный сленг в дальнейшем.

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

            Просто четче определяйте аудитории. Я просто первый раз не до конца понял интересную мне статью на АИНе.   И это при том, что я знаю, как править .htaccess.

        • Денис вы сильно критично относитесь к теме или как-то не очень внимательно читали 🙂 Если отдатьстатью в руки минимальному специалисту то он как минимум повторит все, что описано в ней для своего сайта. Настроит редиректы (поищет как это делается для его платформы в гугле), зальет robots.txt, настроит Google Alerts для спам запросов, запретит обращение с айпишников вебпроксей. Любые другие конкретные вопросы или проблемы на то и являются конкретиными что их надо решать в индивидуальном порядке.

          • Юрий, я вижу разницу между «широкая аудитория» и «минимальный специалист», и указываю на эту разницу. Только и всего. 🙂

          • Денис, стеб по теме понял, таки да для широкой аудитории тут нужны серьёзные разъяснения )

  • «Лучшее средство – всегда возвращать 404 ответ сервера с URL, которых физически нет на вашем сайте» 
    а как отнесется к этому настроенный «адвордс» с включенной пометкой тегами? 😉

    «Выпарсить список прокси из индекса allinurl: http://site,com -site: http://site,com, также можно использовать обратные ссылки по MajesticSEO, после чего IP-адреса на которых расположены proxy были закрыты .htaccess»
    Может перерасти в бесконечную борьбу — найти новые и новые прокси не проблема совсем

    • AdWords конечно же отнесется враждебно. 404 возвращаем для несуществующих статических страниц, а для динамики — закрытие через robots.txt. 
      Бесконечной борьбы, как и бесконечного двигателя не существует. Или у «них» закончатся прокси, или мы сдадимся. Первое гораздо вероятнее.

      • Думаю, здесь лучше закрыть в роботсе по gclid  (вот адвордс то и помечает, как знаете) ну мож еще какие-то «экзотические» дргуе используемые пометки
        А все остальное с 404-й в том числе и с параметрами но исключая gclid (ведь если уже «напопадало» в индекс «левака» — сами знаете что через один только роботс ПС не сразу выбросит)

      • Думаю, здесь лучше закрыть в роботсе по gclid  (вот адвордс то и помечает, как знаете) ну мож еще какие-то «экзотические» дргуе используемые пометки
        А все остальное с 404-й в том числе и с параметрами но исключая gclid (ведь если уже «напопадало» в индекс «левака» — сами знаете что через один только роботс ПС не сразу выбросит)

    • utm можно редиректить на главную и не будет потери передачи параметров. проверенно на опыте. Так что всю динамику можно так же редиректить на главную страницу. 
       Выпарсивать списки проксей надо, но они не бесконечны. Думаю что несколько заходов будет достаточно да и вы можете просто набрать в Google запрос list of web proxy это вам даст 99% основной базы проксей.

      • Да ну, анонимок довольно много
        дело ведь в том, что способ с проксями не такой уж действенный и затратность в плане время-деньги на него в результате грамотного продвиводействия не будет стоить «выделки»

      • а если ссылка с utm должна вести на внутреннюю страницу?
        также, если настроить редирект, который отбрасывает utm, разве это не будет мешать отслеживать кампании?
        имхо лучше просто настроить пометку через # (_setAllowAnchor).

        я не SEO специалист, поэтому задам, возможно, пару глупых вопросов:

        1) неужели к utm и gclid у поисковиков нет «особого» отношения, и это тоже дублированный контент? кто-то убедился в этом на практике?
        2) неужели rel=canonical не достаточно для решения этой проблемы?

        Спс

      • Зачем редиректить на главную урлы с утм-метками? Это же бред.

        Можно редиректить страницу саму на себя, а утм-метки передавать пушем (js в html).

    • 1. Делаем исключения для  гет переменной gclid и все ок.
      2. Не задача закрыть все прокси, задача показать конкуренту что мы видим и реагируем, чтобы он отстал.

  • Шахин, utm и gclid воспринимаются, как и остальные динамичные URL, правильно настроенный rel=canonical решает проблему с внутренним дубляжом, но в случае с прокси его не достаточно.

    • Ну да, для прокси — блокировка IP, как вы и писали. Плюс может абсолютные url или относительные + base могут чуть-чуть помочь, что скажете? Хотя, наверное, только в случае какого-то простенького прокси.

      Еще одно уточнение: штраф за дублированный контент сайт получает в любом случае или только если он признан НЕ первоисточником? В последнем случае не совсем понятно, как прокси вредит давно существующим страницам?

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

    • Думала rel=canonical спасает. Спасибо за информацию

      • Читал читал все коменты и думал когда же хоть один здравый человек про rel=canonical скажет?!

        Конечно спасает, вовсяком случае для Гугла и Яху и Бинг это однозначмо решение большинства проблем с дабл контентом. Проблема что мало кто умеет его грамотно настраивать. В большинстве встречавшихся мне случаев, canonical просто генерируется по новому дубльУРЛ и тогда от него даже больше вреда чем без него.
        .htacess и robots.txt конечно тоже важны.
        Очень мало кто из прогеров понимает истинное предназначение и силу в Canonical, а потому неумеют его правильно прикручивать.
        На своих сайтах ставлю в ручную, без возможности авто-генерации, но конечно есть и автоматизированные методы.

  • Важная тема. Нужно обсудить в формате следующего #SeoCafe

  • Кстати а когда #SeoCafe? Надо бы собраться обсудить план действий. Все же хочется мне подготовить материалов. 🙂

Поиск