Яндекс вебмастер - полное руководство. Отклонение всех обратных ссылок

Google собирается отказаться от классического адреса интернет-страниц в своем браузере. Компания планирует укрепить средства защиты пользователей в сети.

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

Каждая интернет-компания пытается внедрять свои способы защиты пользователей, но все это пока недостаточно эффективно. Согласно McAfee, кибератаки в прошлом году принесли миру убытков на $600 млрд (примерно половина действующего бюджета США).

Принять радикальные методы безопасности хотят создатели одного из самых популярных браузеров - корпорация Google.

Вчера браузеру Сhrome исполнилось 10 лет и, помимо существенных изменений в , разработчики планируют cерьезно укрепить надежность адресной строки.

Google намерен отказаться от использования традиционных интернет-адресов URL, поскольку они являются слишком сложными и непонятными для пользователей.

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

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

“Я еще не знаю как точно это будет выглядеть, потому что сейчас мы активно обсуждаем это в команде. Я знаю: что бы мы не предложили - это будет спорным”, - рассказала в интервью WIRED директор технологий в Chrome Париса Табриз. “Это один из самых главных вызовов в работе со старой, открытой и разваливающейся платформой. Изменения в любом случае будут спорными, независимо от того, что произойдет. Важно, что мы делаем это, поскольку все недовольны URL. Это вроде как отстойно”.

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

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

Очевидно, что Google пока не имеет определенного решения того, как будут функционировать веб-страницы без URL-адресов.

Но компания работает над этим еще с 2014 года. Несколько лет назад они экспериментировали с так называемой “функцией подлинности”. Браузер показывал только основное имя домена сайта, чтобы гарантировать подлинность подключения именно к этому домену. Чтобы увидеть полный URL-адрес нужно было нажать на кнопку, которая отвечала за эту функцию.

Позже, Google перешел на другую систему веб-шифрования HTTPS, которая работает в Сhrome и по сей день.

Напомним, URL - это единый указатель интернет-ресурса, который был изобретен как универсальный определитель нахождения в сети одним из создателей Всемирной паутины Тимом Бернерсом-Ли в 1990 году.

Обновленного сервиса для вебмастеров.

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

Нововведений достаточно много, но сегодня хотелось бы остановиться на отчете «Статистика индексирования», и как с его помощью можно обнаружить дубли и мусорные страницы.

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

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

На странице отчета «Статистика индексирования» мы сможем узнать:

Какие страницы сайта сканирует робот;
Какие страницы робот исключил из поиска;
Какие страницы проиндексированы и находятся в индексе поисковой системы Яндекс.

Для поиска дубликатов и мусорных страниц достаточно проанализировать полный список загруженных Яндексом url-адресов.

В сервисе есть возможность выгрузить архив со всеми url-адресами, которые были просканированы роботом Яндекса. Для загрузки нужно перейти по ссылке:

В итоге мы получаем файл в формате.tsv, открыть который можно через Excel, Libre Office или простым блокнотом.

Файл также содержит следующие данные:

Коды ответа сервера.
Дату последнего сканирования в формате Unix time , преобразовать можно, задав в консоли запрос вида date -r .
Проиндексированность страниц.
В столбце «Double» находятся ссылки на дубликаты страницы, если они есть.

Примеры найденных ошибок на сайтах благодаря данным о загруженных страницах роботами Яндекса:

Сайт asteria.ua:

Были обнаружены следующие страницы:

http://asteria.ua/special/razdel/104.html
http://asteria.ua/uslugi/razdel/77.html
http://asteria.ua/kompaniya/razdel/27.html
http://asteria.ua/partneri/razdel/4.html

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

Ещё несколько страниц дубликатов:

http://asteria.ua/index.php?get=easytostart.html
http://asteria.ua/index.php?get=vkluchenie.html
http://asteria.ua/index.php?get=uslugi.html
http://asteria.ua/index.php?get=kontakti.html
http://asteria.ua/index.php?get=shtraf_uvelichili.html

