Как и почему отрасль инструментов SEO должна разрабатывать технические стандарты

1. Прецеденты для веб-стандартов
2. Итак, почему нет технических стандартов?
3. Какова стоимость?
4. Что нужно стандартизировать?
5. 1. Ссылка метрик
6. 2. Возможности сканирования
7. 3. Сканирование данных
8. 4. Рейтинги
9. 5. Контент-анализ
10. Давайте начнем с черновика

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

Точно так же, как W3C сплотился вокруг определения стандартов протоколов в 1994 году и стандартизированных методов кодирования Web Project Project (WaSP) в 1998 году, наш черед застопорить наше программное обеспечение и подготовиться к тому, что будет дальше.

Остановите меня, если вы слышали это. 4 декабря я получил электронное письмо от DeepCrawl, в котором сообщалось, что в моем аккаунте нет средств. Это не имело никакого смысла, потому что мой цикл выставления счетов только что перезапустился за несколько дней до этого, и, честно говоря, мы не очень активно использовали этот инструмент с октября, как вы можете видеть на скриншоте ниже. У меня все еще должен быть миллион кредитов.

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

Единственная причина, по которой у меня все еще есть учетная запись, заключается в том, что исторические данные клиента заблокированы в платформе. Конечно, вы можете экспортировать множество .CSV, но что тогда? Нет простого способа перенести мои исторические данные из Deep Crawl в On-Page или Botify.

Это потому, что индустрия инструментов SEO не имеет технических стандартов. У каждого инструмента совершенно разные подходы к тому, как и что они сканируют, а также как хранятся и в конечном итоге экспортируются данные.

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

Что касается миграции между платформами, то только поставщики уровня предприятия, такие как Searchmetrics, Linkdex, SEOClarity, Conductor и BrightEdge, имеют системы для миграции между собой. Это, однако, все еще требует настраиваемого импорта данных, чтобы это произошло.

Прецеденты для веб-стандартов

Каждая отрасль имеет своего рода некоммерческий орган управления, который устанавливает стандарты. У нас есть пять основных руководящих органов:

• Консорциум World Wide Web (W3C) - они определяют открытый веб-стандарт и отвечают за такие протоколы, как HTTP и стандартизацию HTML, CSS и JavaScript.
• Международная организация по стандартизации (ИСО). Несмотря на то, что они, похоже, не понимают, как работают сокращения, ИСО имеет определены семь спецификаций для нескольких компонентов сети.
• Консорциум Unicode - они разрабатывают стандарты кодировки символов для Unicode, чтобы обеспечить их совместимость на международном уровне.
• Инженерная рабочая группа по Интернету (IETF) - они определяют технологические стандарты для пакета интернет-протоколов и с тех пор приняли на себя Стандарт HTTP от W3C.
• Европейская ассоциация по стандартизации информационных и коммуникационных систем (ECMA) - они определили каноническую версию JavaScript. До существования ECMA существовало пять различных версий JavaScript, основанных на реализации в каждом браузере.

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

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

Например, Google указывает, что JavaScript подходит для перенаправления между мобильной и настольной версиями страницы И ни один инструмент SEO не может это определить. Кроме того, независимо от недавнего 302 против 301 дебатов В той же спецификации сказано, что вы должны использовать 302 для этих типов перенаправлений. Не существует достаточно умного инструмента, чтобы определить, должна ли страница, возвращающая 302, возвращать 302. Также существует непоследовательный анализ заголовков HTTP, несмотря на то, что Google будет делать определения на их основе.

Итак, почему нет технических стандартов?

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

Так что же мешает индустрии инструментов SEO объединяться и выпускать технические стандарты? Несколько вещей…

• Фирменные преимущества. Многое из того, что предлагают инструменты SEO, вышло из вакуума, созданного Google. Например, Google никогда не давал нам надежного значения PageRank или простого способа определить, является ли веб-сайт спамом, поэтому такие компании, как Moz, разработали свои собственные показатели авторитетности домена и оценки спама. Между тем, у Majestic есть свои собственные экстраполированные метрики, основанные на концепции PageRank, но как согласовать Citation Flow и TrustFlow с метриками Moz, когда у вас есть ссылки, которые одна обнаружила, а другая нет? В случае с Moz они смогли установить свой флаг достаточно хорошо, так как администрация домена заменила PageRank как популярную меру, которую люди используют для определения значения ссылки. По моему опыту, очень немногие в Штатах говорят о показателях Majestic или Ahrefs, когда обсуждают ценность ссылки. Однако некоторая сторонняя стандартизация этих мер, позволяющая конечному пользователю перевести Page Authority (Moz) в Citation Flow (Majestic) в URL Rating (Ahrefs), сделает все данные гораздо более удобными для использования. Реальность такова, что разум вокруг этих метрик, действительно, является частным преимуществом. Как указано в современной Эдисон против Тесла иск, поданный BrightEdge против Searchmetrics Некоторые из этих компаний, похоже, больше заботятся об этих проприетарных преимуществах, чем о проведении лучшего анализа.
• Относительно молодая индустрия. Люди любят упоминать, что SEO еще не достаточно стар, чтобы пить. Однако индустрия не намного моложе самой сети. Чтобы поместить это в перспективу, Google моложе, чем индустрия SEO, и она разработала стандарты во многих отраслях. Трудно принять идею, что молодежь отрасли виновата в отсутствии стандартов.
• Промышленная политика. Возможно, это то, что SEMPO мог бы сделать, но в последние годы организация пыталась создать Кодекс этики для индустрии SEO и встретил много политических раздоров , Я не знаю, какие плюсы и минусы SEMPO и его политической истории, но я подозреваю, что какой-либо одной из сторон будет сложно установить флаг для веб-стандартов. Комбинация агентств и брендов, возможно, должна собраться и использовать их общий вес, чтобы это произошло.

Какова стоимость?

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

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

• Работаю над устранением неправильного образования. Индустрия SEO страдает от мизеобразования, большая часть которого рождается из пассивной небрежности в соответствии с последними тенденциями и изменениями, а не из-за активного невежества. Мы создаем инструменты как ярлыки. Другими словами, мы рассматриваем наши инструменты как калькуляторы, но иногда они располагаются перед людьми, которые не знают основную математику. Внедрение стандартов поможет гарантировать, что эти оптимизаторы будут оставаться в курсе или, по крайней мере, их анализ будет более точным.
• Переносимость данных. Возможность переходить от одного инструмента к другому - это то, что существует в большинстве программ. От браузеров до электронной почты, от CRM до платформ автоматизации маркетинга и даже от самого Google, пользователи, как правило, могут загружать свои данные целиком, загружать их в другой инструмент и использовать их сразу. Несмотря на то, что каждый инструмент в нашем пространстве имеет различную интерпретацию того, как вещи должны распознаваться и анализироваться, все они используют одни и те же входные данные для создания этих выходных данных, поэтому не должно быть затруднений сделать шаг при наличии стандартов.
• Идти в ногу с возможностями Google. В документации для веб-мастеров Google указано много рекомендаций, которые многие программы SEO не соблюдают и не применяют.
• Минимальные функциональные требования. В то время как у каждого поставщика инструментов есть свой собственный набор функций по разным причинам, есть такие, которые не имеют того минимума, которого ожидают пользователи. Например, вы ожидаете, что любой инструмент исследования ключевых слов сможет предложить вам объем поиска и исторический тренд объема поиска на основе ключевых слов. Вы также можете ожидать, что у этого инструмента будет API, позволяющий масштабировать ваш анализ. Установление минимальных требований к характеристикам для типов инструментов позволит гарантировать, что любой используемый инструмент может, как минимум, выполнять те же цели. Это именно то, что Google делает для API AdWords, и почему было применено огромное количество программ для SEO, которые использовали его, потому что они не реализовали минимальную функциональность, необходимую для управления кампаниями AdWords.

Что нужно стандартизировать?

Итак, с чего начинается процесс стандартизации? Что должно быть согласованным на разных платформах, чтобы инструменты SEO отвечали этим требованиям? Это, конечно, для обсуждения, но вот мои предложения:

1. Ссылка метрик

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

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

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

Домашняя страница для общего сканирования

Common Crawl - это публичный архив, последняя итерация которого содержит 1,72 миллиарда страниц. Любой желающий может скачать и обработать его как средство веб-анализа. (В прошлом я руководил проектами, в которых мы использовали Common Crawl в качестве корпуса для извлечения данных влияния и выявления возможностей неработающих ссылок. Но я отвлекся.)

Если бы Moz, Majestic и Ahrefs публично обработали Common Crawl, они могли бы предоставить метрики друг друга или, что более реалистично, пользователи могли бы конвертировать метрики Ahrefs и Majestic в более широко понятые метрики Moz.

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

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

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

2. Возможности сканирования

Возможности сканирования Google прошли долгий путь. Кроме Screaming Frog, насколько мне известно, все инструменты SEO все еще ползают так же, как и всегда. Все инструменты SEO выполняют анализ, основанный на загрузке HTML, а не на визуализации страницы.

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

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

Внутри этих инструментов сканирования потребуется использовать Headless Chromium или QTWebkit без головы (PhantomJS) в дополнение к текстовым сканерам с целью еще более тесно подражать опыту Google.

3. Сканирование данных

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

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

4. Рейтинги

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

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

Мы все воровали рейтинг у Google с помощью средства, которое раздувает объем поиска; Каждый инструмент имеет свою методологию. Что если бы вместо этого существовало централизованное хранилище данных, где ранжирование осуществлялось с помощью распределенных средств или сложных бот-сетей, к которым каждый мог получить доступ, таким образом предоставляя любому доступ к полным данным SERP? Таким образом, перед поставщиками инструментов будет поставлена ​​задача предоставить усовершенствования, которые сделают эти данные более ценными.

STAT раньше предлагал Кодекс который дал бесплатные рейтинги более 200 000 ключевых слов. Я считаю, что это был большой шаг в правильном направлении к моему идеалу. Я также считаю, что STAT является отличным примером компании, которая улучшает данные и позволяет вам дополнительно настраивать эти улучшения.

STAT интерфейс [нажмите, чтобы увеличить]

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

• Зернистая геолокация. Многие инструменты ранжирования позволяют ориентироваться на определенный город или, возможно, почтовый индекс. Эмулятор геолокации Google Chrome позволяет указать ваше местоположение вплоть до широты и продольных координат, и рейтинги реагируют на эту специфику.
• Конкретные мобильные контексты. Вместо «смартфона» минимальная спецификация должна включать возможность выбора различных вариантов браузера и модели телефона. Например, Safari в рейтинге iPhone 6 против Chrome в рейтинге Android.
• Полное измерение SERP. Измерение только органических компонентов страницы результатов поиска (SERP) вводит в заблуждение на этом этапе. По крайней мере, должны быть некоторые измерения взаимодействия между платным и органическим, а также различные функции SERP (например, результаты новостей, локальные пакеты, избранные фрагменты), которые отвлекают от видимости органического рейтинга. Кроме того, включение данных CTR из Google Search Console в этот контент дает вам более подробные сведения о том, как вы работаете.
• Сегментация. Поскольку и Google, и SEO делают шаг к кластеризации ключевых слов, очень важно иметь возможность сегментировать ключевые слова в вашей системе ранжирования. Поддержка этого должна быть распространена; пользователи должны иметь возможность загружать определенный формат CSV, который обеспечивает легкую сегментацию, и в идеале инструменты должны предлагать группировки на основе стандартизированных таксономий. Таксономии Google могут хорошо работать здесь.

5. Контент-анализ

Несмотря на то, что Google перешел из струны к вещам Много лет назад все еще есть люди, исследующие поиск через призму плотности ключевых слов и таргетинга тегов H1. Google объявил, что анализ сущностей - это то, с чего они начинают понимать запрос.

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

Инструменты SEO не всегда на этом уровне сложности для анализа контента. Инструменты NLP, TF * IDF и LDA заменили концепцию плотности ключевых слов, но большинство инструментов сканирования не оценивают эти методы при рассмотрении страниц.

Минимальная спецификация инструмента обхода должна состоять в том, что он извлекает объекты и вычисляет оценки моделирования темы. Основным препятствием для этого в случае TF * IDF является наличие рейтингов, так как для расчета требуется анализ других рейтинговых документов, но инициатива открытого рейтинга может поддержать эти усилия.

Давайте начнем с черновика

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

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

Поставщики инструментов могут собираться вместе для разработки стандартов так же, как поисковые системы объединяются для разработки Schema.org , Однако отсутствие ценности для поставщиков инструментов делает это маловероятным. Возможно, группа агентств или СМИ поисковой индустрии могли бы собраться и сделать это. Эти люди более объективны и не заинтересованы в самих этих компаниях.

Или кто-то может просто начать это и посмотреть, кто в конечном итоге способствует.

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

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

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

Об авторе

Похожие

Комментарии