Просканирована новая метка как убрать
Перейти к содержимому

Просканирована новая метка как убрать

  • автор:

Метка NFC на телефоне Samsung — что такое как отключить?

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

Скажу сразу: на данный момент реальной пользы от NFC почти нет. Реально польза ощутима на западе, например в Америке, у нас пока бесконтактная оплата — пользуется низкой популярностью. Поэтому лучше отключить, этим вы кстати сэкономите заряд батареи.

Тип метки NFC не поддерживается — отключение:

  1. Откройте стандартные Настройки > выберите Еще.
  2. Нажмите Беспроводные сети > Передача файлов и данных.
  3. Деактивируйте NFC, передвинув ползунок в положение выкл.

Дополнительно удалось выяснить:

  1. NFC — технология передачи данных, имеет небольшой радиус действия (10 см), низкую скорость передачи. Обмен данными может происходить между телефоном и специальным устройством, например терминал оплаты. Часто используется для оплаты товара в магазине или услуги.
  2. Каждое устройство, которое имеет метку NFC — может подключиться к вашему смартфону, при условии что на нам присутствует модуль NFC. Кроме платежных терминалов данную метку могут иметь такие девайсы как турникеты в метро. Простыми словами — именно эта метка нужна, чтобы телефон смог определить сервис, а также сумму, какую необходимо оплатить.
  3. С метками NFC на телефонах Samsung, или других производителей — может происходить ошибка. Одна из частых — когда тип метки не поддерживается. Основная причина — неизвестная метка устройства, к которому подносится телефон, который просто не может определить метку. Исправить данную ситуацию часто непросто, например может потребоваться перепрограммировать смартфон, заменить чип NFC, лучше с такой проблемой обратиться в сервисный центр.

Надеюсь данный материал оказался полезным. Успехов.

Что такое NFC метки. Где применяются и используются

Технология NFC (Near Field Communication) сегодня часто используется во всех сферах жизни современного человека. С ее помощью можно выполнить как ряд базовых действий — оплатить проезд в метро, покупки в магазинах, так и упростить процесс развлечений, например, одним движением скачать книгу. Некоторые особо продвинутые бизнесмены даже оснащают свои визитки NFC метками.

Принцип работы

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

Чтобы запитать метку, применяется электромагнитная индукция. Практически аналогичная технология применяется для работы зарядных устройств типа A4WP. Здесь за магнитное поле отвечает «активное устройство» — например, смартфон. Поле появляется за счет небольшой катушки с проводом, производящей магнитные поля. Они находятся перпендикулярно потоку переменного тока в проводе.

При этом регулировать силу магнитного поля можно, изменяя количество витков на катушках или увеличивая силу тока. Поскольку такая работа требует достаточно много энергии, нельзя допускать, чтобы количество элементов, потребляющих ее, было большим. Именно поэтому NFC работает лишь на расстоянии нескольких сантиметров. В отличие от Bluetooth или Wi-Fi, которые позволяют не подходить к раздающему сигнал устройству близко, пользоваться NFC можно только на небольшом расстоянии.

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

Виды меток NFC

Во всем мире NFC метки работают по стандарту ISO 14443, который имеет два типа — А и B. Именно этот стандарт используется для работы для бесконтактных смарт-карт, позволяющих оплачивать проезд. Такая стандартизация и распространенность технологии по всему миру позволяет использовать NFC с различными девайсами.

Существуют метки четырех типов, которые отличаются лишь скоростью передачей и объемом данных, который они могут хранить. У меток 1-го и 2-го типов 48 байт и 2 килобайта памяти, которые они могут передавать на установленной скорости 106 кбит/с. Сравнивая с показателями современных технологий, скорость передачи данных может показаться смехотворно низкой. Однако нужно понимать, что метки используются для конкретных задач — выполнить несложное действие. Например, метка может отправить пользователя на определенный сайт, а основную работу с ресурсом человек будет выполнять на своем мощном смартфоне. Кроме того, метки разрабатываются так, чтобы можно было их использовать несколько раз, перезаписывая информацию.

