Проверить

Влияет ли структура сайта на его позицию в выдаче?

Независимый эксперт по поисковому продвижению

Вы когда-нибудь задумывались, почему сайт находится на 40-х позициях, хотя дает ответ на поисковый запрос не хуже, чем страницы сайта в ТОП 10?

Почему в выдаче поисковой системы у большинства сайтов из первой десятки есть навигационные цепочки, написанные русскими буквами? А сайты, находящиеся в ТОП 40 и ниже, их не имеют?

Возможно, существует определенная группа факторов, которая играет важную роль при ранжировании? Группа факторов, на которую большинство SEO-специалистов не обращают внимания и считают ее влияние на место сайта в ТОПе всего лишь мифом?

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

Из истории мифа

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

• сайт был моложе других в среднем на 3 — 5 лет;
• не имел ссылочной массы в принципе;
• содержал множество технических недочетов и ошибок, таких как большое количество дублей, «битых» ссылок, некорректно работающих скриптов;
• на страницах товаров и категорий отсутствовали не только релевантные запросам тексты, но даже заголовки и теги Title;
• основная посещаемость на сайте была из контекстной рекламы (в среднем 500 посетителей в сутки), а из органической выдачи — менее 150 посетителей.

Однако при всех своих недостатках ресурс довольно неплохо ранжировался по конкурентным запросам. 60 из 100 продвигаемых запросов находились в ТОП 30, а 15 СЧ и НЧ запросов — в ТОП 10. Это было довольно странно, так как подобные явления ранее не встречались в моей практике.

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

После реализации технических доработок, исправления некоторых ошибок (настройка индексации в robots.txt, удаление дублей страниц, настройка корректной работы фильтров, создание и размещение карты сайта и т.п.), оптимизации страниц категорий и товаров, размещения текстов сайт стал значительно лучше ранжироваться. По большинству запросов, в т.ч. по некоторым ВЧ, он попал в ТОП 10.

Также на размышления о том, что наличие грамотной структуры ресурса может повлиять на его ранжирование в поиске, навели появившиеся рекомендации Яндекса: «Разделы сайта должны иметь однозначные названия, чтобы посетитель не тратил время на поиски нужной ему информации. Старайтесь писать понятным пользователю языком — не используйте профессиональные термины».

Мнение экспертов

Как уже было сказано, структуру сайта все воспринимают по-своему.

Например, Елена Камская в своем блоге optimizatorsha.ru в материале, посвященном разработке интернет-магазина, пишет следующее:

Магазин — это не просто визитка компании, а канал продаж (во многих случаях — единственный), а поисковые системы — один из самых выгодных источников потенциальных покупателей, поэтому от структуры сайта, генерации URL, внутренней навигации и структуры разных типов страниц может зависеть очень многое.

Антон Виноградник, PR-менеджер компании ALTWeb Group, в материале «Оптимизация структуры сайта» высказывает такое мнение:

Грамотная структура сайта не только оставляет у посетителей приятное впечатление о нём, но и благоприятно влияет на ранжирование поисковыми системами.

Дмитрий Силаев, независимый эксперт по поисковому продвижению:

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

Анастасия Бадина, ведущий специалист по поисковому продвижению холдинга Ingate:

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

Сами поисковики также дают рекомендации по данному вопросу:

Яндекс: «Структура сайта должна быть организована таким образом, чтобы внутри более общих разделов размещались более конкретные».

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

Гипотеза о влиянии структуры сайта на его место в ТОПе

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

Но как поисковые системы могут определить, является ли иерархия разделов того или иного сайта верной, какие должны быть разделы и подразделы? Поисковики имеют списки поисковых запросов, вводимых пользователями, которые позволяют построить определенную эталонную модель той или иной тематики. Например, эти запросы можно посмотреть в wordstat.yandex.ru: введя какой-нибудь ВЧ запрос, вам будет доступен список всех запросов, которые его содержат. Именно запросы из этого списка являются подразделами основного запроса. А НЧ запросы, не имеющие своих подразделов, — конечные элементы структуры.

Например: категория «метизы», подкатегории «саморезы», «шурупы», «болты», «винты» и т.п. Для каждой подкатегории — свои товары. Чтобы по запросу «метизы» сайт был в ТОПе, нужно, чтобы на нем были все виды метизов (хотя бы большинство), которые ищут пользователи в интернете.

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

Проверка гипотезы

Цель эксперимента: выявить влияние четкой иерархической структуры сайта на его положение в ТОПе по конкурентным запросам.

Условия эксперимента: возьмем все сайты, находящиеся в ТОП 5, и шесть ресурсов из ТОП 50 по запросу «мебельная фурнитура».

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

(Картинка кликабельна)

Как видно, у 4-х из 5-ти сайтов в ТОП 5 есть четкая структура разделов, подразделов и конечных страниц с товарами. Только у двух сайтов, взятых из ТОП 50, есть подобная структура. Остальные четыре или имеют большое количество разделов, или большое количество товаров. Ни у одного из них нет промежуточных подразделов.

Таким образом, только два сайта из ТОП 50 имеют структуру категорий, подкатегорий и количество страниц товаров, сопоставимую с сайтами из ТОП 5. Но по другим факторам: возраст домена, количество внешних ссылок, наличие в Яндекс.Каталоге, тИЦ и PR — они уступают. Хотя тИЦ и PR лишь косвенно говорят об авторитетности сайтов для поисковых систем, но если это учитывать, то в ТОП 5 большинство ресурсов (4 из 5) имеют высокие подобные показатели. Все анализируемые параметры сайтов легко проверить с помощью анализа сайта в сервисе Rookee.

Несмотря на то, что среди остальных сайтов в ТОП 50 есть и старые (5 и более лет), и имеющие достаточное количество ссылок и вложенную структуру URL, по основным показателям структуры каталога товаров они все же не соответствуют сайтам из ТОП 5.

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

Рекомендации

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

1. Создать вложенные URL страниц, содержащие в себе полный путь с главной страницы, URL страниц категорий и подкатегорий.
2. Настроить отображение меню «хлебных крошек» в соответствии с иерархией разделов и вложенностью URL страниц.
3. В основном меню сайта структурировать расположение разделов и подразделов.
4. Давать краткие названия разделам, вложенным подразделам, товарам и услугам. При этом заголовок h2 страницы должен соответствовать анкору ссылки на эту страницу из основного меню сайта. Из основного меню должна быть только одна ссылка на страницу. Если необходимо несколько ссылок, то нужно сделать у них одинаковые анкоры. Title страницы должен содержать заголовка h2.

После проведенного исследования я вывел основные правила создания структуры сайта, которыми хотел бы поделиться с вами:

1. Разделы и подразделы должны иметь короткие простые названия в соответствии с общепринятыми фразами, используемыми большинством людей.
2. Разделы должны содержать по возможности все подразделы, которые могут быть.
3. Обращайтесь к статистике ключевых слов. Выгрузив все запросы, которые вводят пользователи по той или иной тематике, можно построить почти идеальную с точки зрения алгоритмов структуру сайта. Если это сделать, то ваш ресурс будет давать ответы почти на все неуникальные (вводятся более 1 раза) запросы.

Таким образом, вы получите на сайте четкую структуру разделов с внутренней иерархией, отвечающую на все запросы пользователей!

По материалам Прожектор Rookee

анализ сайтов конкурентов и поисковой выдачи по запросу в Яндексе и Google для продвижения сайта — Пиксель Тулс

Сегодня мы поговорим об очень интересной теме — анализ ТОП выдачи и поднимем ряд холиварных вопросов. Многие думают, что анализ ТОП выдачи не работает, поэтому мы подробно остановимся на тех ситуациях, когда он не работает и почему так происходит? Рассмотрим два уровня — анализ конкурентов на уровне проектов и на уровне поискового запроса, расскажем, для чего это нужно и какие инструменты автоматизации используются, подходы и так далее. Будем говорить о том, как выбирать сайты, какие конкуренты бывают, чем они отличаются друг от друга и какие ключевые факторы нужно учитывать.

Содержание

1. Важность систематизации в SEO

2. Когда анализ ТОП не работает

3. Когда нужно анализировать ТОП

4. Почему это часто не работает

5. 7 задач, которые нужно научиться решать

6. Анализ ТОП делится на два масштаба

7. От чего зависит формула

8. Как выбрать конкурентов

9. Какие факторы анализируются на уровне сайта

10. Факторы, учитывающиеся на уровне запроса

11. Оценка полноты сервисов

12. Вопросы для сертификации

13. Вспомогательные материалы

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

Сегодняшняя тема затрагивает верхушку пирамиды Маслоу в SEO — когда мы переходим к внутренней оптимизации, пост-аналитике и генерации гипотез. То есть анализ конкурентов поможет нам с заполнением этих уровней поисковой оптимизации. Анализ конкурентов в SEO — один из самых мощных подходов, так как поисковые системы обучают формулу, опираясь на оценки асессоров и параметры документов из той же выдачи. Грубо говоря, они максимизируют некоторую метрику, опираясь на значение тех документов, которые находятся в выдаче. Если мы пытаемся скопировать паттерны, по которым обучаются поисковые системы, то улучшаем и свои позиции.

Есть кейсы, когда анализ не дает стопроцентного результата. Разберемся, почему некоторые SEO специалисты думают, что анализ ТОП выдачи не работает:

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

Есть несколько типовых задач, в решении которых помогает анализ ТОП в тематике и у прямых конкурентов.

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

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

Третья типовая задача — обнаружение точек роста трафика и способов масштабирования работ. То есть вы что-то сделали, но понимаете, что это не предел того, что можно получить из сайта и органической выдачи. Канал поискового продвижения — номер один по объемам привлечения трафика и продаж для e-commerce, сайтов услуг. В Пиксель Тулс есть исследования, подтверждающие это на большой выборке. Если для вас это не канал номер один, то вполне возможно еще есть куда копать.

Разберем на конкретном примере запроса «мебель для дома» — мы хотим продвигать какой-то раздел в рамках каталога. То есть у нас есть большой сайт, целиком посвященный мебели, и один из подразделов в его структуре — мебель для дома. Мы забираем «мебель для дома», анализируем конкурентов выдачи.