Эти страницы, на момент анализа, перенаправляли пользователей на корректный url-адрес с ЧПУ, но отдавали код 200, а не 301.

Сайт novebti.ua:

Были найдены дубликаты главной страницы сайта:

http://novebti.ua/?razdel=uslugi_view&content=41
http://novebti.ua/?razdel=uslugi_view&content=1
http://novebti.ua/?razdel=uslugi_view&content=26
http://novebti.ua/?razdel=reviews

С этих страниц нужно написать link rel=»canonical» на главную страницу сайта.

А также дубликаты других страниц сайта:
http://novebti.ua/index.php?do=contacts
http://novebti.ua/index.php?do=uslugi/razrabotka_gradostroitelnogo_rascheta

Страницы пагинации и тегов:
http://novebti.ua/faq?ask=true?p=35
http://novebti.ua/article?tag=%CD%EE%E2%EE%F1%F2%E8%20%EA%EE%EC%EF%E0%ED%E8%E8
http://novebti.ua/faq?ask=true?p=40
http://novebti.ua/faq?p=47

Страницы такого типа лучше всего закрывать при помощи мета тега robots=»noindex, follow».

Сайт asiamshop.com.ua:

Было обнаружено множество страниц вида:
http://asiamshop.com.ua/component/jcomments/captcha/32798
http://asiamshop.com.ua/component/jcomments/captcha/42306

Таких страниц много десятков, они генерируются модулем комментирования jcomments, такие страницы нужно закрыть от сканирования, так как они не несут никакой ценности.Так как у этих страниц нет возможности прописать мета тег robots, то лучше их закрыть при помощи файла Robots.txt.

Вывод:

Основное преимущество сервиса состоит в том, что мы анализируем базу url-адресов поисковой системы, а не парсера страниц сайта, который не сможет найти url-адреса на которые нет внутренних ссылок.

Используя инструмент «Статистика индексирования» в новом Яндекс Вебмастере можно в течение 30 минут проанализировать страницы, которые посещает робот, обнаружить проблемы и продумать варианты их решения.

Если вы нашли ошибку, выделите участок текста и нажмите Ctrl + Enter или воспользуйтесь ссылкой , чтобы сообщить нам.

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

То же самое относится к переадресации на сайты для мобильных устройств. Пользователям смартфонов будет удобнее работать не с обычной версией сайта, а с мобильной. Поэтому переадресация, например, с example.com/url1 на m.example.com/url1 оправдана. Однако скрытая переадресация мобильных пользователей на посторонние страницы мешает работе и нарушает рекомендации Google для веб-мастеров .

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

Что, где, когда? Сегодня существует множество способов создать сайт. От готовых движков, плагинов и тем, до комфортных IDE, которые не требуют практически никаких знаний в области вёрстки. У многих крупных или старых ресурсов давно (ещё во времена обычных телефонов с JAVA-браузерами) появилась мобильная версия, которая может сильно отличаться от «полноценной». Тем не менее, мы считаем, что содержание сайта и предоставляемая информация должны совпадать по сути на всех устройствах. Давайте рассмотрим основные проблемы переадресации мобильных пользователей.

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

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

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

Общая программа действий проста, как раз-два-три: определить, изолировать, предотвратить. За дело!

Как обнаружить скрытую переадресацию для мобильных устройств? Чтобы грамотно бороться с проблемой, её надо определить. О том, что кто-то «ворует» ваших мобильных пользователей вы можете и не догадываться, пока кто-нибудь не пожалутеся или вы сами случайно не наткнётесь на результаты работы вредоносных скриптов.

Сообщения от посетителей могут нести мало полезной информации и нагонять панику: «Я открыл ваш сайт, а он меня А-а-а-а-а-а, У-у-у-у-у-у, Ы-ы-ы-ы и предлагает тухлые фрукты по оптовым ценам» . Ни проблемной страницы, ни информации об устройстве или браузере.

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