3-й тип меток работает по стандарту Sony Felica. Они могут передавать данные на 212 кбит/с, поэтому метки берут для выполнения более сложных задач. Кроме того, метки не перезаписываются, что делает их менее привлекательными для выполнения простой работы. Метки 4-го типа считаются самыми мощными, хотя они также защищены от перезаписи. Такие метки передают данные на скорости от 106 кбит/с до 424 кбит/с, в них доступно 32 кбайта памяти для записи информации.

Использование NFC меток

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

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

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

Где можно купить метки

Прежде всего, nfc метки купить можно на различных китайских сайтах в разделе «гаджеты и аксессуары». Их продают небольшими партиями (по 10 штук), однако можно найти выгодные варианты по 100 и больше меток. Важно прочитать всю информацию об активности меток и способе их программирования, а также совместимости.

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

Управление индексированием в Google Search Console — обзор всех возможностей

Управление индексированием в Google Search Console — обзор всех возможностей

Search Console — основной опорный инструмент для продвижения сайтов в Google (и не только). По функциональности консоль может уступать некоторым более продвинутым SEO-инструментам, но у нее есть три ключевых преимущества: она бесплатная, интуитивно понятная и самое важное – предоставляет данные прямо от Google. Через GSC, не опираясь на гипотезы, можно узнать, как алгоритмы оценивают ваш сайт, при этом все рекомендации по улучшению технической части вебмастер получает напрямую от первого лица, т. е. Google. И в этом плане Search Console вряд ли когда-нибудь превзойдет какой-либо коммерческий SEO-инструмент.

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

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

Работа с запросами, безусловно, важна для эффективного продвижения сайта в поиске, но семантика – далеко не все, на чем держится успех в SEO. Прежде чем страницы начнут ранжироваться по релевантным запросам, они должны быть правильно просканированы и проиндексированы поисковыми роботами. Это очень важный процесс, и здесь Google Search Console является самым надежным информатором и техническим помощником. В вебмастерке всегда можно узнать, какие из документов были проиндексированы, а какие нет, когда совершался последний обход сайта, на каких страницах есть проблемы и как их лучше всего устранить по мнению Google. Об этих и других функциях индексирования в GSC – рассказываем в представленном материале.

Отслеживаем индексацию страниц и исправляем ошибки

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

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

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

Чтобы проверить, имеются ли на сайте проблемы с индексацией, откройте Google Search Console и перейдите на вкладку Индекс → Покрытие – здесь будет доступен статус всех страниц сайта.

В первую очередь обратите внимание на разделы «Ошибка» и «Без ошибок, есть предупреждения», чтобы выяснить, что не так с указанными страницами и как устранить имеющиеся проблемы.

Ошибки. Типичные проблемы и как их исправить

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

Под графиком в разделе «Сведения» система уведомляет, какая именно проблема с индексированием присутствует на сайте, например:

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

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

URL-адреса недоступны для индексирования

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

Первое, что нужно проверить в этом случае: действительно ли вы хотите, чтобы страница отображалась в поиске. Если речь идет о URL, который не должен индексироваться – такие страницы есть на любом сайте и о них можно почитать здесь – тогда нужно отозвать свой запрос на обход, чтобы Google прекратил безуспешные попытки отправить страницу в индекс. Наиболее вероятная причина подобных ошибок заключается в том, что нежелательный URL-адрес по недосмотру был добавлен в карту сайта. В этом случае необходимо просто отредактировать файл Sitemap.xml, удалив из него проблемный URL-адрес (подробнее об этом – ниже).

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

Неиндексируемая страница закрыта директивой noindex. Решение: удалить тег noindex из HTML-кода или из заголовка ответа HTTP X-Robots-Tag.

Страница запрещена к индексированию в robots.txt. Решение: проверить файл robots.txt специальным инструментом Google, после чего удалить или изменить все ненужные запрещающие директивы и исправить найденные ошибки.

При обращении к URL возникает ошибка 404. Подобное происходит, когда страница удалена или изменен ее изначальный URL-адрес. Решение: восстановить исходный URL или настроить 301-редирект на новую версию страницы.