Оказывается, что большинство конкурентов не подходят для анализа. Основываясь на их данных, нельзя сделать выводы. В данном случае не совпадают типы страницы (11 главных страниц нам не подходят, так как мы продвигаем внутреннюю страницу каталога), в выборке есть два федеральных агрегатора — например, IKEA (игрок мирового масштаба), который по факторам близости максимально далек от нас. Таким образом, из ТОП-20 только 4-5 проектов имеют релевантную страницу, близкую к нашей. Не корень каталога, а именно тот тип, который мы хотим анализировать.

Разберем еще один пример «сложной ситуации». К слову, выдача поисковых систем в нынешних реалиях, почти по всем запросам «сложная», поскольку состоит из разных наборов разных типов проектов, типов результатов и т.д. Это происходит из-за того, что практически любой поисковый запрос не является до конца сформулированным им. Пользователь не выражает в одном запросе всю полноту того, что хочет. Например, запрос «продвижение сайта» — непонятно, что конкретно ищет пользователь: узнать, что такое продвижение сайта, хочет научиться продвигать сам или заказать продвижение.

Этот спектр потребностей пытается удовлетворить любая поисковая система, что нужно уметь анализировать. Многие противники анализа ТОП, назовем его «анализом ТОП в лоб», жалуются на то, что не знают, что анализировать. Они берут страницу из Википедии, усредняют со страницей про продвижение сайта https://vc.ru, главной страницей какого-нибудь проекта, не понимая, какие выводы можно сделать. Именно так делать и не нужно, при таком подходе анализ не работает.

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

1. Формирование ТЗ на копирайтинг. Вы должны понимать, нужен ли текст, каким должен быть его объем, определить количество вхождений, LSI, структуру;

2. Чистка запросов: удаление нецелевых фраз, оценка состава выдачи, показателей геозависимости и коммерциализации, удаление из выборки запросов, выдача которых состоит из проектов, которые не совпадают с вами;

3. Кластеризация запросов по ТОПу — классическая история, которая позволяет ускорить процесс формирования структуры, соединение поисковых запросов в рамках одного url-адреса;

4. Определение типа нужного URL: главная/листинг/карточка, когда вы не знаете, что хотите продвинуть, поисковые запросы пытаются проанализировать выдачу;

5. Внутренняя оптимизация: какой нужен Title, коммерческие факторы, ассортимент, количество релевантных ответов на сайте и т.д.;

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

7. «После шторма»: поиск выросших и просевших проектов.

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

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

На слайде не зря изображены два схожих физических прибора — телескоп и микроскоп. С помощью первого рассматривают звездное небо, второй используется для того, чтобы изучать микрообъекты. В рамках SEO макрообъектом является анализ ТОПа на уровне сайта, а микрообъектом — на уровне запроса. Это абсолютно разные задачи и подход к ним должен быть тоже разным. Здесь хочется напомнить важный тезис:

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

Ознакомиться со всеми алгоритмами Яндекса по годам. Если мы будем смотреть выдачу по одному и тому же поисковому запросу, то увидим абсолютно противоположные корреляции у проектов разного типа:

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

Когда есть формула ранжирования, она плюс-минус близка и в ней есть общие закономерности только в рамках одного региона, одной и той же потребности пользователей одного и того же типа URL-адреса. Например, банки по запросу «займы» ранжируются по одной формуле, агрегаторы финансовых офферов — по другой, и там другие корреляции.

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

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

Первый шаг, который вам нужно сделать — взять список наиболее частотных поисковых запросов на уровне сайта (желательно не меньше нескольких десятков) и посмотреть, какие домены встречаются чаще всего. Таким образом мы определяем наиболее приоритетных конкурентов выдачи. Это можно сделать с помощью инструмента анализа конкурентов от «Пиксель Тулс».

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

Почему так важен возраст

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

Сейчас график старения выдачи немного замедлился — «старение» выдачи происходит на полгода за год. Это положительная тенденция, так как механизм консервации выдачи стал менее значимым.

Модуль проектов: конкуренты

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

Вы можете определить, какие конкуренты являются вашими в выдаче конкретно сейчас, какие выросли, а какие упали. В дальнейшем это поможет понять, какие из этих проектов сделали успешные шаги, а какие — что-то неправильное. Мы рекомендуем использовать модуль проектов «Пиксель Тулс», вкладка «Конкуренты».

Разметка конкурентов — первостепенная задача

Первое, что нужно сделать после определения списка конкурентов — разметить их по типу соответствия. В маркетинге различают три типа конкурентов:

• косвенный — конкурирующий с вами по каналу или за целевую аудиторию, но при этом не решает ее потребности тем способом, которым это делаете вы;

• прямой — конкурент, непосредственно удовлетворяющий потребности ЦА тем же способом, как и вы;

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

Пример такой разметки:

Что такое близость проектов

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

Мы берем четыре основных фактора, на которые обращают внимание в первую очередь:

1. Показатель ИКС в Яндексе — его можно использовать не только в Яндексе, но и для Google. Авторитетное значение ИКС отражает реальные показатели сайта, в частности посещаемость. Если вы продвигаете сайт Mebelvkusa.ru в ИКСом = 60, то брать в анализ сайт www.ikea.com с ИКСом = 20900 нет никакого смысла.

2. Количество страниц в индексе — это может быть количество страниц в индексе Яндекса или Google.

3. Число уникальных доноров на сайте — на слайде мы видим, что IKEA имеет запредельное значение.

4. Возраст главной страницы в показателе Яндекса.

Вы заполняете все данные таблицы в шаблоне Google Docs, а внедренный алгоритм сам вычисляет показатель близости по формуле. По результатам вычислений нужно отобрать проекты с наименьшими значениями. Например, сайт www.mebel-moskva.ru имеет показатель близости «0» — это значит, что он максимально совпадает.

Подытоживаем — как выбрать конкурентов и URL

Подведем итог, какие факторы нужно учитывать при выборе конкурентов и URL:

Здесь нужно сделать маленькую, но актуальную в 2020 году ремарку: в Яндексе есть проблема с накруткой ПФ, что приводит к искажению внутренних и внешних факторов. Если у вас есть информация, что проект накручивается, его тоже нужно вычеркивать из анализа, так как вы можете сделать неверные выводы. Одним из признаков может быть неестественная частота брендовых запросов по Yandex WordStat, неестественные темпы роста — сайт выскочил в ТОП за 1-2 апдейта и там закрепился, или неестественная пропорция видимости в разных поисковых системах — например, в Яндексе у сайта видимость 80%, а в Google — 0,2%. Конечно есть кейсы, закрытые от той или иной поисковой системы намеренно (для редких тематик) — это является нормой, но в большинстве случаев такая картина указывает на накрутку ПФ.

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

1. Трафик — можно анализировать общий и поисковый (используйте similarweb и другие источники, которым вы доверяете).

2. Показатель ИКС — позволяет оценить объем трафика, если вы не доверяете similarweb.

3. Видимость по семантическому ядру — проверяется в любой системе съема позиций, в том числе в «Пиксель Тулс».

4. Страницы в индексе Яндекса, Google, с поддоменами и без.

5. Возраст домена, главной страницы, индексации.

6. Процент пересечения по ядру: сервис keys.so с помощью базы своих поисковых запросов позволяет сказать, насколько пересекаются ваши запросы, в которых показывается сайт.

7. Наличие, активность, объем трафика инфо-раздела.

8. Ссылочные показатели — сколько ссылок на домен, Domain Rank, процент безанкорных ссылок (megaindex, ahrefs, Majestic).

9. Мобильная адаптация — Google mobile-friendly для основных разделов.

10. Скорость — загрузка основных URL по Google Page Speed Insights, хотя скорость и не является каким-то суперважным фактором со 100% корреляцией, но тоже желательно его анализировать.

11. Регионы — поддомены для регионов, видимость в нескольких регионах.

12. Соц. сети, как признак маркетинговой активности — наличие и активность групп в социальных сетях, группы, чата.

13. Особенности бизнеса: тип проекта, бизнес-модель, позиционирование и т.д.

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

Шаг №1: Шаблон в Google Docs

Берем шаблон в Google Docs. Там есть все факторы, о которых мы только что говорили.

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

Шаг №2: Список конкурентов

На данном этапе мы получаем список из 10-20 конкурентов для анализа. При этом берем либо раздел в системе съема позиций, которую вы ведете — например, раздел «Конкуренты» в модуле ведения проектов «Пиксель Тулс», либо можно взять 50-100 наиболее частотных запросов из результатов инструмента «Анализ видимости и конкурентов» и получаете по любой интересующей семантике список из 10-20 конкурентов.

Ссылочки на упомянутые инструменты: «Обнаружение ТОП-20 проектов по значению видимости», «Анализ видимости и конкурентов».

Шаг №3: Заполняем данные из SimilarWeb

Заходим на SimilarWeb. Чтобы получить объем поискового трафика, нужно сделать нехитрые математические вычисления. Берем суммарное количество визитов сайта в месяц, умножаем на долю поискового трафика у данного проекта и на долю органики.

Таким образом, SimilarWeb объединяет два источника — органику и платную выдачу. В представленном примере суммарное количество визитов сайта составляет 68,42К, доля поискового трафика = 25,07%, а доля органики = 99,67%.

Шаг №4: Берем данные Keys.so

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

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

Шаг №5: Определяем ИКС, возраст, количество страниц в индексе

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

Если конкуренты были найдены с помощью «Анализа видимости и конкурентов», то показатели уже определены, вам нужно просто скопировать их в таблицу.

Шаг №6: Получаем адаптацию и Page Speed

Здесь используются фришные инструменты от Google, с помощью которых вы сможете получить вспомогательные параметры о мобильной адаптации и скорости загрузки основных URL. Для проверки адаптации используем Mobile-Friendly Test Tool:

Для аналитики скорости загрузки — PageSpeed Insights:

Шаг №7: Оценка близости и выводы

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

