adel92: Возьмите инструкцию Яндекса, замените htaccess -> web.config и выполните все действия.
Про какую конкретно инструкцию Яндекса идёт речь? Можно ссылку?
И насчёт общей схемы редиректа. Нам не уйти от Global.asax, так как в нём прописана достаточно витиеватая схема редиректа для старых ресурсов (это алгоритм на VB.NET, который разбирает исходный запрос и преобразует его в новый соответствующий ресурс). Если мы оставим этот алгоритм и сделаем его работающим только для HTTP, то можем ли мы сделать безусловный редирект на HTTPS средставми web.config? Я имею в виду следующее: Global.asax возможно будет перенаправлять исходный запрос на новый ресурс, а web.config этот редирект перенаправит ещё и на HTTPS. Будет ли работать такая 2-х шаговая схема?
Мемори: конечно все это уже мертво, а авто ссылки в 1 сек загоняют сайт под фильтры и в гугле и яндксе.
Тут это называется прогоном по говно-каталогам...
Вот это я и хотел выяснить. Т.е. любые каталоги (например, https://www.softpile.com/), использующие ПАДы, теперь 100%-но считаются ГС?
Дело в том, что как-то вопрос с PAD-файлами упустили из виду, а они всё продолжают себе тихо-мирно лежать в неприметной поддиректории на сайте и снабжать ботов из говно-каталогов ссылками на наш сайт (правда, многие из ссылок уже не актуальны).
Я так понимаю, что теперь лучше вообще ПАДы убрать с вебсайта? А что делать с ГК, на которых раньше "засветился"? Или если это было давно, то теперь это не в счёт на Гугле/Яндексе?
Блин, какая-то хрень... Sitemap у меня реализован в одном файле. Вчера специально руками проверил все URL из этого файла. Нашёл только одну неработающую ссылку, исправил её. Также дописал в sitemap.xml несколько новых страниц. Засабмиттил заново в Google WMT. Сегодня открываю и вижу такую картину:
84 Submitted
79 Indexed
В robots.txt ни одна из страниц не блокируется. Инструмент проверки Гугла также это подтверждает.
---------- Добавлено 26.02.2016 в 12:59 ----------
AlekseiD: Лучше всего загружать несколько sitemap под определенные группы страниц и по ним уже определять в какой группе есть проблемы.
Типа что-то метода половинного деления :) ? Разумно. Однако по времени может растянуться надолго, т.к. Гугл обрабатывает каждый sitemap не очень быстро.
---------- Добавлено 26.02.2016 в 14:07 ----------
AlekseiD: Узнать никак не возможно. Можно, конечно, дрючится с site:, но как недавно узнал, эта команда не дает правильного видения индексации гугл.
А я подрючился - уже нашёл одну страницу, которую Гугл не включает в свой индекс. Вроде такая очень даже приличная страница - непонятно, почему её гугл в свой индекс не взял... А что теперь дальше делать? К какому дяде пойти и пожаловаться, чтобы он рассказал в чём причина и включил страницу в индекс?
Про галочку не понял. Я недавно общался с саппортом Метрики. Они сказали, что проблему вообще решить нельзя.
Сейчас ещё раз настройки счётчика перепроверил - вроде нет такой опции.
Насчёт возможностей ГА, которых нет в Метрике: для проекта, о котором идёт разговор, данных Метрики хватает с головой. Единственное, чего не достаёт - возможности отследить ситуацию по каждому запросу с Гугла в деталях. Сами запросы Гугла можно и в WMT увидеть, но привязать бы их к Веб-визору Метрики или получить нечто подобное в ГА - вот это было бы здорово...
Если не секрет, в каких частях страницы ставите скрипты?
Я на всякий случай ставлю код Метрики почти в самом конце страницы, между </footer> и </body> - чтобы Гугл не снимал баллы за то, что основной контент с задержкой из-за скрипта Метрики может грузиться.
---------- Добавлено 22.02.2016 в 15:37 ----------
Mish-ka: Ну, ГА решает довольно таки много вопросов.
Тогда вопрос такой: что он делает такого, что не делает Метрика?
Mish-ka: И да, запросы в Гугле вы даже в Аналитиксе не увидите.
Не понял. Там что, теперь нельзя увидеть поисковые запросы и по каждому из них отследить скажем путь по сайту??!
Mish-ka: И ухудшение ранжирования в Гугле за Аналитикс - это сильно )))
Подоплёка в том, что каждый скрипт аналитики начинает пулять на свои сервера детальную информацию про визит. Например, в Метрике мы можем отследить все движения мышью пользователя. Это же не бесплатно - мы платим трафиком и, возможно, ухудшением скорости работы страницы. Теоретически за это Гугл может и какие-то баллы снять, которые приведут к понижению позиций в СЕРПе. Например, мне Google PageSpeed Insights до сих пор снимает баллы только за скрипт Метрики:
Leverage browser caching for the following cacheable resources:
Возьмите инструкцию Яндекса, замените htaccess -> web.config и выполните все действия.
Про какую конкретно инструкцию Яндекса идёт речь? Можно ссылку?
И насчёт общей схемы редиректа. Нам не уйти от Global.asax, так как в нём прописана достаточно витиеватая схема редиректа для старых ресурсов (это алгоритм на VB.NET, который разбирает исходный запрос и преобразует его в новый соответствующий ресурс). Если мы оставим этот алгоритм и сделаем его работающим только для HTTP, то можем ли мы сделать безусловный редирект на HTTPS средставми web.config? Я имею в виду следующее: Global.asax возможно будет перенаправлять исходный запрос на новый ресурс, а web.config этот редирект перенаправит ещё и на HTTPS. Будет ли работать такая 2-х шаговая схема?
в гугле есть инструмент чистки нежелательных ссылок disawow кажется так...
Да, нашёл для Гугла - это Disavow Links:
https://www.google.com/webmasters/tools/disavow-links-main
конечно все это уже мертво, а авто ссылки в 1 сек загоняют сайт под фильтры и в гугле и яндксе.
Тут это называется прогоном по говно-каталогам...
Вот это я и хотел выяснить. Т.е. любые каталоги (например, https://www.softpile.com/), использующие ПАДы, теперь 100%-но считаются ГС?
Дело в том, что как-то вопрос с PAD-файлами упустили из виду, а они всё продолжают себе тихо-мирно лежать в неприметной поддиректории на сайте и снабжать ботов из говно-каталогов ссылками на наш сайт (правда, многие из ссылок уже не актуальны).
Я так понимаю, что теперь лучше вообще ПАДы убрать с вебсайта? А что делать с ГК, на которых раньше "засветился"? Или если это было давно, то теперь это не в счёт на Гугле/Яндексе?
Гугл в помощь :)
http://appvisor.com/pad/
Блин, какая-то хрень... Sitemap у меня реализован в одном файле. Вчера специально руками проверил все URL из этого файла. Нашёл только одну неработающую ссылку, исправил её. Также дописал в sitemap.xml несколько новых страниц. Засабмиттил заново в Google WMT. Сегодня открываю и вижу такую картину:
84 Submitted
79 Indexed
В robots.txt ни одна из страниц не блокируется. Инструмент проверки Гугла также это подтверждает.
---------- Добавлено 26.02.2016 в 12:59 ----------
Лучше всего загружать несколько sitemap под определенные группы страниц и по ним уже определять в какой группе есть проблемы.
Типа что-то метода половинного деления :) ? Разумно. Однако по времени может растянуться надолго, т.к. Гугл обрабатывает каждый sitemap не очень быстро.
---------- Добавлено 26.02.2016 в 14:07 ----------
Узнать никак не возможно. Можно, конечно, дрючится с site:, но как недавно узнал, эта команда не дает правильного видения индексации гугл.
А я подрючился - уже нашёл одну страницу, которую Гугл не включает в свой индекс. Вроде такая очень даже приличная страница - непонятно, почему её гугл в свой индекс не взял... А что теперь дальше делать? К какому дяде пойти и пожаловаться, чтобы он рассказал в чём причина и включил страницу в индекс?
Идея прикольная. У Вас эта система уже реализована и проверена в боях, или это так - чисто на уровне идеи?
Она родимая. Но отключать её не хочется - вдруг страницы перестанут быстро грузиться и Гугл снимет баллы за это. Или я напрасно волнуюсь?
Про галочку не понял. Я недавно общался с саппортом Метрики. Они сказали, что проблему вообще решить нельзя.
Сейчас ещё раз настройки счётчика перепроверил - вроде нет такой опции.
Насчёт возможностей ГА, которых нет в Метрике: для проекта, о котором идёт разговор, данных Метрики хватает с головой. Единственное, чего не достаёт - возможности отследить ситуацию по каждому запросу с Гугла в деталях. Сами запросы Гугла можно и в WMT увидеть, но привязать бы их к Веб-визору Метрики или получить нечто подобное в ГА - вот это было бы здорово...
Всегда ставлю оба.
Если не секрет, в каких частях страницы ставите скрипты?
Я на всякий случай ставлю код Метрики почти в самом конце страницы, между </footer> и </body> - чтобы Гугл не снимал баллы за то, что основной контент с задержкой из-за скрипта Метрики может грузиться.
---------- Добавлено 22.02.2016 в 15:37 ----------
Ну, ГА решает довольно таки много вопросов.
Тогда вопрос такой: что он делает такого, что не делает Метрика?
И да, запросы в Гугле вы даже в Аналитиксе не увидите.
Не понял. Там что, теперь нельзя увидеть поисковые запросы и по каждому из них отследить скажем путь по сайту??!
И ухудшение ранжирования в Гугле за Аналитикс - это сильно )))
Подоплёка в том, что каждый скрипт аналитики начинает пулять на свои сервера детальную информацию про визит. Например, в Метрике мы можем отследить все движения мышью пользователя. Это же не бесплатно - мы платим трафиком и, возможно, ухудшением скорости работы страницы. Теоретически за это Гугл может и какие-то баллы снять, которые приведут к понижению позиций в СЕРПе. Например, мне Google PageSpeed Insights до сих пор снимает баллы только за скрипт Метрики:
Leverage browser caching for the following cacheable resources:
https://mc.yandex.ru/metrika/watch.js (60 minutes)