SEO HARDCORE
  • Разборы патентов
    • Патенты Google
  • Скоро SEO инструменты
  • Скоро SEO аналитика
  • seohardcore
SEO HARDCORE
назад

Как Google использует иерархию серверов и столбцовое хранение данных для обработки массивных наборов данных

HIERARCHY OF SERVERS FOR QUERY PROCESSING OF COLUMN CHUNKS IN A DISTRIBUTED COLUMN CHUNK DATA STORE (Иерархия серверов для обработки запросов к фрагментам столбцов в распределенном хранилище фрагментов столбцов)
  • US9576024B2
  • Google LLC
  • 2014-10-30
  • 2017-02-21
  • Описание
  • Разбор
  • Выводы
  • Практика
  • FAQ
  • Похожие

Патент описывает инфраструктуру для хранения и обработки огромных объемов данных. Система разбивает таблицы данных на "фрагменты столбцов" (Column Chunks) и распределяет их по множеству серверов. Запросы обрабатываются динамически определяемой иерархией серверов, которые выполняют подзадачи параллельно и объединяют результаты.

Описание

Какую проблему решает

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

Что запатентовано

Запатентована система распределенного хранения и обработки запросов. Ключевыми особенностями являются хранение данных в виде Column Chunks (столбцовый формат) для эффективного сжатия и извлечения, а также распределение этих фрагментов по множеству серверов с обеспечением избыточности (Parity Column Chunk). Для обработки запросов используется динамическое формирование Hierarchy of Servers (Иерархии серверов), что позволяет выполнять запросы параллельно.

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

Система работает следующим образом: таблицы данных разбиваются на Column Chunks в соответствии с заданными политиками хранения. Эти фрагменты распределяются (striping) по множеству серверов хранения. Для отказоустойчивости вычисляются и сохраняются фрагменты четности (parity). При получении запроса система трансформирует его в набор подзапросов (sub-queries). Динамически определяется иерархия серверов (например, трехуровневая) для выполнения этих подзапросов. Серверы работают параллельно, часто используя локальные или кэшированные данные. Промежуточные результаты агрегируются вверх по иерархии для формирования итогового ответа.

Актуальность для SEO

Высокая (для инфраструктуры). Описанные принципы — столбцовое хранение, распределенные вычисления, динамическая оптимизация запросов — лежат в основе современных систем обработки больших данных Google (таких как BigQuery/Dremel). Хотя конкретная реализация могла эволюционировать с момента подачи исходной заявки (2005 год), описанный архитектурный подход остается фундаментальным и актуальным.

Важность для SEO

Минимальное (1/10). Патент описывает внутреннюю инфраструктуру Google для хранения и обработки данных (архитектуру баз данных), а не алгоритмы ранжирования, сигналы качества или методы интерпретации контента. Он не дает прямых рекомендаций для SEO-специалистов по оптимизации сайтов. Понимание этой инфраструктуры полезно для общего технического контекста работы поисковой системы, но не влияет на повседневные SEO-задачи.

Детальный разбор

Термины и определения

Column Chunk (Фрагмент столбца)
Единица хранения данных. Представляет собой данные одного столбца таблицы, разделенные на части с использованием одного или нескольких ключей (например, методом хэширования или по диапазону значений).
Column Chunk Data Store (Хранилище данных фрагментов столбцов)
Распределенная система хранения, состоящая из множества серверов, хранящих Column Chunks.
Data Domain Compression (Сжатие домена данных)
Применение схем сжатия, специфичных для типа данных в конкретном столбце (например, оптимизированное сжатие дат, попадающих в узкий диапазон).
Distribution Policy (Политика распределения)
Правила, определяющие, как Column Chunks распределяются (например, striping) между доступными серверами хранения.
Hierarchy of Servers (Иерархия серверов)
Динамически определяемая структура серверов обработки запросов (например, Level 1, Level 2, Level 3), используемая для распределенного и параллельного выполнения запроса.
Parity Column Chunk (Фрагмент столбца четности)
Специальный фрагмент данных, созданный (например, с помощью операции XOR) на основе двух или более других Column Chunks. Используется для восстановления данных при отказе одного из серверов.
Query Processing Server (Сервер обработки запросов)
Сервер, выполняющий этапы обработки запроса (парсинг, анализ, оптимизация, выполнение). Может быть как отдельным сервером, так и совмещенным с функциями сервера хранения.
Storage Policy (Политика хранения)
Правила, определяющие, как таблица данных должна быть разделена на Column Chunks (например, метод разделения, количество фрагментов) и требуемый уровень избыточности.
Storage Server (Сервер хранения)
Сервер, физически хранящий Column Chunks и предоставляющий к ним доступ.
Sub-queries (Подзапросы) / Transformed Query
Части исходного запроса, полученные в результате его трансформации для распределенного выполнения на разных серверах.

Ключевые утверждения (Анализ Claims)

Патент описывает внутренние процессы Google без прямых рекомендаций для SEO.

Claim 1 (Независимый пункт): Описывает комплексный метод управления данными и обработки запросов в распределенной системе.

  1. Создание первого и второго Column Chunks из таблицы данных. Создание основано на Storage Policy (определяет количество фрагментов) и Distribution Policy (определяет размещение).
  2. Создание Parity Column Chunk на основе первого и второго фрагментов для обеспечения возможности восстановления данных.
  3. Распределение первого и второго фрагментов для хранения на серверах.
  4. Получение запроса к данным.
  5. Трансформация исходного запроса в несколько sub-queries (подзапросов).
  6. Распределение первого и второго подзапросов на разные серверы обработки запросов (query servers).
  7. Получение промежуточных результатов (sub-results) от этих серверов.
  8. Объединение промежуточных результатов в итоговый результат (master result).
  9. Отправка ответа на запрос.

Claim 2 (Зависимый от 1): Уточняет метод создания Parity Column Chunk.

Создание фрагмента четности включает выполнение побитовой операции XOR над данными первого и второго Column Chunks.

Claim 3 (Зависимый от 1): Уточняет размещение Parity Column Chunk.

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

Где и как применяется

Патент описывает инфраструктуру хранения и извлечения данных. Он не описывает стандартные фазы поисковой архитектуры (Ranking, Query Understanding и т.д.), а скорее базовую платформу (Data Store), на которой эти фазы могут оперировать при работе с большими данными.

INDEXING – Индексирование (Хранение данных)
Описанная система предназначена для хранения массивных наборов данных, собранных и обработанных в процессе индексирования (например, индекс ссылок, логи поведения пользователей, Content Warehouse). Механизмы Column Chunks, Data Domain Compression и распределенное хранение с Parity Column Chunk применяются при записи данных в хранилище.

RANKING – Ранжирование (Обработка запросов к данным)
Когда алгоритмам ранжирования требуется доступ к этим массивным наборам данных для анализа или извлечения признаков, система обработки запросов (Query Processing Servers) использует описанную Hierarchy of Servers для эффективного извлечения и агрегации информации.

Входные данные:

  • Таблицы данных (для загрузки в хранилище).
  • Storage Policy и Distribution Policy.
  • Запрос (Query) к данным в хранилище.

Выходные данные:

  • Сохраненные и распределенные Column Chunks и Parity Column Chunks.
  • Итоговый результат выполнения запроса (Master Result).

На что влияет

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

Когда применяется

  • Хранение данных: Алгоритмы разделения и распределения применяются при загрузке новых или обновлении существующих больших наборов данных в распределенное хранилище.
  • Обработка запросов: Механизм иерархической обработки применяется, когда поступает запрос к данным, хранящимся в формате Column Chunks. Иерархия серверов активируется для оптимизации и выполнения этого запроса.

Пошаговый алгоритм

Процесс А: Хранение данных

  1. Доступ к политике: Система получает доступ к Storage Policy для определения метода разделения таблицы и уровня избыточности.
  2. Разделение данных: Таблица данных разделяется на Column Chunks (например, с использованием range, list или hash partitioning).
  3. Сжатие: К фрагментам применяется Data Domain Compression.
  4. Вычисление четности: Система вычисляет Parity Column Chunks (например, через XOR) для обеспечения отказоустойчивости.
  5. Распределение: На основе Distribution Policy, фрагменты данных и фрагменты четности распределяются (striping) по разным серверам хранения (Storage Servers).

Процесс Б: Обработка запроса

  1. Получение запроса: Клиент отправляет запрос на сервер обработки запросов (например, Level 3).
  2. Парсинг и Анализ: Сервер проверяет синтаксис и семантику запроса.
  3. Оптимизация и Трансформация: Оптимизатор запросов определяет шаги выполнения и трансформирует запрос в набор подзапросов (sub-queries) для распределенного выполнения.
  4. Определение Иерархии: Система динамически определяет иерархию серверов (Level 1, Level 2) для выполнения подзапросов. Выбор серверов может основываться на расположении необходимых Column Chunks (включая кэшированные данные).
  5. Распределение подзапросов: Подзапросы и инструкции по обработке отправляются вниз по иерархии (например, с Level 3 на Level 2, затем на Level 1).
  6. Параллельное выполнение (Level 1): Серверы нижнего уровня выполняют подзапросы, извлекая необходимые Column Chunks (из кэша или с серверов хранения) и обрабатывая их.
  7. Агрегация промежуточных результатов (Level 2): Серверы среднего уровня получают промежуточные результаты от серверов нижнего уровня и объединяют (combine) их согласно инструкциям.
  8. Финальная агрегация (Level 3): Головной сервер получает результаты от среднего уровня, выполняет финальное объединение и формирует итоговый ответ (master result).
  9. Возврат результата: Ответ отправляется клиенту.

Какие данные и как использует

Данные на входе

Патент фокусируется на инфраструктуре и не упоминает конкретные SEO-факторы (контентные, ссылочные, поведенческие, временные и т.д.). Он оперирует следующими типами данных:

  • Структурные данные: Таблицы данных, состоящие из строк и столбцов, которые преобразуются в Column Chunks.
  • Системные данные (Метаданные): Информация о физическом расположении Column Chunks, политиках хранения (Storage Policy), политиках распределения (Distribution Policy), состоянии серверов (нагрузка, доступность) и наличии кэшированных данных на серверах обработки запросов.

Какие метрики используются и как они считаются

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

  • Размер результатов: Оценка размера промежуточных результатов выполнения подзапросов. Это используется для определения того, как лучше всего агрегировать данные на среднем уровне иерархии (Level 2).
  • Локальность данных: Учет того, какие серверы (Query Processing Servers) уже кэшируют необходимые Column Chunks. Оптимизация направлена на выполнение вычислений на тех серверах, где данные уже присутствуют, для минимизации передачи данных по сети.

Выводы

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

  1. Столбцовое хранение (Columnar Storage): Google использует формат Column Chunks для хранения массивных наборов данных. Это позволяет применять высокоэффективное сжатие, специфичное для типа данных (Data Domain Compression), и оптимизировать извлечение данных, читая только необходимые для запроса столбцы, а не целые строки.
  2. Отказоустойчивость через избыточность: Система обеспечивает целостность данных и возможность восстановления при сбоях оборудования с помощью вычисления и хранения Parity Column Chunks (используя операцию XOR). Эти фрагменты четности хранятся отдельно от исходных данных.
  3. Масштабируемая обработка запросов: Для обработки запросов к большим данным используется динамически формируемая Hierarchy of Servers. Запросы трансформируются в подзапросы (sub-queries) и выполняются параллельно на множестве серверов с последующей агрегацией результатов.
  4. Оптимизация через кэширование: При формировании иерархии и планировании выполнения запроса система стремится использовать кэшированные Column Chunks на серверах обработки запросов для ускорения работы и снижения нагрузки на сеть и дисковую подсистему.

Практика

Патент является инфраструктурным и не дает практических выводов или рекомендаций для SEO-специалистов по оптимизации сайтов.

Best practices (это мы делаем)

Информации в патенте нет.

Worst practices (это делать не надо)

Информации в патенте нет.

Стратегическое значение

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

Практические примеры

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

Вопросы и ответы

Описывает ли этот патент, как Google ранжирует сайты?

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

Что такое "Column Chunk" и почему это важно?

Column Chunk — это способ хранения данных в столбцовом формате, а не построчно. Это критически важно для аналитических систем, так как позволяет сжимать данные более эффективно (используя Data Domain Compression) и значительно ускоряет запросы, которым нужны только несколько столбцов из таблицы с сотнями полей, поскольку система читает только нужные столбцы.

Какое отношение этот патент имеет к SEO?

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

Что такое "Hierarchy of Servers" в контексте патента?

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

Упоминается ли в патенте кэширование?

Да, система обработки запросов спроектирована так, чтобы учитывать расположение кэшированных Column Chunks. Оптимизатор старается направить выполнение подзапроса на тот сервер, который уже имеет нужные данные в кэше, чтобы избежать передачи данных по сети и ускорить обработку.

Что такое "Parity Column Chunk"?

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

Является ли описанная система аналогом MapReduce?

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

Описывает ли патент базу данных, которую использует Google для хранения веб-индекса?

Патент описывает общую архитектуру распределенного хранилища (Distributed Column Chunk Data Store). Эта архитектура может использоваться для хранения различных типов больших данных, включая части веб-индекса, логи поведения пользователей, данные аналитики или индекс ссылок.

В патенте упоминаются политики хранения (Storage Policy). Может ли SEO-специалист на них повлиять?

Нет. Storage Policy и Distribution Policy — это внутренние конфигурации системы управления базами данных Google. Они определяют, как данные физически разделяются и распределяются по серверам Google. Внешние пользователи или SEO-специалисты не имеют к ним доступа и не могут на них влиять.

Актуален ли этот патент, учитывая, что он был подан давно?

Да, архитектурные принципы, заложенные в патенте (столбцовое хранение, распределенные вычисления, динамическая иерархия обработки), являются фундаментальными для современных систем больших данных. Хотя конкретная реализация в Google, вероятно, эволюционировала (например, в системах типа Dremel/BigQuery), базовые концепции остаются высоко актуальными.

Похожие патенты

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

  • Персонализация

Как Google строит инфраструктуру поиска на основе фраз и оптимизирует извлечение концепций из контента
Патент описывает комплексную систему поиска, которая индексирует документы на основе фраз, а не отдельных слов. Он детализирует процесс извлечения фраз (Phrase Extraction), учитывающий структуру и форматирование контента. Для хранения этого индекса используется многоуровневая (Tiers) и шардированная (Shards) архитектура, которая оптимизирует скорость поиска и снижает нагрузку на серверы.
  • US7693813B1
  • 2010-04-06
  • Индексация

  • Семантика и интент

Как Google масштабирует поиск похожих объектов (например, изображений или дубликатов) с помощью распределенных деревьев поиска
Патент описывает инфраструктурное решение Google для поиска ближайших соседей (наиболее похожих объектов) в огромных наборах данных, которые не помещаются на одном сервере. Система использует структуру "Parallel Hybrid Spill Tree" для распределения данных по нескольким машинам, что позволяет выполнять эффективный и быстрый поиск дубликатов или схожего контента в масштабах всего интернета.
  • US7539657B1
  • 2009-05-26
  • Индексация

Как Google оптимизирует инфраструктуру своего индекса для ускорения поиска подстрок и фраз
Этот патент описывает инфраструктурную оптимизацию поискового индекса Google. В нем представлена «гибридная структура данных», которая ускоряет извлечение информации (например, местоположение фраз в документах) путем объединения бинарных деревьев с таблицами поиска и использования высокоэффективных методов сортировки. Это делает поиск быстрее, но не влияет на алгоритмы ранжирования.
  • US8856138B1
  • 2014-10-07
  • Индексация

Как Google использует фразы для построения индекса, оптимизирует поиск и обеспечивает свежесть выдачи
Анализ патента, описывающего архитектуру поисковой системы Google, основанную на индексировании фраз, а не отдельных слов. Патент раскрывает, как система извлекает значимые фразы из документов, используя структурные сигналы (заголовки, абзацы, форматирование), организует индекс в многоуровневую структуру (Tiers и Shards) и обеспечивает непрерывное обновление данных (Segment Swapping) без остановки поиска.
  • US7702614B1
  • 2010-04-20
  • Индексация

  • Свежесть контента

  • Семантика и интент

Популярные патенты

Как Google использует внешние сигналы (соцсети, новости, блоги) для верификации реальной популярности контента и фильтрации накруток
Google верифицирует популярность контента (например, видео) проверяя, упоминается ли он на внешних источниках: блогах, новостных сайтах и в социальных сетях. Это позволяет формировать списки "популярного", отражающие подлинный широкий интерес, отфильтровывая контент с искусственно завышенными просмотрами или узконишевой популярностью. Система также учитывает географическую релевантность внешних упоминаний.
  • US9465871B1
  • 2016-10-11
  • Антиспам

  • SERP

  • Ссылки

Как Google использует клики пользователей в поиске по картинкам для понимания содержания изображений и улучшения таргетинга
Google анализирует поведение пользователей в поиске по картинкам для идентификации содержания изображений. Если пользователи ищут определенный запрос (идею) и массово кликают на конкретное изображение в результатах, система связывает это изображение с данным запросом (концепцией). Эти данные используются для улучшения ранжирования в поиске картинок и для предложения релевантных ключевых слов рекламодателям, загружающим схожие изображения.
  • US11409812B1
  • 2022-08-09
  • Поведенческие сигналы

  • Семантика и интент

  • SERP

Как Google персонализирует поисковые подсказки (Autocomplete) на основе недавно просмотренного медиаконтента
Google использует информацию о недавно потребленном пользователем медиаконтенте (видео, аудио, книги, игры) для персонализации поисковых подсказок. Система извлекает атрибуты (аспекты) из этого контента, такие как названия, имена актеров или артистов, и повышает в ранжировании те подсказки, которые соответствуют этим атрибутам. Влияние потребления медиа на подсказки зависит от времени, прошедшего с момента просмотра, типа контента и того, делился ли им пользователь.
  • US9268880B2
  • 2016-02-23
  • Персонализация

  • Семантика и интент

  • Мультимедиа

Как Google выбирает модель визуальной релевантности для сложных запросов в Поиске по картинкам
Google решает проблему ранжирования изображений для сложных или редких запросов, для которых нет специализированной модели релевантности. Система тестирует существующие модели, созданные для частей запроса (подзапросов), и выбирает ту, которая лучше всего соответствует поведению пользователей (кликам) по исходному запросу. Это позволяет улучшить визуальную релевантность в Image Search.
  • US9152652B2
  • 2015-10-06
  • Поведенческие сигналы

  • Мультимедиа

  • Семантика и интент

Как Google извлекает, обрабатывает и индексирует анкорный текст, контекст и атрибуты входящих ссылок для ранжирования целевых страниц
Фундаментальный патент, описывающий инфраструктуру Google для обработки ссылок. Система извлекает анкорный текст, окружающий контекст и атрибуты форматирования (аннотации) из исходных страниц и инвертирует эти данные в структуру "Sorted Anchor Map". Это позволяет индексировать целевую страницу по тексту ссылок, указывающих на нее, используя эту внешнюю информацию как сигнал релевантности.
  • US7308643B1
  • 2007-12-11
  • Ссылки

  • Индексация

  • Техническое SEO

Как Google масштабирует расчет кратчайших путей в графе ссылок от авторитетных сайтов («Seed Nodes»)
Патент описывает инфраструктуру Google для распределенного вычисления кратчайших путей в огромных графах, таких как веб-граф. Система позволяет эффективно и отказоустойчиво рассчитывать расстояние от любого узла до ближайших авторитетных «Seed Nodes». Это foundational технология, которая делает возможным применение алгоритмов ранжирования, основанных на анализе ссылочного графа и распространении авторитетности (например, типа TrustRank) в масштабах всего интернета.
  • US8825646B1
  • 2014-09-02
  • Ссылки

Как Google использует «Фразовую модель» (Phrase Model) для прогнозирования качества сайта на основе статистики использования N-грамм
Google прогнозирует оценку качества сайта, анализируя, какие фразы (N-граммы) используются и как часто они распределены по страницам сайта. Система создает «Фразовую модель», изучая известные высококачественные и низкокачественные сайты, а затем применяет эту модель для оценки новых сайтов по их лингвистическим паттернам.
  • US9767157B2
  • 2017-09-19
  • Семантика и интент

  • Техническое SEO

  • EEAT и качество

Как Google использует распределение кликов в выдаче для определения брендовых (навигационных) и общих (тематических) запросов
Google анализирует поведение пользователей в поисковой выдаче для классификации интента запроса. Если клики сконцентрированы на одном результате (низкое разнообразие, высокая частота), запрос классифицируется как навигационный или брендовый (Data-Creator Targeting). Если клики распределены по разным сайтам, запрос считается общим (Content Targeting). Эта классификация используется для адаптации поисковой выдачи.
  • US20170068720A1
  • 2017-03-09
  • Семантика и интент

  • Поведенческие сигналы

  • SERP

Как Google индексирует контент внутри мобильных приложений для показа в результатах поиска (App Indexing)
Google использует механизм для индексации контента, который пользователи просматривают в нативных мобильных приложениях. Система получает данные о просмотренном контенте и deep links напрямую от приложения на устройстве. Эта информация сохраняется в индексе (персональном или публичном) и используется для генерации результатов поиска, позволяя пользователям переходить к контенту внутри приложений напрямую из поисковой выдачи.
  • US10120949B2
  • 2018-11-06
  • Индексация

  • SERP

  • Персонализация

Как Google использует социальные связи для обнаружения ссылочного спама и накрутки кликов
Google может анализировать связи между владельцами сайтов в социальных сетях, чтобы оценить независимость ссылок между их ресурсами. Если владельцы тесно связаны (например, друзья), ссылки между их сайтами могут получить меньший вес в ранжировании, а клики по рекламе могут быть классифицированы как спам (накрутка).
  • US8060405B1
  • 2011-11-15
  • Антиспам

  • Ссылки

  • SERP

seohardcore