• ручной анализ проектов — актуально при запуске проекта в незнакомой нише;

• фиксируем основные выводы и наш пользовательский опыт: что понравилось, какие сильные стороны и УТП, отличия бизнес-модели;

• находим наиболее ёмкие по трафику разделы: инфо, категории товаров, трафиковые запросы. Используем успешный опыт для роста;

• размечаем эти проекты как ключевых конкурентов бизнеса в поиске и используем URL с именно этих проектов для анализа на уровне запроса.

Мы пытаемся скопировать успешные приемы наиболее близких к вам конкурентов и делаем выводы относительно предстоящих работ для улучшения ситуации.

Как это работает

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

На уровне ссылок часто оказывается, что вам не нужна ссылочная стратегия. У конкурента может быть меньше ссылок или столько же, как у вас, поэтому нет смысла убиваться и тратить время на это. То же самое с Google Page Speed Insights — вам кто-то порекомендовал довести показатель до 100%, но по факту вы видите, что у конкурентов цифра не превышает 50%. Вы должны понимать на уровне стратегии, какие факторы нужно улучшать до показателей конкурента, а какие можно не трогать.

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

• тип URL адреса, который мы продвигаем и тип конкурента в выдаче;

• объем текста — SEO специалисты используют символы для подсчета, в русском языке показатель пересчитывается с помощью магического коэффициента «6.5», который указывает примерную длину слова в русском языке0, иногда нужно разбивать на текстовые фрагменты и plain text;

• вхождения — как правило, в штуках для каждого слова и N-грамм;

• LSI — поисковая система придает вес не только тем словам, которые встречаются в поисковом запросе, но и определенному набору синонимов и тематических слов, которые характеризуют соответствие конкретной странице запросу пользователя;

• оптимизация тега Title, количество релевантных URL по тегу;

• исходящие ссылки — количество, их анкоры + внешние;

• входящие ссылки — их показатели, анкоры, количество;

• интерактивные элементы — калькулятор, КВИЗы, видео;

• скорость загрузки и адаптация конкретной страницы — сравнение показателей URL;

• факторы домена — ИКС, наличие HTTPS, номера «8 800» и внешних ссылок на сайт.

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

Посмотреть вебинар можно на YouTube.

Шаг №1: Выбираем запрос/группу для анализа

Важный момент — мы должны не просто взять случайный поисковый запрос. Берется группа запросов или фраз, по которым значение ROI максимальное. Продвижение по этому запросу приведет к реальному профиту. Делается это довольно просто:

Вы можете посчитать, какая частота у поискового запроса, какой тип спроса и, если у вас коммерческий сайт, по формуле узнать объем коммерческого спроса по группе, который отвечает нашей потребности продать что-то пользователю. Акцент делаем на фразы с высоким потенциалом конверсии — бывает полезно анализировать, какие фразы хорошо продают на карточке и на листинге. Вычисление прогнозируемого объема продаж — отдельный вид искусства, которым занимаются немногие. Если вы это сделаете, то попадете в 2% SEO-специалистов, которые проводят работы только по поисковым запросам с максимальной окупаемостью для бизнеса. Подробно узнать, как проводится расчёт ROI (ROMI) по фразе и группам фраз можно из нашего видео.

Шаг №2: Выбор URL конкурентов

Это один из самых важных шагов, который часто наивно пропускают — ведь можно что-то выбрать наугад и этим ограничиться. Какими принципами нужно руководствоваться:

Работать нужно только с теми конкурентами, которые входят в ТОП-5 по фактору близости. Формула ранжирования устроена по принципу сот — учитываются только близкие друг к другу сайты по типу. Если вы продвигаете карточку товара, то нет смысла анализировать разделы, если продвигаете главную — не анализируйте внутренние страницы конкурентов. Кроме того, важно выбирать URL с точным попаданием, чтобы не получить усредненную картину, которая совершенно бесполезна в анализе.

Пример выбора URL

Продолжим рассматривать тот же поисковый запрос, что и в предыдущих примерах — «мебель для дома». Продвигать будем внутреннюю страницу каталога https://8mebel.ru/catalog/mebel-dlya-doma. Каких конкурентов выбрать?

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

Шаг №3: Анализ факторов

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

Рассмотрим результаты по приведенному примеру: объем текста в словах — здесь у нас все довольно неплохо, различие с рекомендуемым объемом составляет не более 7%, поэтому что-то менять нет смысла. Смотрим дальше каждый параметр и делаем все, чтобы привести значения к цифрам конкурентов.

Шаг №4: Внесение корректировок

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

Как правило, незначительные изменения не приносят значимого результата, хотя эта аксиома и не всегда работает в SEO. Например, плохо конвертит сайт — если показатель конверсии «5», то ситуацию не исправит перестановка кнопки или какие-то мелкие апгрейды. Возможно, конверсия вырастет на 10% относительно текущего значения, но кратного роста это никогда не даст. Отдавайте приоритет тем изменениям, которые затрагивают весь сайт целиком (большое количество тегов или страниц) или могут быть масштабированы. Точечное однократное изменение не дает устойчивого эффекта. Не забывайте делать бэкап — часто это спасает ситуацию. В поисковых системах есть опция отката, хоть она и не всегда работает на 100%. Но если вы где-то «напортачили», есть возможность вернуться плюс-минус к первоначальному этапу.

Шаг №5: Отслеживание динамики

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

Здесь мы обязательно добавляем такую группу URL-адресов, которую проработали в модуле ведения проектов, и смотрим, какой профит дали эти изменения. Секрет в том, что 80% работ, которые делают SEO-специалисты, не дают никакого числимо значимого результата — то есть, вообще не окупаются. Когда мы не отслеживаем динамику, мы пребываем в комфортном состоянии «незнания». Но когда мы открываем глаза, то видим, что 80% от проделанной работы были бесполезны с точки зрения видимости или позиций. Вы могли бы делать в 5 раз меньше, но получать при этом хороший профит. Расстраиваться тут не нужно, так как отсутствие результата — тоже результат! Теперь вы знаете, что делать нужно, а над чем работать нет смысла.

Те, кто занимается клиентским подходом, часто боятся признаться клиентам, что проведенные работы не дали ожидаемого результата. Здесь нужно оставаться до конца искренними, поскольку клиенты вашу искренность высоко оценят. Когда мы говорим клиенту, что 20% выделенного бюджета были потрачены на нерезультативные мероприятия, вы и заказчик понимаете, что этого больше не повторится — вы опробовали эти методы и убедились в их непригодности в конкретной ситуации.

10 пунктов проверки релевантности

В рамках этих 10 пунктов релевантности кроется около 80% успеха, поэтому проверять их нужно:

1. Региональная привязка.

2. Возраст документа.

3. Нужный тип сайта (соответствие интенту).

4. Оптимальный тип документа по запросу.

5. Title, h2 и meta-теги.

6. Текстовая оптимизация.

7. Запросозависимые поведенческие факторы.

8. Внешние факторы (ссылки).

9. Коммерческие факторы.

10. Технические показатели и адаптивная версия.

Внешние входящие ссылки

Мы сегодня мало говорили о ссылках, хотелось бы дополнить эту тему. Компания «Пиксель Тулс» проводила свое исследование — выяснилось, что есть определенная корреляция с внешними ссылками в Яндексе и Google. Есть два сильных фактора, которые лучше всего коррелируют с позициями в выдаче:

Эти факторы остаются сильными, хардовыми сеошными факторами до сих пор. Исследование на тему «Факторы ранжирования в Яндексе и Google» вы можете посмотреть в видео.

Когда мы используем любой внешний сервис ссылочного анализа, например, Ahrefs, он видит лишь одну из четырех хороших ссылок. Под понятием «хорошая» имеется в виду ссылка, размещенная на нормальном сайте, которая может быть проиндексирована и отображается в Google Search Console. Плюс-минус 80% ссылок, которые учитываются в ранжировании, встречаются в Google Search Console. До 90% ссылок в Ahrefs — «мусорные», которые вряд ли будут сказываться на ранжировании

Объединяя эти данные с информацией из исследования, которое компания «Пиксель Тулс» проводила в 2019 году, можно сделать вывод, что в большинстве случаев ничего анализировать не нужно. Надо обеспечить некоторое штучное количество ссылок на URL-адрес с частичным вхождением в анкоры слов из поисковых запросов, которые вы продвигаете. Бывает достаточно нескольких ссылок для удовлетворения ссылочных факторов в Яндексе, а в Google дела обстоят несколько иначе — значение факторов насыщается медленнее. Работать с Ahrefs нужно аккуратно. Более подробно об этой теме рассказал наш коллега — Юрий Хаит, вы можете ознакомиться с его вебинаром и презентацией.

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

1. На какие факторы обратить внимание при анализе ТОПа на уровне сайта? Назовите не менее 7 основных факторов.

2. На какие факторы обратить внимание при анализе ТОПа на уровне запроса? Назовите не менее 7 основных факторов.

3. Вы проводите анализ внутренней оптимизации URL под продвигаемый запрос. Один из проектов в выдаче явно «крутит» ПФ. Стоит ли включить его в выборку для оценки?

4. Для каких запросов требуется проводить детальный анализ ТОП выдачи в первую очередь? На какой показатель ориентироваться?

1. Шаблон анализа конкурентов.

2. Формула оценки близости конкурентов.

3. Инструмент «Анализ видимости и конкурентов».

4. Вебинар по поиску причин низких позиций сайта по запросу.

5. Инструмент анализа ТОП выдачи Яндекса и Google по запросу.

6. Вебинар «Всё о поисковых запросах», в том числе, оценка групп фраз по ROI.

7. Оценка трафика проектов.

8. Регулярная оценка факторов ранжирования по ВСЕМ запросам в проекте.

Чтобы не пропускать наши новые видео, рекомендуем вступить в Telegram-чат, подписаться на наш YouTube-канал, добавиться в друзья на FB и подписаться на Telegram-канал.

Задайте вопрос или оставьте комментарий

Другие материалы

Трафик на сайт из поисковых систем. Прогноз посещаемости сайта.

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