URL возвращает ложную ошибку (soft 404). Такое происходит, когда страница физически существует (сервер помечает ее статусом OK), но Google решил, что URL имеет статус 404 (страница не найдена). Как правило, это происходит при отсутствии контента на странице (или его незначительности), а также из-за манипуляций с редиректами, когда внутренняя переадресация ведется на тематически НЕблизкую страницу. Решение: проверить страницу на предмет «тонкого» контента или нерелевантных редиректов.

URL возвращает ошибку 401 (неавторизованный запрос). Это значит, что робот Google не может получить доступ к нужной странице из-за запрашиваемой авторизации. Решение: отменить требование авторизации либо разрешить Googlebot доступ к странице.

URL возвращает ошибку 403. Googlebot выполняет вход на сервер, но ему не предоставлен доступ к контенту. Решение: если вы хотите, чтобы страница попала в индекс, откройте к ней доступ анонимным посетителям.

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

Наличие ошибок переадресации

Иногда нужная страница не может быть проиндексирована по причине некорректно работающего редиректа. Выше мы уже описали, как это происходит в случае с перенаправлением на нерелевантную страницу (ошибка soft 404), но на практике существуют и другие ошибки переадресации. Страница может не попадать в индекс по причине слишком длинной связки перенаправлений, из-за циклических редиректов или битых URL в цепочке переадресаций.

Решение: проверьте URL на предмет некорректно работающих 301- или 302-редиректов и примите меры по их отладке.

Проблемы на стороне хостера

Ошибка 5xx возникает, когда поисковым роботам Google не удается получить доступ к серверу. Возможно, сервер вышел из строя, истекло время ожидания или он был недоступен, когда Googlebot проводил обход сайта (скорее всего, причина именно в этом).
Решение: проверьте URL с помощью инструмента «Проверка URL-адреса», отображается ли ошибка в настоящее время. Если сервер в порядке, отправьте страницу на переобход, в противном случае внимательно ознакомьтесь с тем, что предлагает Google для решения этой проблемы или свяжитесь со своим хостинг-провайдером.

Без ошибок, есть предупреждения

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

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

Проиндексировано, несмотря на блокировку в файле robots.txt

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

Чтобы гарантированно исключить попадание нежелательных страниц в индекс, используют другие механизмы: добавление noindex в HTML-код страницы или настройку HTTP-заголовка X-Robots-Tag. Запреты в robots.txt поисковик же расценивает исключительно как рекомендации: он не будет сканировать страницу, отклоненную в роботс, во время обхода сайта, но эта же страница может быть проиндексирована, если на нее ведут другие ссылки. Отсюда следует один очень важный момент: из-за запрета в robots.txt, страницы могут попадать в индекс в неполной версии, поскольку поисковые роботы смогли просканировать лишь отдельные фрагменты «закрытого» документа.

Как решить такую проблему? В первую очередь следует внимательно изучить все «желтые» URL и определиться, нужно ли блокировать конкретную страницу или нет. Если вы уверены, что странице не место в индексе – ограничиваем к ней доступ поисковых ботов с помощью noindex или X-Robots-Tag. От страниц, не представляющих ценности ни для пользователей, ни для поисковых лучше избавиться вовсе. Как правильно удалять страницы из индекса Google и Яндекса без вреда для SEO – читайте в отдельной статье.

Страница проиндексирована без контента

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

Чтобы устранить эту проблему, необходимо внимательно ознакомиться со всеми рекомендациями в разделе «Покрытие» и внедрить предложенные правки. В некоторых случаях может потребоваться дополнительная проверка кода страницы, поскольку отчеты Search Console далеко не всегда способны обнаруживать недочеты, связанные с указанной проблемой. Более глубокий технический SEO-аудит, проведенный с использованием специальных программ, поможет обнаружить битые изображения или видео, повторяющиеся заголовки и метаописания, проблемы с локализацией и другие недочеты, из-за которых страницы могут индексироваться без контента.

Исключено

Google Search Console также уведомляет о страницах, которые не попали в индекс, но присутствуют на сайте. Эта информация отображается в красном блоке «Исключено».

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

  • обход страниц запрещен через noindex или X-Robots-Tag;
  • прописаны запрещающие директивы в файле robots.txt;
  • страница является неканонической, т. е. дублем, правильно размеченным атрибутом rel=«canonical».