Откройте сайт на смартфоне и посмотрите, не попадете ли вы на другой ресурс
Мы рекомендуем проверить свой сайт, перейдя на него из результатов поиска Google на смартфоне. При современном разнообразии на рынке мобильных устройств отладку удобнее проводить с использованием эмуляции мобильных устройств в компьютерных браузерах. Данную функцию поддерживают Chrome , Firefox и Safari . В последнем случае (Safari) потребуется открыть настройки браузера и установить флажок «Показывать меню „Разработка“ в строке меню».
Изучайте отзывы посетителей
Пользователи могут видеть ваш сайт не так, как вы. У кого-то старый браузер, укого-то гора экстеншнов (они тоже могут подвергнутся атаке и начать подсовывать рекламу / переадресовывать пользователей). Всегда читайте отзывы посетителей и обращайте внимание на их жалобы, чтобы вовремя выявлять проблемы. Если требуется, задавайте уточняющие вопросы, попросите прислать скриншот или рассказать, как именно пользователь попал на проблемную страницу.
Отслеживайте действия посетителей и анализируйте статистику сайта
Необычные действия мобильных пользователей можно обнаружить, изучая данные веб-аналитики. Стастистика - мощнейший инструмент, который позволяет выявлять проблемы там, где одиночные проверки и тесты ничего не показывают. Например, если среднее время, проведенное на сайте владельцами мобильных устройств (и только ими), резко сократилось - это может быть вызвано переадресацией.
Чтобы сразу же узнавать о значительных изменениях в поведении мобильных пользователей, можно настроить специальные оповещения в Google Analytics .
Попробуйте создать оповещение о резком снижении времени, проведенного мобильными посетителями на сайте, или уменьшении их количества. При этом следует помнить, что значительные изменения этих показателей не всегда являются непосредственным следствием скрытой переадресации, но снижение посещаемости всё равно стоит изучить. Вы же сайт не просто так делали?

На моем сайте обнаружена скрытая переадресация для мобильных пользователей. Что делать? Допустим, вы нашли проблему? Что дальше? Как с ней бороться? Шаг второй: изолировать источник проблем. Источников переадресации может быть два - внешнее или внутреннее воздействие.

В первом случае кто-то получил доступ к вашему сайту (уязвимости для популярных движков регулярно находятся и не всегда оперативно закрываются). Во втором вы, сами того не желая, заложили «бомбу замедленного действия», вставив какой-нибудь скрипт, не проверив его содержимое. Опционально, движок сайта мог самостоятельно обновить элементы с какого-нибудь репозитория, который был взломан. В любом случае, для устранения подобных проблем алгоритм одинаковый.

Проверьте, не взломан ли сайт
Откройте раздел Проблемы безопасности в Search Console: если мы обнаружили взлом, внутри вы найдёте соответствующее оповещение.
Кроме того, стоит изучить дополнительную информацию о типичных признаках взломанных сайтов и примеры из нашей практики . Если вы используете какой-либо движок или фреймворк - посмотрите новости соответствующего сообщества, быть может с проблемой столкнулись не только вы.
Проверьте, нет ли на сайте посторонних скриптов и элементов
Если ваш сайт не взломан, проверьте, нет ли на нем сторонних скриптов или элементов, выполняющих переадресацию. Для этого выполните следующие действия:
Внимание! Прежде чем вносить какие-либо изменения в работающий сайт, создайте резервную копию сайта, проверьте её работоспособность.
Найдите страницу, на которой осуществляется переадресация пользователей. Если на ней находятся чужие скрипты и элементы - смело удаляйте их по одному.
После каждого удаления проверяйте с мобильного устройства или через эмулятор, происходит ли переадресация.
После локализации элемента, отвечающего за скрытую переадресацию, удалите его со всех страниц. Если элемент критически важен и необходим для функционирования сайта - попросите его поставщика помочь вам с отладкой.

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

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

Проверьте разрешения на чтение / запись в определённые папки, если запись не требуется - поставьте атрибут read only, он помешает злоумышленникам и вредоносам, попавшим через узкую лазейку, прописаться в рабочих папках и повысить уровень привилегий.