Существует много методов прогноза посещаемости. Один из самых распространенных – анализ трафика в зависимости от занимаемой позиции сайта.

Допустим, вы подобрали семантическое ядро (список ключевых фраз, по которым будете продвигать свой сайт; методика подбора сем.ядра подробно описана тут). Как узнать, сколько человек придет, если ваш сайт по всем этим словам попадет, скажем, в ТОП-10?

Для определения трафика следует использовать статистику по ключевым фразам.

Для Яндекса – Яндекс.Вордстат, для Google – Google Тренды. Дальше речь пойдет о Яндексе, по аналогии сможете сами спрогнозировать трафик из Google.

1. Рассчитываем спрос по словам с помощью сервиса wordstat.yandex

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

Для получения точного количества показов нужно использовать специальные операторы: «кавычки» («») – показы по выбранному запросу и всем его словоформам, а также «восклицательный знак» (″!″) – исключение иных словоформ данного запроса.

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

Например, вас интересует, сколько человек ищет «ремонт автокондиционеров»:

На первый взгляд 17 898 показов в месяц кажется цифрой огромной, однако на самом деле, если вы не используете операторы кавычки и восклицательный знак (как мы сделали это на рисунке выше), 17 898 показов – это сумма всех запросов, где встречается словосочетание «ремонт автокондиционеров».

Т.е. включая все запросы шлейфа: «ремонт автокондиционеров митино», «инструмент для ремонта автокондиционеров купить» и т.д. – это могут быть целевые и нецелевые запросы. Цифра 17898 будет непоказательна.

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

Перед союзами и предлогами можно ставить знак «+», этот оператор принудит посчитать именно фразы с этим союзом или предлогом, иначе союзы и предлоги учтены не будут.

Фразу «ремонт автокондиционеров» следует вбить так:

Используя специальные операторы, мы получили цифру чистого спроса по запросу «ремонт автокондиционеров» – и это уже совсем другая цифра, всего 1293 показа в месяц.

Отмечу, что при подсчете трафика имеет смысл также учитывать регион сайта (выберите пункт «По регионам»), сезонность (см. «Историю запросов»).

Теперь, зная точное количество показов в месяц, трафик можно рассчитать по формуле:

Трафик = количество показов * CTR

где CTR — показатель кликабельности сайта в результатах поиска.

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

Количество показов узнаем с помощью сервиса Wordstat, как узнать CTR?

2. Рассчитываем CTR

За основу можно взять исследование Яндекса 2011 г. (оригинал на английском языке), где специалисты Яндекса оценивали сниппеты с обычной и дополнительной подсветкой, при этом показали цифры кликабельности сниппетов. На рисунке ниже приведены значения с обычной подсветкой:

Когда-то давно для прогноза трафика мы опирались на другую таблицу, которая давно гуляет в Интернете и была составлена частично на основе этого исследования.

Многие SEO-специалисты до сих пор работают по ней, примерные цифры по трафику она тоже покажет:

Как мы оцениваем трафик в зависимости от позиций

В своей работе мы ежедневно рассчитываем трафик при составлении сем. ядра. Регулярный анализ трафика позволил составить нам свою таблицу коэффициента кликабельности сниппета (CTR) в зависимости от позиции сайта.

Высокие позиции сайта, как правило, дают высокий CTR:

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

Зная CTR, можно легко рассчитать примерное минимальное и максимальное количество пользователей, которые посетят ваш сайт.

Прогноз трафика в зависимости от позиции, пример расчета

Спрогнозируем трафик для интернет-магазина материалов для временных тату по ключевым запросам «блеск тату материалы», «все для тату интернет магазин», «интернет магазин хны для тату», «купить все для блеск тату».

1. Для начала определим точное вхождение фраз с помощью специальных операторов и сервиса Wordstat, регион Россия:

«!блеск !тату !материалы» – 9 показов в месяц;
«!все +для !тату !интернет !магазин» – 27 показов в месяц;
«!интернет !магазин !хны +для !тату» – 12 показов в месяц;
«!купить !все +для !блеск !тату» – 18 показов в месяц.

Т.е. если продвинуть сайт на первую страницу по этим запросам, то его увидят 66 пользователей в месяц. Сколько же из них перейдет на сайт? 

2. Предположим, сайт займет следующие позиции по данным словам:

Теперь можно воспользоваться формулой и подсчитать примерный трафик:

Минимум посетителей по запросу «все для тату интернет магазин» = (частота показов) 27 * 0,2 (20% — CTR нижней границы по 1 месту) = 5,4, округляем до 5 посетителей.

Максимум посетителей по запросу «все для тату интернет магазин» = (частота показов) 27 * 0,5 (50% — CTR нижней границы по 1 месту) = 13,5, округляем до 14 посетителей.

Итого по запросу «все для тату интернет магазин» можно получить от 5 до 14 посетителей в месяц, если сайт попадет на первое место.

Считаем аналогичным образом для остальных запросов:

А теперь сравним ожидаемый трафик с полученным по факту по этим запросам:

Наш прогноз по позициям сбылся:

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

Теперь вы можете рассчитать примерный трафик для своего сайта. Лучше для прогноза трафика для молодых сайтов ориентироваться на CTR для ТОП 8-10, т.е. от 2 до 4%.

В идеале составьте таблицу эксель, где поэкспериментируйте с разными позициями, которые может занять сайт. Т.е. сколько минимум и максимум посетителей придут на сайт, если сайт по запросам попадет в ТОП-10, ТОП-5 и ТОП-1, это позволит своевременно скорректировать семантическое ядро и получить нужное количество посетителей.

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

Остались вопросы? Задавайте их в комментариях. Понравилась статья? Ставьте Лайк =)

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

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

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

1. PR-CY.ru

Сайт сервиса: pr-cy.ru

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

Ниже можно посмотреть пример отчета:

Чтобы посмотреть запросы конкурента, введите адрес его сайта на главной странице сервиса pr-cy.ru и нажмите кнопку «Анализировать». Откроется страница с результатами анализа, на которой будут данные, по каким запросам продвигается сайт конкурента и на каких позициях он находится.

Скриншот формы:

Плюсы сервиса:

• Позволяет посмотреть, по каким запросам продвигается сайт конкурента.
• Помимо списка ключевых фраз, выводит их частоту и позицию сайта. Вы можете оценить, по каким запросам сайт конкурента находится в ТОП-10.
• Для анализа 1-2 сайтов не требуется регистрация. Достаточно ввести адрес сайта на странице pr-cy.ru и нажать кнопку «Анализировать».

Минусы сервиса:

• Можно посмотреть только 100 запросов в каждой поисковой системе.
• При анализе большого числа сайтов сервис потребует зарегистрироваться.

2. X-tool.ru

Сайт сервиса: xtool.ru/analyze/

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

Пример отчета из сервиса:

Чтобы посмотреть запросы, по которым выводится сайт в поисковых системах, необходимо на сайте Xtool.ru добавить URL сайта в специальную форму и нажать кнопку «Проверить»:

В полученном отчете необходимо перейти на вкладку «Видимость в Яндексе» или «Видимость в Google» для просмотра запросов в соответствующей поисковой системе.

Плюсы сервиса:

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

Минусы сервиса:

• Без регистрации можно посмотреть только 100 запросов для каждой поисковой системы. Для просмотра большего объема данных требуется регистрация.
• Показывает данные не для всех сайтов.

3. PromoPult (ранее — Сеопульт)

Сайт сервиса: promopult.ru

Это система автоматического продвижения сайтов. После регистрации вы можете создать в ней проект. В процессе создания система выводит текущие позиции сайта в Яндексе и Google. Таким образом, используя Сеопульт, можно посмотреть, по каким запросам продвигается сайт конкурентов. При этом заказывать само продвижение сайта не нужно.

Пример таблицы со списком запросов в системе:

Плюсы сервиса:

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

Минусы сервиса:

• Нельзя выгрузить данные.
• Требуется регистрация для просмотра данных.

Резюме

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

В завершении статьи хочу посоветовать другие полезные статьи по теме:

Расположение окна JavaScript

Объект window.location может использоваться для получения адрес текущей страницы (URL) и перенаправить браузер на новую страницу.

Расположение окна

Объект window.location можно записать без префикса окна.

Некоторые примеры:

• window.location.href возвращает href (URL) текущей страницы
• окно.location.hostname возвращает доменное имя веб-хоста
• window.location.pathname возвращает путь и имя файла текущей страницы
• window.location.protocol возвращает используемый веб-протокол (http: или https 🙂
• window.location.assign () загружает новый документ

Расположение окна Href

Свойство window.location.href возвращает URL-адрес текущей страницы.

Пример

Отображение href (URL) текущей страницы:

document.getElementById («demo»). innerHTML =
«Расположение страницы:» + window.location.href;

Результат:

Расположение окна Имя хоста

Свойство window.location.hostname возвращает имя интернет-хоста (текущей страницы).

Пример

Показать имя хоста:

документ.getElementById («демонстрация»). innerHTML =
«Имя хоста страницы» + window.location.hostname;

Результат:

Путь к расположению окна

Свойство window.location.pathname возвращает путь к текущая страница.

Пример

Показать путь к текущему URL-адресу:

document.getElementById («демонстрация»). innerHTML =
«Путь к странице» + window.location.pathname;

Результат:

Протокол определения местоположения окна

Окно .Свойство location.protocol возвращает веб-протокол страницы.

Пример

Показать веб-протокол:

document.getElementById («демонстрация»). innerHTML =
«Протокол страницы» + window.location.protocol;

Результат:

Порт расположения окна

Свойство window.location.port возвращает номер интернет-хоста. порт (текущей страницы).

Пример

Показать имя хоста:

документ.getElementById («demo»). innerHTML =
«Порт число: «+ window.location.port;

Результат:

Большинство браузеров не отображают номера портов по умолчанию (80 для http и 443 для https)

Назначить расположение окна

Метод window.location.assign () загружает новый документ.

Пример

Загрузить новый документ:

API геолокации — веб-API

API геолокации позволяет пользователю предоставлять свое местоположение веб-приложениям, если они того пожелают. По соображениям конфиденциальности у пользователя запрашивается разрешение сообщить информацию о местоположении.

WebExtensions, которые хотят использовать объект Geolocation , должны добавить разрешение "geolocation" в свой манифест.Операционная система пользователя предложит пользователю разрешить доступ к местоположению при первом запросе.

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

Доступ к API геолокации осуществляется через вызов navigator.geolocation ; это заставит браузер пользователя запросить у него разрешение на доступ к данным о его местоположении. Если они согласны, то браузер будет использовать лучшие доступные функции на устройстве для доступа к этой информации (например, GPS).

Теперь разработчик может получить доступ к этой информации о местоположении несколькими способами:

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

• Обязательный успешный обратный вызов: если получение местоположения прошло успешно, обратный вызов выполняется с объектом GeolocationPosition в качестве единственного параметра, обеспечивая доступ к данным местоположения.
• Необязательный обратный вызов ошибки: если получение местоположения не удалось, обратный вызов выполняется с объектом GeolocationPositionError в качестве единственного параметра, предоставляя информацию для доступа о том, что пошло не так.
• Необязательный объект PositionOptions , который предоставляет параметры для получения данных о местоположении.

Для получения дополнительной информации об использовании геолокации прочтите Использование API геолокации.

Геолокация

Основной класс этого API — содержит методы для получения текущего положения пользователя, отслеживания изменений в его положении и очистки ранее установленного наблюдения.

Геолокация Местоположение

Представляет позицию пользователя.Экземпляр GeolocationPosition возвращается при успешном вызове одного из методов, содержащихся в Geolocation , внутри успешного обратного вызова и содержит метку времени плюс экземпляр объекта GeolocationCoordinates .

Геолокация Координаты

Представляет координаты позиции пользователя; Экземпляр GeolocationCoordinates содержит данные о широте, долготе и другую важную информацию.

Ошибка геолокации

GeolocationPositionError возвращается в результате неудачного вызова одного из методов, содержащихся в Geolocation , внутри обратного вызова ошибки и содержит код ошибки и сообщение.

Navigator.geolocation

Точка входа в API. Возвращает экземпляр объекта Geolocation , из которого можно получить доступ ко всем остальным функциям.

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

  кузов {
  отступ: 20 пикселей;
  цвет фона: # ffffc9
}

button {
  прибыль: .5рем 0;
}
  

HTML

   Показать мое местоположение  

 
 
  

JavaScript

  function geoFindMe () {

  const status = document.querySelector ('# статус');
  const mapLink = document.querySelector ('# карта-ссылка');

  mapLink.href = '';
  mapLink.textContent = '';

  function success (position) {
    const latitude = позиция.coords.latitude;
    const longitude = position.coords.longitude;

    status.textContent = '';
    mapLink.href = `https://www.openstreetmap.org/#map=18/$ {latitude} / $ {longitude}`;
    mapLink.textContent = `Широта: $ {широта} °, Долгота: $ {долгота} °`;
  }

  function error () {
    status.textContent = 'Невозможно определить ваше местоположение';
  }

  if (! navigator.geolocation) {
    status.textContent = 'Геолокация не поддерживается вашим браузером';
  } else {
    status.textContent = 'Поиск…';
    навигатор.geolocation.getCurrentPosition (успех, ошибка);
  }

}

document.querySelector ('# find-me'). addEventListener ('щелчок', geoFindMe);
  

Результат

Таблицы BCD загружаются только в браузере

Доступность

Поскольку определение местоположения на основе Wi-Fi часто предоставляется Google, стандартный API геолокации может быть недоступен в Китае. Вы можете использовать местных сторонних поставщиков, таких как Baidu, Autonavi или Tencent. Эти службы используют IP-адрес пользователя и / или локальное приложение для обеспечения улучшенного позиционирования.

Content-Location — HTTP | MDN

Заголовок Content-Location указывает альтернативное расположение для возвращаемых данных. Основное использование — указать URL-адрес ресурса, переданного в результате согласования содержимого.

Расположение и Content-Location разные. Location указывает URL-адрес перенаправления, а Content-Location указывает прямой URL-адрес, который будет использоваться для доступа к ресурсу без дальнейшего согласования содержимого в будущем. Location — это заголовок, связанный с ответом, а Content-Location связан с возвращаемыми данными. Это различие без примеров может показаться абстрактным.

Запрос данных с сервера в разных форматах

Допустим, API сайта может возвращать данные в форматах JSON, XML или CSV. Если URL-адрес для определенного документа находится на https://example.com/documents/foo , сайт может возвращать разные URL-адреса для Content-Location в зависимости от заголовка Accept запроса:

Эти URL-адреса являются примерами — сайт может обслуживать файлы разных типов с любыми шаблонами URL-адресов, которые он пожелает, например, параметр строки запроса: / documents / foo? Format = json , / documents / foo? Format = xml и так далее.

Тогда клиент сможет запомнить, что версия JSON доступна по этому конкретному URL, пропуская согласование содержимого при следующем запросе этого документа.

Сервер также может учитывать другие заголовки согласования содержимого, например Accept-Language .

Указание на новый документ (HTTP 201 Создан)

Допустим, вы создаете новую запись в блоге через API сайта:

 PUT / новое / сообщение
Хост: example.com
Content-Type: текст / уценка

# Моя первая запись в блоге!

Я сделал это с помощью `example.com 'API. Надеюсь, это сработало.
 

Сайт возвращает типичное сообщение об успешном выполнении, подтверждающее публикацию сообщения. Сервер указывает , где — новое сообщение с Content-Location :

 HTTP / 1.1 201 Создано
Тип содержимого: текст / обычный; charset = utf-8
Расположение содержимого: / my-first-blog-post

✅ Успех!
 

Указание URL-адреса результата транзакции

Допустим, у вас есть

  
  

     Кому вы хотите отправить деньги?
      
    
  

  

     Сколько?
      
    
  

   Отправить деньги 

  

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

 HTTP / 1.1 200 ОК
Content-Type: текст / html; charset = utf-8
Расположение содержимого: / мои-поступления / 38


  (много HTML…) 

 Вы отправили ExampleUser 38,00 долларов 

  (Еще больше HTML…) 
 

Таблицы BCD загружаются только в браузере

Получить текущее местоположение с помощью Core Location (Учебное пособие)

В прошлом месяце я добавил в свое приложение для поездов Rapidly функцию «Показать ближайший вокзал».Я наткнулся на несколько проблем, следуя онлайн-руководствам по реализации Core Location implement. В этом посте мы рассмотрим, как получить текущее местоположение пользователя с помощью Core Location и устранить некоторые распространенные проблемы.

Мы будем использовать CLLocationManager (CL означает Core Location) для обработки информации о местоположении. Вот код инициализации, который мы будем использовать:

  // ViewController.swift

импорт UIKit
импортировать CoreLocation

class ViewController: UIViewController {
    
    пусть locationManager = CLLocationManager ()
  
     переопределить функцию viewDidLoad () {
        супер.viewDidLoad ()
        locationManager.delegate = self
    }
}

extension ViewController: CLLocationManagerDelegate {
  // обрабатываем здесь методы делегата диспетчера местоположения
}
  

Вот общий процесс получения местоположения пользователя:

Содержание

1. Запрос разрешения местоположения у пользователя
2. Получение текущего местоположения пользователя
3. Ошибка обработки
4. ‘didUpdateLocation’ не вызывался даже после того, как я установил делегат! Что случилось?
5. Не забудьте проверить функцию CoreLocation на реальном устройстве
6. requestLocation () может занять больше времени для получения данных о местоположении
7. Точность
8. Получение данных о местоположении, когда приложение работает в фоновом режиме

Запрос разрешения местоположения у пользователя

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

Мы можем запросить разрешение на определение местоположения, вызвав .requestWhenInUseAuthorization () , чтобы получить данные о местоположении, когда приложение активно, или .requestAlwaysAuthorization () , чтобы получить данные о местоположении, когда приложение активно или в фоновом режиме (вот как Waze / Google Карты могут продолжать получать данные о вашем местоположении, даже если они находятся в фоновом режиме).

  // запрашиваем разрешение на получение местоположения пользователя, когда приложение используется (т.е. активно)
// это покажет пользователю окно с предупреждением
locationManager.requestWhenInUseAuthorization ()

// запрашиваем разрешение на получение местоположения пользователя, когда приложение используется или в фоновом режиме
// это покажет пользователю окно с предупреждением
locationManager.requestAlwaysAuthorization ()
  

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

В Info.plist наведите указатель мыши на любую строку и нажмите кнопку «+».Затем введите «Конфиденциальность — Местоположение» и используйте автозаполнение, чтобы выбрать правильный ключ из списка.

Конфиденциальность — Местоположение при использовании Описание использования для. requestWhenInUseAuthorization ()

Конфиденциальность — местоположение всегда и когда используется Описание использования для .requestAlwaysAuthorization ()

Если ваше приложение должно поддерживать iOS 10 и более ранние версии и всегда требовать авторизации, вам необходимо добавить ключ Privacy — Location Always Usage Description вместе с «Конфиденциальность — Location Always and When In Use Usage Description».

После выбора правильного ключа введите причину в столбце «Значение»:

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

Щелкните правой кнопкой мыши «Info.plist» и выберите «Открыть как> Исходный код».

Затем введите ключ и значение, используя и

Ключи: NSLocationWhenInUseUsageDescription , NSLocationAlwaysAndWhenInUseUsageDescription и NSLocationAlwaysUsageDescription (для iOS 10 и более ранних версий).

Текст, введенный вами в список, будет показан в предупреждении о разрешении запроса:

Это предупреждение будет отображаться после первого вызова .requestWhenInUseAuthorization () или .requestAlwaysAuthorization () (когда пользователь не нажал «Разрешить» или «Не разрешать»).

После того, как пользователь нажмет «Разрешить» или «Запретить», будет вызван метод делегата didChangeAuthorization status: .

  расширение ViewController: CLLocationManagerDelegate {
    // вызывается при изменении статуса авторизации для разрешения основного местоположения
    func locationManager (_ manager: CLLocationManager, didChangeAuthorization status: CLAuthorizationStatus) {
        print ("статус авторизации менеджера местоположения изменен")
    }
}
  

Следует отметить, что этот метод делегата (didChangeAuthorization status) всегда будет вызываться после строки locationManager.delegate = self , даже если диалоговое окно разрешения не было показано пользователю раньше.

Вот возможный случай статуса авторизации:

  расширение ViewController: CLLocationManagerDelegate {
    // вызывается при изменении статуса авторизации для разрешения основного местоположения
    func locationManager (_ manager: CLLocationManager, didChangeAuthorization status: CLAuthorizationStatus) {
        print ("статус авторизации менеджера местоположения изменен")
        
        switch status {
        дело .авторизованоВсегда:
            print ("пользователь разрешает приложению получать данные о местоположении, когда приложение активно или в фоновом режиме")
        case .authorizedWhenInUse:
            print ("пользователь разрешает приложению получать данные о местоположении, только когда приложение активно")
        case. denied:
            print ("пользователь нажимает 'запретить' в диалоговом окне разрешений, не может получить данные о местоположении")
        case .restricted:
            print ("настройка родительского контроля запрещает данные о местоположении")
        case .notDetermined:
            print («диалоговое окно разрешения местоположения раньше не отображалось, пользователь не нажимал разрешить / запретить»)
        }
    }
}
  

Мы можем проверить текущий статус авторизации с помощью CLLocationManager.authorizationStatus () :

  // когда пользователь нажимает кнопку, чтобы получить местоположение
@IBAction func getCurrentLocationTapped (_ sender: Any) {
    retriveCurrentLocation ()
}

func retriveCurrentLocation () {
    let status = CLLocationManager.authorizationStatus ()

    if (status == .denied || status == .restricted ||! CLLocationManager.locationServicesEnabled ()) {
        // показываем пользователю предупреждение о том, что ему нужно разрешить данным о местоположении использовать некоторые функции вашего приложения
        возвращение
    }

    // если ранее не отображалось диалоговое окно разрешения местоположения, показать его пользователю
    если (статус ==.не определено){
        locationManager.requestWhenInUseAuthorization ()

        // если вы хотите, чтобы приложение получало данные о местоположении даже в фоновом режиме, используйте requestAlwaysAuthorization
        // locationManager.requestAlwaysAuthorization ()
        возвращение
    }
    
    // на этом этапе статус авторизации авторизован
    // запрашиваем данные о местоположении один раз
    locationManager.requestLocation ()
  
    // запускаем мониторинг данных о местоположении и получаем уведомления всякий раз, когда в данных о местоположении происходят изменения / каждые несколько секунд, пока не будет вызвана функция stopUpdatingLocation ()
    // locationManager.startUpdatingLocation ()
}
  

Нам также необходимо будет проверить, включены ли службы определения местоположения на телефоне пользователя (используя CLLocationManager.locationServicesEnabled () ), пользователь мог отключить возможность служб определения местоположения на устройстве (глобально, что влияет на все приложения), но разрешить вам приложение для доступа к данным о местоположении. В этом случае метод делегата locationManager: didFailWithError: будет вызываться, когда приложение пытается получить данные о местоположении, с кодом ошибки kCLErrorDenied .

Получение текущего местоположения пользователя

Убедившись, что службы определения местоположения включены и статус авторизации авторизован, мы можем начать запрашивать местоположение, вызвав locationManager.requestLocation () (единовременная доставка данных о местоположении) или иметь постоянный поток обновлений местоположения с помощью locationManager.startUpdatingLocation () .

Оба эти метода дадут указание устройству iOS получить данные о его текущем местоположении, и после получения данных о местоположении будет вызван метод делегата didUpdateLocations location: .Разница в том, что .requestLocation () будет вызывать только местоположения didUpdateLocations: один раз, тогда как .startUpdatingLocation () будет продолжать вызывать местоположений didUpdateLocations: каждые несколько секунд или при изменении местоположения, пока вы не остановите его, вызвав locationManager.stopUpdatingLocation .

.requestLocation () поток

расположения didUpdateLocations: вызывается только один раз, когда мы используем .requestLocation.

.requestLocation () передаст только одно местоположение в массив didUpdateLocations location .

  расширение ViewController: CLLocationManagerDelegate {
    func locationManager (_ manager: CLLocationManager, didUpdateLocations местоположения: [CLLocation]) {
        // .requestLocation передаст только одно местоположение в массив location
        // следовательно, мы можем получить к нему доступ, взяв первый элемент массива
        if let location = locations.first {
            self.latitudeLabel.text = "\ (location.coordinate.latitude)"
            self.longitudeLabel.text = "\ (location.coordinate.longitude)"
        }
    }
}
  

.startUpdatingLocation () поток

Расположение didUpdateLocations: вызывается всякий раз, когда происходит обновление местоположения / каждые несколько секунд, пока мы не вызовем locationManager.stopUpdatingLocation.

.startUpdatingLocation () может передать более одного местоположения в массив didUpdateLocations местоположений .

  расширение ViewController: CLLocationManagerDelegate {
    func locationManager (_ manager: CLLocationManager, didUpdateLocations местоположения: [CLLocation]) {
        // .startUpdatingLocation может передать более одного местоположения в массив местоположений
      для местоположения в регионах {
        // что-то делаем с данными каждого местоположения
        // последний элемент - это самые последние данные о местоположении
      }
    }
}
  

Ошибка обработки

Возможно, приложению не удалось получить данные о местоположении (после вызова.requestLocation или .startUpdatingLocation), когда это произойдет, будет вызвана ошибка didFailWithError: .

  func locationManager (_ manager: CLLocationManager, didFailWithError error: Error) {
    // возможно, пользователь не включил службу определения местоположения на устройстве
    // или внутри здания может не быть сигнала GPS
  
    // может быть хорошей идеей показать пользователю предупреждение, чтобы попросить его дойти до места с сигналом GPS
}
  

‘didUpdateLocation’ не вызывался даже после того, как я установил делегат! Что случилось?

Я видел, как этот вопрос часто задавали на форуме разработчиков Apple, и заметил, что большинство из них запрашивали данные о местоположении сразу после запроса разрешения, например:

  locationManager.requestWhenInUseAuthorization ()
locationManager.requestLocation ()
  

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

Не делайте этого:

  функция переопределения viewDidLoad () {
    super.viewDidLoad ()
    locationManager.delegate = self
  
    locationManager.requestWhenInUseAuthorization ()
    // после отображения диалогового окна разрешения программа продолжит выполнение следующей строки до того, как пользователь нажмет «Разрешить» или «Запретить»
    
    // когда вызывается функция requestLocation (), статус остается.неопределенный, поэтому iOS не начнет запрашивать местоположение
    locationManager.requestLocation ()
}

  

Вместо этого сделайте это так:

  функция переопределения viewDidLoad () {
    super.viewDidLoad ()
    locationManager.delegate = self
  
    locationManager.requestWhenInUseAuthorization ()
    // после отображения диалогового окна разрешения программа продолжит выполнение следующей строки до того, как пользователь нажмет «Разрешить» или «Запретить»
    
    // если ранее пользователь давал разрешение на местоположение, то запрашиваем местоположение
    если (CLLocationManager.authorizationStatus () == .authorizedWhenInUse || CLLocationManager.authorizationStatus () == .authorizedAlways) {
        locationManager.requestLocation ()
    }
}

// После того, как пользователь нажмет на «Разрешить» или «Запретить» в диалоговом окне
func locationManager (_ manager: CLLocationManager, didChangeAuthorization status: CLAuthorizationStatus) {
  if (status == .authorizedWhenInUse || status == .authorizedAlways) {
    manager.requestLocation ()
  }
}
  

Не забудьте проверить функцию CoreLocation на реальном устройстве

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

Вы можете изменить координаты местоположения для симулятора, используя Debug > Custom Location .

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

requestLocation () может занять больше времени для получения данных о местоположении

Как упоминалось в этом видео WWDC о CoreLocation (около 11:55), requestLocation () — это удобный метод, предоставляемый Apple, который под капотом запускает startUpdatingLocation () , извлекает данные нескольких местоположений и выбирает наиболее точный для передачи делегату и вызовите stopUpdatingLocation () .Этот процесс может занять до 10 секунд (что примерно соответствует пределу тайм-аута), если он не может решить, какие данные о местоположении лучше всего.

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

Точность

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

  // данные о местоположении с точностью до сотен метров
locationManager.desiredAccuracy = kCLLocationAccuracyHundredMeters
  

Вот список типов точности:

Из документации Apple по желаемой точности, для iOS и macOS значение этого свойства по умолчанию — kCLLocationAccuracyBest . Для watchOS значение по умолчанию — kCLLocationAccuracyHundredMeters ), если вы не установили желаемую точность, значения по умолчанию следующие:

Для iOS и macOS значение этого свойства по умолчанию — kCLLocationAccuracyBest .Для watchOS значение по умолчанию — kCLLocationAccuracyHundredMeters .

Следует отметить, что более высокая точность потребует больше времени для получения данных о местоположении. Использование kCLLocationAccuracyHundredMeters для вызова requestLocation () заняло 1 секунду на моем телефоне, тогда как kCLLocationAccuracyBest заняло 10 секунд.

Я предлагаю использовать наименьшую точность, необходимую вашему приложению (сотни метров обычно достаточно, если ваше приложение не похоже на приложение Waze / Google Maps / Emergency), это может сэкономить время на получение местоположения.

Получение данных о местоположении, когда приложение работает в фоновом режиме

Чтобы ваше приложение могло получать данные о местоположении в фоновом режиме, вам необходимо:

1. Выберите свой проект> Возможности> включите фоновые режимы и отметьте «Обновления местоположения»

2. Всегда запрашивать авторизацию для менеджера CoreLocation

     locationManager.requestAlwaysAuthorization ()
     

   Пользователь должен будет нажать «Всегда разрешать» при появлении запроса на разрешение, а статус авторизации должен быть .авторизован Всегда

3. Начало обновления локации и все!

     locationManager.startUpdatingLocation ()
     

перенаправлений, запросы POST и GET, а также «потерянные» данные

У нас есть веб-приложение, которое должно принимать POST-запросы от клиентов.

Перед этим приложением есть прокси-сервис, независимо от того, какой — сначала мы столкнулись с проблемами в AWS Application Load Balancer, затем я воспроизвел их с помощью NGINX, и он будет «работать» для любой другой прокси-системы.

Помимо проксирования — эта служба также выполняет перенаправление HTTP (80) на HTTPS (443).

Проблема точно проявляется при таком редиректе:

1. клиент отправляет запросов POST через HTTP
2. прокси возвращает 301 или 302 перенаправление на HTTPS
3. затем клиент отправляет запрос через HTTPS, но:
   1. в некоторых случаях этот POST становится GET
   2. или это все равно будет POST , но все его данные будут «потеряны»

Настройка среды тестирования

Для тестирования воспользуемся следующей конфигурацией:

1. NINGX принимает API-запросы
2. NGINX передает через proxy_pass по HTTP серверной службе.
   • для воспроизведения проблемы POST — GET — будет использоваться серверная часть с приложением Go в контейнере Docker
   • для воспроизведения «потерянных» данных и пустого Длина содержимого — скрипт Python будет использоваться для работы в качестве веб-сервера

NGINX

Обычный конфиг — NGINX, слушает на 80, перенаправляет на HTTPS:

 сервер {

    слушать 80;

    server_name dev.poc.example.com;

    расположение / {

        возврат 302 https: //dev.poc.example.com$request_uri;
    }
}
... 

И сервер 443 {} — также обычная конфигурация с proxy_pass на бэкэнд на порту 8081:

 ...
server {

    слушайте 443 ssl;
    имя_сервера dev.poc.example.com;

    ...

    расположение / {

        proxy_pass http: // localhost: 8081;

        proxy_set_header Host $ host;
        proxy_set_header X-Real-IP $ remote_addr;
        proxy_set_header X-Forwarded-For $ proxy_add_x_forwarded_for;
        proxy_set_header Схема X-Forwarded-Proto $;

    }
}
 

Go-приложение в Docker

У нас там несколько контейнеров в стеке, но в настоящее время нас интересует go-queue-consumer с локальным NGINX (вся исходная система все еще находится в состоянии Proof of Concept, так что не стоит задумываться о слишком большом количестве NGINX здесь).

Нас просто интересуют его журналы с методами POST или GET .

Веб-сервер Python

И еще один веб-сервер, который играет роль бэкенда, чтобы увидеть проблему с длиной данных — быстро погуглил скрипт Python:

 #! / Usr / bin / env python3
"" "
Очень простой HTTP-сервер на Python для регистрации запросов
Применение::
    ./server.py [<порт>]
"" "
из http.server импортировать BaseHTTPRequestHandler, HTTPServer
импорт журнала

класс S (BaseHTTPRequestHandler):
    def _set_response (самостоятельно):
        я.send_response (200)
        self.send_header ('Content-type', 'текст / html')
        self.end_headers ()

    def do_GET (сам):
        logging.info ("Запрос GET, \ nPath:% s \ nHeaders: \ n% s \ n", str (self.path), str (self.headers))
        self._set_response ()
        self.wfile.write ("Запрос GET для {}". формат (self.path) .encode ('utf-8'))

    def do_POST (сам):
        content_length = int (self.headers ['Content-Length']) # <--- Получает размер данных
        post_data = себя.rfile.read (content_length) # <--- Получает сами данные
        logging.info ("Запрос POST, \ nPath:% s \ nHeaders: \ n% s \ n \ nBody: \ n% s \ n",
                str (self.path), str (self.headers), post_data.decode ('utf-8'))

        self._set_response ()
        self.wfile.write ("запрос POST для {}". формат (self.path) .encode ('utf-8'))

def run (server_class = HTTPServer, handler_class = S, порт = 8081):
    logging.basicConfig (уровень = logging.INFO)
    server_address = ('', порт)
    httpd = server_class (server_address, handler_class)
    протоколирование.info ('Запуск httpd ... \ n')
    пытаться:
        httpd.serve_forever ()
    кроме KeyboardInterrupt:
        проходить
    httpd.server_close ()
    logging.info ('Остановка httpd ... \ n')

если __name__ == '__main__':
    из sys import argv

    если len (argv) == 2:
        запустить (порт = int (argv [1]))
    еще:
        бег () 

Примеры: воспроизвести проблему

Данные POST потеряны после перенаправления

Первое, с чем мы столкнулись, это то, что после перенаправления HTTP на HTTPS наши POST-запросы теряют свои данные.

Для его воспроизведения воспользуемся сценарием Python, упомянутым выше.

Запустите его на 8081 порт:

root @ ip-10-0-15-118: / home / admin # ./test_post.py 8081

INFO: root: запуск httpd ...

И запустите curl с POST и некоторыми данными в --data :

curl -vL -X POST http://dev.poc.example.com/ -d "param1 = value1 & param2 = value2"

...

* Попытка 52. ***. ***. 224: 80 ...

...

> Content-Length: 27

...

...

...

> POST / HTTP / 1.1

> Хост: dev.poc.example.com

> User-Agent: curl / 7.67.0

> Принять: * / *

>

* Отметить пакет как не поддерживающий многоразовый

...

Давайте посмотрим, что здесь происходит:

1. запрос POST отправляется через HTTP, Content-Length: 27
2. 302 редирект выдан на HTTPS
3. и запрос POST отправляется через HTTPS, Content-Length: 173

В логах NGINX мы видим стандартный HTTP POST :

...

==> /var/log/nginx/dev.poc.example.com-error.log <==

2019/11/23 09:52:41 [ошибка] 19793 # 19793: * 51100 восходящий поток преждевременно закрытое соединение при чтении заголовка ответа из восходящего потока, клиент: 194. ***. ***. 26, сервер: dev.poc.example.com, запрос: «POST / HTTP / 1.1», исходящий: «http: / /127.0.0.1:8081/ ", хост:" dev.poc.example.com "

==> /var/log/nginx/dev.poc.example.com-access.log <==

194. ***. ***. 26 - - [23 / ноя / 2019: 09: 52: 41 +0000] "POST / HTTP / 1.1 "502 173" - "" локон / 7,67,0 "

...

Но давайте посмотрим на stderr запущенного Python-сервера:

...

Исключительная ситуация во время обработки запроса от ('127.0.0.1', 38224)

Traceback (последний вызов последним):

Файл "/usr/lib/python3.5/socketserver.py", строка 313, в _handle_request_noblock

self.process_request (request, client_address)

Файл "/usr/lib/python3.5/socketserver.py", строка 341, в process_request

self.finish_request (request, client_address)

Файл "/usr/lib/python3.5/socketserver.py", строка 354, в finish_request

self.RequestHandlerClass (request, client_address, self)

Файл "/ usr / lib / python3.5 / socketserver.py ", строка 681, в __init__

self.handle ()

Файл" /usr/lib/python3.5/http/server.py ", строка 422, в дескрипторе

self. handle_one_request ()

Файл "/usr/lib/python3.5/http/server.py", строка 410, в handle_one_request

method ()

File "./test_post.py ", строка 22, в do_POST

content_length = int (self.headers ['Content-Length']) # <--- Получает размер данных

TypeError: аргумент int () должен быть строкой , Байтовый объект или число, а не NoneType

...

Обратите внимание на эти строки:

…
content_length = int (self.headers [‘ Content-Length ‘])
TypeError: аргумент int () должен быть строкой, байтовым объектом или числом, а не « NoneType ‘

E.g., приложение получило пустое / отсутствующее поле Content-Length .

Тем не менее, если отправить новый запрос напрямую через HTTP (с отключенным перенаправлением на NGINX) или через HTTPS - все будет работать, как и ожидалось:

curl -vL -X POST https://dev.poc.example.com/ -d "param1 = value1 & param2 = value2"

...

> POST / HTTP / 1.1

> Host: dev.poc. example.com

> User-Agent: curl / 7.67.0

> Accept: * / *

> Content-Length: 27

> Content-Type: application / x-www-form-urlencoded

>

* загрузка полностью отправлена: 27 из 27 байтов

* Отметить пакет как не поддерживающий многоразовый

<Сервер: nginx / 1.10.3

<Дата: Сб, 23 ноя 2019 09:55:07 GMT

< Соединение: keep-alive

<

* Соединение № 0 с хостом dev.poc.example.com осталось неизменным

Запрос POST для /

И стандартный вывод приложения Python:

...

ИНФОРМАЦИЯ: root: запрос POST,

Путь: /

Заголовки:

Хост: dev.poc.example.com

X-Real-IP: 194. ***. ***. 26

X-Forwarded-For: 194. ***. ***. 26

X-Forwarded-Proto : Https

Подключение: закрыть

Content-Length: 27

User-Agent: curl / 7.67.0

Accept: * / *

Content-Type: application / x-www-form-urlencoded

Body :

param1 = value1 & param2 = value2

127.0.0.1 - - [23 ноября / 2019 09:55:07] «POST / HTTP / 1.0» 200 -

А теперь перейдем к следующей второй задаче.

A POST стал GET

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

Давайте посмотрим, как наш запрос POST превратится в ... запрос GET !

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

завиток

Выполните запрос с типом POST через HTTP с -L , чтобы выполнить перенаправление на HTTPS.

В этом случае мы используем не скрипт Python, который использовался выше, а наш настоящий бэкэнд-контейнер Docker, чтобы продемонстрировать его работу и проверить его логи.

Сами данные, как и любые ошибки, здесь не имеют значения - нас интересуют только используемые методы запросов - POST и GET .

curl -vL -X POST http: // dev.poc.example.com/skin/api/v1/receipt -d "{}"

...

> POST / skin / api / v1 / чек HTTP / 1.1

> Хост: dev.poc.example. com

> User-Agent: curl / 7.67.0

> Accept: * / *

>

* Отметить пакет как не поддерживающий многоразовый

<Дата: Сб, 23 ноя 2019, 10:07:37 GMT

<

* Соединение №1 с хостом dev.poc.example.com оставлен без изменений

{"message": "Ошибка проверки: невозможно проанализировать тело json"}

Еще раз - не смотрите здесь на ошибки - вместо этого давайте обратимся к журналам NGINX:

==> /var/log/nginx/dev.poc.example.com-access.log <==

194. ***. ***. 26 - - [23 ноября 2019 г .: 10:07 : 37 +0000] "POST / skin / api / v1 / квитанция HTTP / 1.1" 400 58 "-" "curl / 7.67.0"

Кажется, здесь все хорошо? Отправлено POST - получено POST .

Просто для проверки - давайте запустим curl с явно указанным типом GET , чтобы увидеть ответ серверной части и журналы NGINX в этом случае:

curl -L -X GET http://dev.poc.example.com/skin/api/v1/receipt -d "{}"

Страница 404 не найдена

И журналы NGINX с этим GET :

==> /var/log/nginx/dev.poc.example.com-access.log <==

194. ***. ***. 26 - - [23 ноября 2019 г .: 10:07 : 37 +0000] "POST / skin / api / v1 / получение HTTP / 1.1 "400 58" - "" curl / 7.67.0 "

194. ***. ***. 26 - - [23 / ноя / 2019: 10: 09: 57 +0000]" GET / skin / api / v1 / квитанция HTTP / 1.1 "404 18" - "" curl / 7.67.0 "

Все хорошо, вроде все правильно - никаких проблем, а?

Почтальон

А теперь давайте воспользуемся Postman для отправки того же запроса на ту же конечную точку: POST через HTTP для запуска и выполнения перенаправления на HTTPS:

А?…

И - теперь давайте посмотрим логи NGINX:

==> / var / log / nginx / dev.poc.example.com-access.log <==

194. ***. ***. 26 - - [23 / ноя / 2019: 10: 07: 37 +0000] "POST / skin / api / v1 / получение HTTP / 1.1 "400 58" - "" curl / 7.67.0 "

194. ***. ***. 26 - - [23 / ноя / 2019: 10: 09: 57 +0000]" GET / skin / api / v1 / Receiver HTTP / 1.1 "404 18" - "" curl / 7.67.0 "

194. ***. ***. 26 - - [23 / ноя / 2019: 10: 11: 44 +0000] "GET / skin / api / v1 / квитанция HTTP / 1.1" 404 18 "http://dev.poc.example.com/skin/api/v1/receipt" "PostmanRuntime / 7.19.0"

Errr…

Что?!?

Но я отправил явно указанный запрос POST ?

Еще раз:

1. сделать запрос с curl , HTTP => HTTPS редирект выдан, POST в журналах - все хорошо
2. делает запрос с помощью Postman, HTTP => HTTPS редирект выдан, но GET в логах - WTF ???

POST, GET и «потерянные» данные

Что ж, теперь мы можем понять, куда ушли наши данные - потому что наш POST стал GET .

Основная причина, перенаправления 3xx и HTTP RFC

На самом деле обе проблемы вызваны одной и той же причиной.

Давайте начнем наше расследование с чтения описания кода 301 в RFC 2616 - https://tools.ietf.org/html/rfc2616#section-10.3.2, особенно его Note :

Примечание. При автоматическом перенаправлении запроса POST после получения
кода состояния 301, некоторые существующие пользовательские агенты HTTP / 1.0
ошибочно изменят его на запрос GET .

То есть, некоторые клиенты после отправки POST и получения 301 - изменят тип запросов на GET .

Но это только начало!

При дальнейшем чтении, в описании кода 302 в том же RFC 2016 - https://tools.ietf.org/html/rfc2616#section-10.3.3, мы увидим еще одну Note :

Примечание. RFC 1945 и RFC 2068 указывают, что клиенту не разрешено
изменять метод в перенаправленном запросе.Однако большинство
существующих реализаций пользовательского агента обрабатывают 302, как если бы это был ответ 303
, выполняет GET для значения поля Location независимо от
исходного метода запроса . Коды состояния 303 и 307
были добавлены для серверов, которые хотят однозначно указать, какой тип
реакции ожидается от клиента.

RFC 1945 около 3хх редирект - https: // tools.ietf.org/html/rfc1945#section-9.3

RFC 2068 около 3хх редирект - https://tools.ietf.org/html/rfc2068#section-10.3.2

То есть, RFC 1945 и RFC 2068 заявляют, что у клиента нет типа изменения для перенаправленного запроса, но большинство из них будет рассматривать код 302 как… 303 !

Перейдем к следующей части и прочитаем о коде 303 - https://tools.ietf.org/html/rfc2616#section-10.3.4:

Ответ на запрос можно найти под другим URI, и
СЛЕДУЕТ получить с помощью метода GET для этого ресурса.

То есть, когда клиент считает, что он получил код 303 - он всегда выполнит GET .

Итак, что мы видели в случае с Postman (и нашими клиентами мобильных приложений, в которых мы впервые столкнулись с этой проблемой):

1. клиент выполняет POST по HTTP
2. получает перенаправление на HTTPS с 301 или 302
3. считает его 303
4. и изменяет тип своего собственного запроса, отправленного по HTTPS, с на GET , «теряя» все исходные данные

Решение

Я нашел решение после прочтения документации Mozilla (хотя в RFC 2016 Notes для 302 была подсказка), в которой говорится о перенаправлениях 301 и 302 :

Поэтому рекомендуется устанавливать код 302 только в качестве ответа для методов GET или HEAD , а для использовать временное перенаправление 307 вместо , поскольку в этом случае изменение метода явно запрещено.

Хорошо - давайте обновим наш NGINX и изменим код 302 на 307 :

 сервер {

    слушать 80;
...
    расположение / {

        # return 302 https: //dev.poc.example.com$request_uri;
        возврат 307 https: //dev.poc.example.com$request_uri;
    }
}
... 

Перезагрузить конфиги и повторить запрос от curl :

curl -L -X POST http://dev.poc.example.com/skin/api/v1/receipt -d "{}"

{"message": "Ошибка проверки: поля 'hardware_id' и 'квитанция 'Обязательны "}

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

Редирект сработал, получен запрос POST .

И журнал NGINX:

==> /var/log/nginx/dev.poc.example.com-access.log <==

194. ***. ***. 26 - - [23 ноября 2019 г .: 10:07 : 37 +0000] "POST / skin / api / v1 / квитанция HTTP / 1.1" 400 58 "-" "curl / 7.67.0"

194. ***. ***. 26 - - [23 / ноя / 2019: 10: 09: 57 +0000] "GET / skin / api / v1 / receive HTTP / 1.1" 404 18 "-" "curl / 7.67.0"

194. ***. ***. 26 - - [23 / ноя / 2019: 10: 11: 44 +0000] «GET / skin / api / v1 / получение HTTP / 1.1 "404 18" http://dev.poc.example.com/skin/api/v1/receipt "" PostmanRuntime / 7.19.0 "

194. ***. ***. 26 - - [23 / Ноя / 2019: 10: 35: 51 +0000] "POST / skin / api / v1 / квитанция HTTP / 1.1" 422 81 "-" "curl / 7.67.0"

194. ***. ***. 26 - - [23 / ноя / 2019: 10: 36: 00 +0000] "POST / skin / api / v1 / квитанция HTTP / 1.1" 422 81 "-" "curl / 7.67.0"

Повторите запрос от Почтальона:

Журналы NGINX:

==> /var/log/nginx/dev.poc.example.com-access.log <==

194.***. ***. 26 - - [23 / ноя / 2019: 10: 07: 37 +0000] "POST / skin / api / v1 / квитанция HTTP / 1.1" 400 58 "-" "curl / 7.67. 0 "

194. ***. ***. 26 - - [23 / ноя / 2019: 10: 09: 57 +0000]" GET / skin / api / v1 / квитанция HTTP / 1.1 "404 18" - "" Curl / 7.67.0 "

194. ***. ***. 26 - - [23 / ноя / 2019: 10: 11: 44 +0000]" GET / skin / api / v1 / квитанция HTTP / 1.1 "404 18" http://dev.poc.example.com/skin/api/v1/receipt "" PostmanRuntime / 7.19.0 "

194. ***. ***. 26 - - [23 / Ноя / 2019: 10: 35: 51 +0000] "POST / skin / api / v1 / квитанция HTTP / 1.1" 422 81 "-" "curl / 7.67.0 "

194. ***. ***. 26 - - [23 / ноя / 2019: 10: 36: 00 +0000]" POST / skin / api / v1 / квитанция HTTP / 1.1 "422 81" - "" Curl / 7.67.0 "

194. ***. ***. 26 - - [23 / ноя / 2019: 10: 37: 57 +0000]" POST / skin / api / v1 / квитанция HTTP / 1.1 "422 81" http://dev.poc.example.com/skin/api/v1/receipt "" PostmanRuntime / 7.19.0 "

Все работает, как положено.

AWS Application Load Balancer перенаправляет

К сожалению, я не смог найти, как установить 307 при использовании AWS ALB:

Вот и все, ребята!

Полезные ссылки

Те проблемы на других сайтах

Помогло найти решение

Также опубликовано на Medium.

Библиотека запросов Python (Руководство) - Real Python

Смотреть сейчас В этом руководстве есть связанный видеокурс, созданный командой Real Python. Посмотрите его вместе с письменным руководством, чтобы углубить свое понимание: Создание HTTP-запросов с помощью Python

запросов Библиотека де-факто является стандартом для выполнения HTTP-запросов в Python. Он абстрагируется от сложностей выполнения запросов за красивым и простым API, так что вы можете сосредоточиться на взаимодействии со службами и использовании данных в вашем приложении.

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

Из этого руководства вы узнаете, как:

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

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

Теперь, когда это решено, давайте углубимся и посмотрим, как вы можете использовать запросов в своем приложении!

Пройдите тест: Проверьте свои знания с помощью нашей интерактивной викторины «HTTP-запросы с библиотекой запросов».