Но иногда попадание страниц в блок «Исключено» может свидетельствовать о наличии технических проблем или недоработок, например:

  • страница не проиндексирована из-за неавторизованного запроса (ошибка 401), переноса в другое место или удаления (404), запрета доступа (403), ложной ошибки (soft 404);
  • присутствие на странице некорректно настроенного редиректа;
  • страница является дублем, без указания канонического URL.
  • Google выбрал канонический вариант страницы не таким, как его указал вебмастер (соответственно, из индекса вылетели важные URL).

Таким образом, отслеживая все, что попадает в блок «Исключено», можно получать сигналы о недоработках в техническом SEO и своевременно устранять недочеты. Отдельно отметим, что сюда иногда залетают и полностью «здоровые» страницы, например, те, что были просканированы, но пока не попали в индекс. Отправлять на принудительную переиндексацию такие URL не нужно.

Ускоряем индексирование приоритетных страниц

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

Делайте запрос на переиндексацию каждый раз после публикации новой страницы или существенного обновления старого контента. Для этого нужно ввести исходный адрес в верхнее поле поиска Google Search Console и нажать Enter. Через несколько секунд система предоставит информацию о текущем статусе URL, после нужно нажать «Запросить индексирование».

Инструмент быстро просканирует страницу на предмет проблем, и при отсутствии таковых добавит URL в очередь на приоритетный обход. Запрос на ускоренную индексацию или переобход большого количества страниц делают через отправку файла Sitemap (об этом – в следующем пункте).

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

Оптимизируем индексацию с помощью Sitemap

Карта сайта — это специальный файл (sitemap.xml), который размещают в корневой папке, чтобы помочь поисковым роботам Google лучше ориентироваться в структуре ресурса. В хml-файле содержится перечень всех URL сайта с информацией об их последнем обновлении и указанием, какие из страниц нужно сканировать в первую очередь. Таким образом хml-карта упрощает краулерам поиск URL для индексирования, выступая в роли вспомогательной навигации по сайту.

Файл sitemap.xml можно создать одним из нескольких способов:

  • Написать вручную, в соответствии с правилами синтаксиса (сегодня почти никто так уже не делает).
  • Сгенерировать автоматически при помощи специальных программ или онлайн-сервисов.
  • Воспользоваться встроенным функционалом некоторых CMS (например, такая опция предусмотрена в Битрикс).
  • Сгенерировать и настроить XML-карту при помощи WP-плагинов (эта опция доступна в двух популярных SEO-плагинах: All in One SEO и Yoast).

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

Чтобы передать созданную карту сайта в Search Console и/или проверить ее на наличие ошибок, достаточно перейти в раздел «Файлы Sitemap», ввести путь доступа к xml-файлу и нажать «Отправить».

В плане технических требований файл Sitemap должен:

  • соответствовать правилам синтаксиса (ошибки в файле можно проверить специальными валидаторами);
  • иметь размер, не превышающий 50 МБ;
  • содержать не более 50 000 URL-адресов, а если количество URL на сайте превышает указанный лимит, необходимо добавить несколько файлов sitemap.xml.

Без Sitemap содержимое сайта все равно будет попадать в индекс. В этом случае Google станет самостоятельно сканировать URL и проверять их на наличие обновлений, но он будет делать это так часто и в такой приоритетности URL, как посчитает нужным. Очевидно, что это не лучшим образом отразится на скорости индексирования важных страниц. В то же время возлагать на sitemap большие ожидания тоже не стоит. Карта сайта – это в первую очередь рекомендация, которую поисковик может брать во внимание, а может и не учитывать.

Так ли важна карта сайта?

С учетом всего вышесказанного может возникнуть вопрос: нужна ли вообще карта сайта? Ответ однозначный: да нужна. Хотя Google утверждает, что относительно небольшим сайтам (до 500 страниц) можно пренебречь Sitemap, этого лучше не делать. В первую очередь потому что любой молодой проект по умолчанию имеет слабый ссылочный профиль, а этот фактор важен в том числе и для краулеров. Поэтому, если на сайт ведет мало ссылок, его сложнее найти – отсюда проблемы с органической индексацией.

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

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