Используйте Search Console Если пользователь перенаправляется на другие страницы с целью показать контент, отличный от представленного в результатах поиска, это является нарушением рекомендаций Google для веб-мастеров. Подробнее о скрытой переадресации можно прочитать .

Команда Google по оценке качества поиска может принять меры в отношении таких сайтов, например удалить URL из нашего индекса. Если подобное случится, вы, как владелец сайта увидите в Search Console соответствующие оповещения. Это лишь одна из причин, по которой мы рекомендуем вам зарегистрировать аккаунт в Search Console. Сам сервис крайне гибок и позволяет не только получать своевременные уведомления о проблемах, но и анализировать текущее состояние сайта, а также направлять в Google запросы на повторную проверку. Быстро, удобно, а главное - в одном месте.

One more thing Выбирайте рекламодателей, которые не будут направлять ваших посетителей на неожиданные страницы. Если вы стремитесь к развитию доверительных отношений в отрасли - ознакомьтесь с рекомендациями по работе в рекламных сетях. Вы можете начать с изучения рекомендаций IAB по обеспечению качества площадок .

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

Всем привет! В данной статье затронем тему безопасности, а именно безопасный протокол передачи данных — https. Если вы обратили внимание мой блог, на котором вы сейчас находитесь работает по протоколу https, на который я перешел недавно. Также, на https я перевел один из моих клиентских сайтов. Пришлось немного повозиться и понервничать, но в итоге все получилось. Я подумал, что надо обязательно написать об этом на блоге — как перейти с http на https безболезненно для сайта, тем более эта тема я считаю уже популярна, т.к. сегодня все больше и больше сайтов переходят на https.

Что меня побудило перейти на протокол https? В последнее время мне на глаза стали попадаться вот такие заголовки: Браузер Mozilla Firefox в скором времени перестанет поддерживать небезопасные http-соединения; всем государственным сайтам перейти на HTTPS; C января 2017 года все сайты, передающие секретные данные (пароли, номера кредитных карт и т.д.) по незащищенному соединению в браузере Google Chrome будут помечаться как небезопасные. Плюс ко всему где-то в интернете читал, что скоро всем сайтам придется перейти на протокол https в обязательном порядке. Я подумал, что в один прекрасный день все равно эта участь постигнет и меня. Так зачем же тянуть? Тем более хостинг beget.ru , на котором я сижу предоставил возможность для приобретения бесплатных SSL-сертификатов. В общем, собрал всю необходимую информацию по тому, как перейти с HTTP на HTTPS и сделал это. 🙂

Структура статьи

Зачем нужно использовать https и что имеется ввиду под безопасностью?

Если говорить кратко, то протокол https позволяет отправлять запросы на сервер с нашего сайта в зашифрованном виде, гарантируя при этом, что эти самые данные не будут перехвачены хакерами. Элементарный пример передаваемых данных — это авторизация на сайте (или регистрация). В процессе авторизации мы отправляем запрос на сервер, который содержит логин и пароль. Так вот, если отправлять эти данные по небезопасному соединению, то они легко могут быть перехвачены, что в результате может привести к взлому сайта. Работу протокола https обеспечивают SSL сертификаты. Они бывают разных видов, про виды сертификатов читайте ниже.

Весь процесс я решил разделить на шаги и выполнять их как раз именно в такой последовательности. Также ниже я дам рекомендации по переходу для популярных cms Joomla и WordPress. У каждого есть свои особенности.

Приобретение сертификата

Для начала необходимо приобрести SSL сертификат, чтобы ваш сайт был доступен по обоим протоколам — http и https. Давайте сначала внесем некоторые ясности в виды SSL сертификатов.

Виды сертификатов Простые сертификаты

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

Wildcard SSL

Wildcard SSL — прекрасно подойдет сайтам с наличием поддоменов. В данном случае достаточно выпустить один сертификат, который будет работать на всех поддоменах и позволит сэкономить деньги на покупку отдельных сертификатов.

Мультидоменные SSL сертификаты

Мультидоменный SSL сертификат — сертификат, который может поддерживать сразу несколько доменов. Также, как и Wildcard позволит сэкономить денежку. Так что имейте ввиду, если у вашей компании или проекта имеется несколько доменных имен, то выбирайте именно мультидоменный сертификат.

EV (Extended Validation) сертификаты

EV (Extended Validation) — расширенная проверка компании. Данный вид сертификата могут позволить себе купить только крупные компании. Для его получения необходимо предоставить всю подробную информацию о компании — название организации, реквизиты, наличие о государственной регистрации, реальные звонки для утверждения полученных данных и многое другое. Да, получение такого вида сертификата дело хлопотное, но поверьте оно того стоит. Более того, рядом с адресной строкой в браузере будет отображаться название компании. Вот как это выглядит на примере сайта Сбербанка.

Смотрится круто и повышает доверие потенциального клиента. Поэтому, владельцам крупных компаний рекомендуется выпуск именно EV сертификатов.

Сертификаты с поддержкой IDN

Не все сертификаты поддерживают кириллические домены. Если у вас домен кириллицей в зоне РФ, то вам следует приобрести сертификат с поддержкой IDN.

Подробнее про виды сертификатов и их стоимости вы можете почитать в интернете. Здесь же я привел лишь некоторые, чтобы вы имели понятие, что сертификаты SSL бывают разные.

Получение сертификата

Сегодня приобрести сертификат SSL для сайта можно абсолютно бесплатно. Уже давно Google заявил о том, что пора уже переходить всем на безопасный прокол https и что предпочтение в ранжировании будет отдаваться сайтам именно с защищенным соединением. Кстати, это еще одна причина по которой я перешел на https. В общем, в связи с этим всем в свет появился проект под названием Let’s Encrypt . В первую очередь данный проект рассчитан на доступность приобретения SSL сертификата, а также облегчить жизнь рядовым веб-разработчикам с установкой сертификатов (генерация приватных ключей и прочее). И что самое главное — сертификаты, выдаваемые Let’s Encrypt, абсолютно бесплатные . Лично на моем блоге стоит именно такой сертификат.

Я получил сертификат SSL от Let’s Encrypt в панели управления beget.ru. Если вы пользуетесь данным хостингом, то получить его будет проще простого. Заходите в панель управления Бегет, далее переходите в раздел «Домены » и в списке доменов щелкаете по иконке SSL.

Иконка рядом с доменом говорит о том, что сертификат уже установлен. Попав в раздел SSL, открываем вкладку «Бесплатный SSL сертификат «. Если у вас имеются поддомены на выбранном домене, то лучше сразу выберите и их тоже, т.к. если этого не сделать сразу, то в дальнейшем придется перевыпускать сертификат.

Настройка сайта Загружаемые ресурсы

Для перевода сайта на HTTPS необходимо выполнить некоторые настройки на сайте, касается это загружаемых ресурсов. Что подразумевается под ресурсами, это — скрипты, стили, картинки, аудио, видео, т.е. все те ресурсы, которые загружаются браузером с вашего сайта через протокол http. Существуют относительные и абсолютные адреса. Чем они отличаются?

Относительный адрес:

/image.jpg

Относительный адрес вне зависимости от протокола:

//sitename.ru/image.jpg

Абсолютный адрес:

http://sitename.ru/image.jpg

В абсолютном адресе указывается доменное имя сайта с протоколом. Так вот, при переходе на https необходимо применять относительные адреса вне зависимости от протокола, т.е. отсекая сам протокол. При таком подходе ресурсы будут загружаться по такому же протоколу, что и ваш и не важно на http он или на https. Единственное условие — если вы загружаете ресурсы с внешних сайтов (например, с CDN), то данные сайты должны быть доступны по https, иначе от них придется отказаться.

Также, как вариант вы можете просто указать все абсолютные ссылки с протоколом https (так например сделано в WordPress).

Тег

Обратите внимание, если вы на сайте используете тег с адресом сайта, то обязательно проследите, чтобы адрес был указан с протоколом https.. Данный тег не является обязательным, но все же, если в вашей cms он используется, то потрудитесь его исправить в случае чего. Находится он в самом начале секции . Если получится так, что вы все ссылки изменили на относительные вне зависимости от протокола (//sitename.ru), а в теге содержится адрес с http, то все ваши относительные ссылки будут считаться относительными в зависимости от протокола http. В результате в консоле браузера вы получите кучу ошибок, а на сайте поплывет дизайн.

Тег rel=»canonical»

Если у вас на сайте используется тег rel=»canonical», то проследите за тем, чтобы канонический адрес страницы в данном теге был абсолютным с указанием протокола https. Иначе, если будет http он будет работать только во вред.

301 редирект с http на https

Чтобы не потерять трафик нам необходимо сделать так, что когда пользователь заходит на сайт по протоколу http его бы автоматически перекидывало на https. Склейка зеркал и переиндексация сайта в поисковиках дело долгое (Гугл правда быстро реагирует, вот с Яндексом придется ждать), поэтому 301 редирект может это дело ускорить и не дать потерять трафик. Для этого в файл.htaccess нужно добавить всего две строчки:

RewriteCond %{SERVER_PORT} !^443$ RewriteRule ^(.*)$ https://sitename.ru/$1

Этих двух строк должно хватить. Если же у вас будут проблемы с редиректом, то можете попробовать альтернативный код.

RewriteEngine On # Если этой строки нет выше RewriteCond %{HTTP:X-Forwarded-Protocol} !=https RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI}

А вот еще один код редиректа. Бывало такое у меня, что выше два кода не работали. Помог только этот.

RewriteEngine On RewriteCond %{HTTPS} off RewriteCond %{HTTP:X-Forwarded-Proto} !https RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI}

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

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

## редирект с без www на www: RewriteCond %{HTTP_HOST} ^sitename.ru$ RewriteRule ^(.*)$ https://www.sitename/$1 ## редирект c www на без www: RewriteCond %{HTTP_HOST} ^www.sitename.ru$ RewriteRule ^(.*)$ https://sitename.ru/$1

Файл robots.txt

В robots.txt нам обязательно следует указать главное зеркало с протоколом https. Также указать ссылку на карту сайта так с протоколом https. Вот как я сделал на своем блоге:

Host: https://сайт Sitemap: https://сайт/sitemap.xml

Переезд сайта в панели вебмастеров Яндекс и Гугл

После вышеперечисленных действий нам необходимо сообщить поисковикам, что сайт переехал на новый протокол https. Как известно адрес с http и с https это абсолютно два разных адреса в глазах поисковиков.

Яндекс вебмастер

Для переезда сайта в Яндекс заходим в панель Яндекс Вебмастер по адресу https://webmaster.yandex.ru . Выбираем свой сайт и в разделе «Настройка индексирования » вводим свой домен и отмечаем чек-бокс «Добавить HTTPS «, сохраняем.

Центр вебмастеров Гугл

Http://сайт https://сайт http://www..сайт

Далее выбираем основное зеркало с https естественно, только с www или без www. Для своего сайта я выбрал без www — https://сайт . Открываем сайт и в настройках сайта (кликаем по шестеренке справа) указываем основной домен. Вот на примере моего блога.

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

Также хотелось бы сказать, что процесс переиндексации в Гугл занимает не так много времени, примерно 2 недели хватит, а может и меньше. Вот в Яндекс по сложнее с этим, я и не удивлен. Яндекс всегда был тугой в этом плане. В первое время у вас обнулится ТИЦ, если он у вас был и в первый же апдейт ТИЦа должен будет вернуться. Это я написал, чтобы вы не пугались. Ну а далее в Яндекс Вебмастер вы обнаружите следующую картину…

Прошло довольно приличное время после перехода на https и как видите по скрину еще не все страницы перешли на https. Что сказать, так устроен отечественный поисковик.

Парус слов про Яндекс Метрику. Если у вас был установлен код яндекс метирки, то в панели метирики вам придется добавить сайт заново с протоколом https.

Переход на HTTPS в Joomla

Обновлено - 15.12.2016

В последних версиях Joomla с переходом на https не должно возникнуть проблем. В файл.htaccess не обязательно добавлять директивы редиректов, движок сам перекинет с http на https. Для этого необходимо просто включить опцию в общих настройках Joomla — «Сервер » -> «Включить SSL » -> «Весь сайт» .

Важно! Включайте данную опцию именно тогда, когда вы уверены, что сертификат у вас уже установлен и сайт доступен по протоколу Https.

Ошибка при переходе на Https в Joomla

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

Помимо тех настроек сайта, что были указаны выше нам необходимо открыть файл configuration.php и в поле live_site вписать абсолютный адрес с проколом https.

Public $live_site = "https://sitename.ru";

По идее после этой настройки в теге адрес сайта должен быть указан с протоколом https. Но нет, он был указан с протоколом http, от того и пошли все ошибки. Поискал решение проблемы в интернете, конкретно на форуме joomlaforum.ru и нашел решение. Необходимо было сделать некоторый хак ядра, правда уверяли, что после обновления данные изменения не затрутся. Открываем файл — /libraries/joomla/document/renderer/html/head.php и заменяем (77 строка)

$buffer .= $tab . "" . $lnEnd;

Скажу сразу — после обновления движка изменения все же затираются и вам придется после каждого обновления вносить правки в вышеуказанный файл.

Пока я эту проблему так и не решил. Не понимаю почему так происходит — версия движка последняя.

После этих действий все пришло в норму. Также в общих настройках Joomla, включил SSL. Ее включение привело к неработоспособности сайта. Если вдруг вы выбрали опцию «Весь сайт » и сайт перестал работать, то вам необходимо открыть файл configuration.php по Ftp, найти $force_ssl и установить значение на 0.

Public $force_ssl = "0";

После этого сайт заработает.

Переход на HTTPS в WordPress

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

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

На этом и завершу. Всем спасибо за внимание. Не стесняемся, задаем вопросы в комментариях.

From:
Registered: 2014.07.07
Posts: 3,648
I just like PunBB:
5 years, 3 months, 5 days,
Likes: 425

Topic: Меры принятые вручную

Что делать, если на почту пришло письмо:
Маскировка и/или скрытая переадресация

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

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

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

Когда сайт будет приведен в соответствие с рекомендациями Google для веб-мастеров, отправьте запрос на его повторную проверку. Если Ваш сайт будет соответствовать нашим рекомендациям, принятые вручную меры будут отменены.

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

2 Reply by PunBB

From: Moscow, Sovkhoznay 3, apt. 98
Registered: 2014.07.07
Posts: 3,648
I just like PunBB:
5 years, 3 months, 5 days,
Likes: 425

Re: Меры принятые вручную

Под маскировкой подразумевается предоставление неодинакового контента или разных URL пользователям и поисковым системам. Использование маскировки является нарушением рекомендаций Google для веб-мастеров, поскольку пользователям предоставляются не те результаты, которые ожидались.

Ниже приведены некоторые примеры маскировки.

Предоставление поисковым системам страницы с HTML-текстом, а пользователям – страницы с картинками или Flash
Добавление на страницу текста или ключевых слов только в ответ на запрос этой страницы агентом пользователя, связанным с поисковой системой
Если на вашем сайте имеется содержание, при доступе к которому у поисковых систем могут возникнуть проблемы (JavaScript, изображения, Flash и т. п.), ознакомьтесь с нашими рекомендациями о том, как обеспечить возможность доступа поисковых систем к этому содержанию без использования маскировки.

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

3 Reply by PunBB

From: Moscow, Sovkhoznay 3, apt. 98
Registered: 2014.07.07
Posts: 3,648
I just like PunBB:
5 years, 3 months, 5 days,
Likes: 425

Re: Меры принятые вручную

Скрытая переадресация

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

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

Ниже приведены некоторые примеры скрытой переадресации:

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

4 Reply by PunBB

From: Moscow, Sovkhoznay 3, apt. 98
Registered: 2014.07.07
Posts: 3,648
I just like PunBB:
5 years, 3 months, 5 days,
Likes: 425

Re: Меры принятые вручную

Запросы на повторную проверку

Что такое запрос на повторную проверку?

Эта процедура выполняется, если вы устранили все выявленные нарушения правил на своем сайте и хотите сообщить об этом в Google. Подробности вы найдете здесь.

Как отправить запрос на повторную проверку
Выполните следующие действия:

Войдите в свой аккаунт Search Console.
Проверьте все версии своего сайта.
В разделе "Меры, принятые вручную" прочитайте, какие действия предприняли специалисты Google в отношении вашего сайта.
Устраните все выявленные проблемы.
Перейдите в раздел "Проблемы безопасности" и узнайте, все ли в порядке с вашим сайтом.
Нажмите "Запросить проверку".

5 Reply by PunBB

From: Moscow, Sovkhoznay 3, apt. 98
Registered: 2014.07.07
Posts: 3,648
I just like PunBB:
5 years, 3 months, 5 days,
Likes: 425

Re: Меры принятые вручную

Как происходит повторная проверка

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

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

Отправьте нам запрос на повторную проверку из своего аккаунта Search Console.
Вам придет подтверждение от Google. Обратите внимание, что обработка запроса может занять несколько дней.
Google одобрит или отклонит ваш запрос.
Если проверка пройдет успешно, мы отменим меры, принятые вручную в отношении вашего сайта.

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

6 Reply by PunBB

From: Moscow, Sovkhoznay 3, apt. 98
Registered: 2014.07.07
Posts: 3,648
I just like PunBB:
5 years, 3 months, 5 days,
Likes: 425

Re: Меры принятые вручную

Как оформить запрос на повторную проверку

Запросы обрабатываются вручную специалистами Google. Чтобы нам было проще понять, какие меры вы приняли, расскажите о них как можно более подробно.

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

Вы также можете предоставить нам материалы, в которых описываются ваши действия по устранению проблем на сайте. О том, как собрать и отправить такую информацию, читайте ниже.

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

Likes: 425

Re: Меры принятые вручную

Типичные ошибки при отправке запроса на повторную проверку

Ниже перечислены наиболее распространенные ошибки, допускаемые веб-мастерами при отправке сайта на повторную проверку. Рекомендуем внимательно изучить этот раздел.

1. Отклонение всех обратных ссылок

Часто инструмент отклонения обратных ссылок используется неправильно. Необходимо помнить о следующем:

Обратные ссылки рекомендуется по возможности удалять. Добавление всех обратных ссылок в файл отклонения не считается решением проблемы, и вам не удастся пройти проверку.
Если в домене несколько таких ссылок, используйте строку вида domain:example.com.
Убедитесь, что не заблокировали обычные ссылки.

2. При удалении взломанного контента не использовалась функция "Просмотреть как Googlebot"

Часто нежелательный контент добавляется на взломанные сайты с помощью маскировки. Это означает, что пользователи и поисковый робот видят на веб-странице разные материалы.

Одним из способов выявления маскировки является функция Просмотреть как Googlebot в Search Console. Она позволяет узнать, как поисковый робот воспринимает ваш сайт. Часто нам приходится отклонять запросы на повторную проверку из-за того, что проблема не была устранена и при сканировании страницы обнаруживается внедренный контент. Узнайте больше о маскировке и скрытой переадресации.

3. Отправка запроса на повторную проверку пустого сайта

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

Пустые сайты , на которых много веб-страниц, но мало или вообще нет контента.
Припаркованные домены – страницы-заполнители для доменов без контента.
Сайты, недоступные в связи с ошибкой "Не найдено" (404) или сбоями сервера. Подробнее об ошибках сканирования...
Перед повторной проверкой убедитесь, что ваш сайт соответствует требованиям Google. Если запрос отклонен, внимательно изучите наше сообщение и устраните все возможные проблемы, прежде чем обращаться к нам снова.