Спросите SMXperts: последние в передовой технической SEO

1. Мишель Роббинс
2. Рассвет андерсон
3. Бастиан Гримм
4. Брайан Вайс
5. Есть вопрос, который мы не затронули?

Серия Ask the SMXpert продолжает сегмент вопросов и ответов (Q & A), проводимый во время сеансов в Search Marketing Expo (SMX) Запад 2018.

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

Мишель Роббинс

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

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

Рассвет андерсон

Слайд-колода: Некоторые текущие проблемы с голосовым и разговорным поиском

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

Рассвет: Хотя поисковые системы утверждают, что распознают голоса и могут отвечать на вопросы о понимании на страницах Википедии, это автоматически не означает реального «понимания» естественного языка. Безусловно, существуют определенные проблемы в удовлетворении информационных потребностей пользователей с помощью этой технологии.

Прошлым летом мне посчастливилось посетить раз в два года Европейскую летнюю школу по поиску информации в Барселоне. Лекции читали исследователи из ведущих университетов и коммерческих организаций, таких как Facebook, Bloomberg, Amazon и, что важно, по этой теме, Google.

Одним из лекторов был Энрике Альфонсека, который является членом исследовательской группы по поисковому диалогу в Google Цюрихе и одним из исследователей, занимающихся некоторыми хорошо известными документами для разговорного поиска и обработки естественного языка.

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

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

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

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

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

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

Вопрос: Что делает голосовой поиск сложной задачей?

Рассвет: Есть много причин и областей вокруг голосового поиска, которые делают его сложным.

Есть еще много проблем с обработкой естественного языка, таких как использование местоимений (он, она, они, они и т. Д.) В разговорных разговорах. Такое отсутствие понимания представляется особенно проблематичным для многоуровневых вопросов, когда пользователь хочет продолжать разговор или задавать вопросы и ожидает, что помощник (устройство) запомнит, к кому относится каждое местоимение.

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

Вопрос: Как насчет перефразирования в голосовом поиске, чтобы предоставить хотя бы один ответ «рядом» с запросом пользователя?

Рассвет: Энрике Альфонсека из группы по поисковому диалогу Google объяснил с помощью голосового поиска, что при получении релевантного результата «перефразирование» (переформулировка запроса, произнесенного пользователем) не производится.

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

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

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

Например, «кошка» может означать «фотографии кошек», «типы кошек» и так далее. С помощью голосового поиска это невозможно; может быть только один, и он должен быть правильным.

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

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

Бастиан Гримм

Слайд-колода: Как быстро достаточно быстро? Оптимизация производительности следующего поколения - выпуск 2018 года

Вопрос: Каковы ваши рекомендации относительно надежного набора показателей, выходящих за рамки общеизвестных PageSpeed ​​Insights? Доступно большое разнообразие от времени до первого байта страницы, загруженной до измерений интерактивности. Какой действительно путь?

Бастиан: Измерение веб-производительности - это гораздо больше, чем просто взглянуть на Google PageSpeed ​​Insights Score (PIS). Это число просто никак не отражает то, как реальный процесс загрузки веб-сайта ощущается пользователями ваших пользователей. Современные веб-сайты должны использовать измерение времени рисования и особенно уделять пристальное внимание событию «время до первого значимого рисования», которое отмечает момент, когда произошло самое значительное изменение макета, превышающее сгиб, и виден ваш самый важный элемент.

Подумайте, YouTube: когда вы посещаете этот сайт, вас действительно волнует видео - этот элемент должен быть очень быстрым; за ними могут следовать такие элементы, как навигация, логотип, похожие видео или комментарии, но видео - это элемент вашего героя, и его нужно показывать быстро!

Вопрос: Google в последнее время чаще говорит о критическом пути рендеринга и сверхскоростном контенте; Можете ли вы объяснить концепцию вокруг этого и почему это важно для них?

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

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

Вопрос: Можете ли вы рассказать нам о своей рутинной работе с CSS? Какой способ пойти и получить максимальную отдачу от специфичных для CSS оптимизаций?

Бастиан: Чтобы ускорить вашу доставку CSS, я бы порекомендовал вам:

• Запустите аудит, очистите (устранение дублирования, избавьтесь от неиспользуемых стилей и т. Д.), А затем разделите ваш CSS на две части: одну для «начального представления» и оставшуюся часть CSS для «ниже сгиба».
• Используйте этот инструмент «Критический» (что бесплатно), чтобы помочь идентифицировать, а также генерировать критически важную информацию CSS.
• Встроенный ранее сгенерированный CSS для начального представления (да, встроенный!).
• Используйте rel = «preload» и «loadCSS» для асинхронной загрузки CSS «ниже сгиба / сидячего» (тег noscript обеспечит откат для клиентов без включенного JavaScript).

Между прочим, есть веская причина, почему Google вкладывает весь свой CSS (на своих страницах результатов поиска): это намного быстрее, чем запросы HTTP (HTTP)!

Брайан Вайс

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

Вопросы: Вы упомянули получение «базового уровня» перед сканированием и использованием инструментов. Зачем вам нужна базовая линия?

Брайан: Если вы получите базовое представление о вашем веб-сайте ПЕРЕД сканированием или использованием других инструментов SEO, это позволит вам гораздо лучше задавать вопросы и эффективно использовать собираемые вами данные.

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

Если вы вернете данные сканирования и увидите что-то отличное от ожидаемого, есть три возможных объяснения:

• Данные сканирования неверны.
• Ваша интерпретация логики сайта была неверной.
• Ваша интерпретация была правильной, но вы неправильно рассчитали, какое влияние это окажет на масштаб.

Любой из этих трех пунктов было бы чрезвычайно важно знать!

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

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

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

Использование robots.txt также имеет свою цену, так как PageRank передается по заблокированным URL-адресам, но не может вернуться на ваш сайт. Использование nofollow оказывает аналогичное влияние на PageRank, но менее эффективно блокирует сканирование URL-адресов - редко есть веская причина для использования nofollow для внутренних ссылок.

Вопрос: Так есть ли подход, в котором нет недостатка, связанного с различными элементами управления индексацией и сканированием, которые вы упомянули?

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

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

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

Есть вопрос, который мы не затронули?

У вас есть еще вопросы к нашим SMXperts? полный эта форма , и мы ответим на ваш вопрос и ответы SMXpert в ближайшее время!

Хотите узнать больше технической тактики SEO? Присоединяйтесь к нам в следующем месяце на нашем SMX Advanced конференция в Сиэтле, где ведущие эксперты отрасли поделятся своими советами, тактиками и стратегиями по этим темам и многим другим:

Мнения, выраженные в этой статье, принадлежат автору гостя и не обязательно относятся к Search Engine Land. Штатные авторы перечислены Вот ,

Об авторе