Для каких сайтов Sitemap является обязательным

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

  • Ресурсы, у которых много страниц (500+ URL).
  • Сайты с большим архивом документов, иерархически не связанных друг с другом.
  • Крупные сайты с логичной, но сложноорганизованной структурой.
  • Площадки с большой долей мультимедийного контента (видео/изображения).
  • Часто обновляемые ресурсы (магазины, новостники и т. д.).

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

Отслеживаем индексирование AMP-страниц

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

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

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

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

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

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

Через трудности и ошибки к безупречному интерфейсу кассы самообслуживания

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

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

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

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

Касса самообслуживания — настоящий вызов для проектировщика интерфейсов.

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

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

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

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

Процесс сканирования в нашем интерфейсе:

Разработку кассы самообслуживания мы начали в середине 2013 года. Несмотря на вышедший за месяц до начала разработки нашей кассы самообслуживания iOS7 мы решили не гнаться за трендами и не делать интерфейс кассы очень плоским. Связано это с тем, что должно пройти в время прежде чем простой прямоугольник без легких градиентов и скруглений будет восприниматься большинством пользователей как кнопка. Касса самообслуживания — это система для широкой аудитории, поэтому старое-доброе (но все же не очень старое) здесь лучше.

Кроме того мы:
  • Отказались от видео
    Гипнотический эффект зацикленного видео заставляет новичков “залипать” даже над простой задачей, опытным же пользователей постоянно крутящееся на экране видео совсем не нужно. Тут два варианта: либо у опытного покупателя разовьется баннерная слепота, тогда ему будет все равно, либо раздражение от такой подсказки будет только расти.
  • Отказались от звука
    Остров самообслуживания в супермаркете, например, в Лондоне похож на восточный базар — кассы из разных углов выкрикивают одинаковые фразы. В итоге возникает эффект, описанный в экспериментах американского психолога Энн Трисман — подача одинаковой информации в разные каналы с задержкой заставляет внимание скакать между этими каналами. Нам же хотелось, чтобы покупатели могли спокойно совершить покупку и их бы ничего не отвлекало.
  • Убрали виртуальный чек
    На других кассах самообслуживания треть экранного пространства занимает список добавленных покупателем товаров.
    При этом на обычной кассе покупатели могут следить за кассиром через крошечную щелку — дисплей покупателя. Часто это небольшой монохромный экран с двумя строчками, на которых показывается последний товар, его цена и итоговая сумма. И в общем-то покупателям этого обычно достаточно. Так почему бы не оставить такое же представление для самостоятельного сканирования, отдав основную площадь на контекстно-возникающие подсказки?
  • Двойное сканирование
    В силу особенностей весового контроля товаров на кассе самообслуживания будет лучше, если покупатель будет сканировать и класть товары на весовую платформу по-одному. Как быть, если покупатель, просканировав один товар, пытается просканировать еще один? В других кассах эта ситуации решена так: при попытке просканировать второй товар сканер просто молчит. Не один раз я видел, как такое отсутствие обратной связи заставляло покупателей в течение десятков секунд крутить товар над сканером, ожидая заветного пика.

Какой же из этих шагов привел нас к самым большим проблемам после запуска? Уверен, многие из вас сейчас подумали об отказе от звука или чека. Нет, основные проблемы не там. И совсем не в отсутствии видео. Самым неудачным из этих решений было текущее решение с двойным сканированием.

В чем же его проблема?

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

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

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

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

В первоначальном варианте было сделано вот так:

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

Естественно подсказку пришлось переделать, заодно показав покупателю где же точно нужно проводить карту.

Приведу пару примеров проблем, с которыми мы сейчас работаем.

Вот экран выбора пакетов:

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

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

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

  • интерфейс
  • касса самообслуживания
  • SCO
  • self checkout
  • Блог компании Crystal Service Integration
  • Интерфейсы
  • Usability

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *