Как технически устроены сайты, которые Яндекс держит наверху

У attik.ru в выборку попали две страницы одного шаблона. Посадочная под дачные окна стоит седьмой по запросу «тёплые окна для дачи», общая категория пластиковых окон — тридцать пятой по «пластиковые окна купить». Подключений поровну, по 22 скрипта и 54 файла стилей на обеих. Сервер один, отвечает за 335 и 327 мс. Документы различаются на 42 килобайта.

Расходятся эти страницы там, где заканчивается техничка. 1205 слов против 2015, картинок 50 против 79. Дальше идёт on-page, то есть объём, полнота раскрытия темы и соответствие странице своему запросу.

Это не единичный случай. По всем 111 сайтам, где в выборку попали и высокие, и низкие адреса, картина та же. Между разными сайтами техничка отделяет верх от низа уверенно. Внутри одного сайта перестаёт. Алгоритм ранжирования Яндекса опирается на сотни факторов, и техничка среди них тот слой, который задаёт условия участия, а не место в выдаче.

Что здесь не будет разбираться

On-page слой я уже измерял отдельно, на 1601 странице по 162 запросам. Там проверялись title, description, H1, подзаголовки, объём текста, изображения, микроразметка и полнота интента. Ни полнота интента, ни длина title, ни большинство привычных ручных правок порядок мест внутри выдачи не объясняли.

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

Две величины, которые нельзя путать

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

Размер HTML — это сам документ, который отдаёт сервер, без скриптов, стилей, картинок и шрифтов. Медиана топ-10 здесь 395 КБ. Объём загрузки — всё, что браузер реально скачал, чтобы показать страницу. Медиана топ-10 уже 3,2 МБ.

Разница между ними в сорок с лишним раз. На HTML приходится всего 2,2% от того, что качает браузер, и эта доля одинакова у топа и у хвоста выдачи.

Шестнадцать признаков на одной шкале

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

Читается это так. Размер HTML оказался сильнейшим из шестнадцати, и даже он ошибается в 41 случае из 100. Время ответа сервера ушло влево. Страница с бо́льшим временем стоит выше только в 45 случаях из 100, так что быстрые хосты в этих данных чаще наверху. А число файлов JavaScript и CSS сидит на пятидесяти, то есть на чистой монетке.

Что обещают чеклисты и что в данных

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

Правда ли топ тяжелее? можно опираться

Сначала всё выглядело просто. Данные аудита по всем 2585 страницам показывают ровный градиент.

Связь размера HTML с позицией на диапазоне 1–49 равна −0,224 при 2585 наблюдениях. Минус читается как «больше HTML — выше место», но связь слабая. Отличить топ от хвоста по ней можно, а угадать место конкретной страницы по её весу нельзя.

Данные аудита показывают только документ. Чтобы увидеть, что реально уходит в браузер, я взял 192 адреса поровну из шестнадцати ниш и открыл каждый трижды так, будто пользователь пришёл впервые, с пустым кэшем и чистым профилем. Байты считал сам браузер. Привычный способ, performance.transferSize, здесь врёт. Он показывает ноль для всего, что грузится с чужих доменов, а это половина рекламы и все CDN.

Успешно измерились 179 адресов: 88 сверху и 91 снизу.

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

Загрузку тяжелее трёх мегабайт имеют 53,4% страниц наверху против 36,3% внизу. Больше ста запросов делают 61,4% страниц топа против 33,0% внизу.

Почему счётчики скриптов ничего не решают

Технический аудит обычно считает штуки. Сколько скриптов, сколько файлов стилей, сколько картинок. По этим счётчикам верх выдачи от хвоста почти не отличается. Данные те же самые — 1215 страниц топ-10 против 1370 страниц с позиций 31–49, счётчики берутся из разбора HTML.

Стилей поровну, ровно по пять. Блокирующих скриптов наверху даже меньше, чем в хвосте. Число JS-файлов упирается интервалом в ноль. Уверенно расходятся только картинки, и то на восемь штук.

При этом по объёму те же самые страницы расходятся в полтора раза с лишним. 395 килобайт HTML против 242, 3267 килобайт загрузки против 2159, 1104 килобайта JavaScript против 716. Наверху не больше подключений, зато внутри того же их числа больше кода.

Одна оговорка про этот замер. Байты я считал от момента открытия страницы до конца загрузки плюс ещё полторы секунды. Всё, что подгружается позже — картинки при прокрутке, поздняя аналитика, реклама по таймеру, — в цифру не вошло. Так что это объём первой загрузки, а не всё, что страница скачает за время визита.

Что проверяли

2585 страниц из выдачи Яндекса: топ-10 против позиций 31–49, 160 запросов, шестнадцать ниш. Плюс 179 адресов через настоящий браузер с холодным кэшем.

Что нашли

Наверху HTML крупнее на 63%, браузер качает на 51% больше данных, запросов на 61% больше, DOM на 61% крупнее. Времена загрузки при этом не различаются.

Что это значит

Тяжёлая страница и медленная страница совсем не одно и то же, и в отчёте их стоит разводить.

Что делать

Сравнивать свой сайт с топом по килобайтам и DOM, а не по числу подключений. И мерить времена, а не сумму байтов.

А если сравнить две страницы одного сайта? можно опираться

А потом я сравнил страницы внутри одного сайта, и картина сломалась.

Вернёмся к attik.ru и добавим к нему вторую пару, cem-cement.ru. Оба сайта отдали в выборку по одной странице сверху и по одной снизу.

Техническая часть внутри каждого сайта совпадает. Тот же набор подключений, тот же шаблон, тот же сервер с разницей в десяток миллисекунд. А вот дальше начинается то, чем эти страницы действительно отличаются, и это контент. У attik.ru верхняя страница в полтора раза с лишним короче нижней, у cem-cement.ru наоборот, во столько же длиннее. Направления нет. Различие уходит в объём текста и полноту раскрытия темы, то есть в on-page, а не в техничку.

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

Сравнение внутри домена частично закрывает сайтовые свойства. Бренд, возраст домена, значительную часть его авторитета, CMS, инфраструктуру, CDN и защиту. Если у сайта одна страница стоит в топ-10, а другая — на 31–49, эти характеристики у них общие и объяснять разницу уже не могут.

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

Каждый из 111 доменов даёт один голос. Считается медиана его верхних страниц минус медиана нижних.

Что проверяли

Может, вся разница держится просто на том, что наверху стоят сайты покрупнее? Взял 111 доменов, у которых есть страницы и в топ-10, и на позициях 31–49, и сравнил их между собой.

Что нашли

Размер HTML: +11 463 байта вместо +157 075, если сравнивать топ с хвостом напрямую. DOM: −5 узлов. Обе цифры вполне могут оказаться случайными (p = 0,128 и p = 0,775).

Что это значит

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

Что делать

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

Ни одна строка в таблице ниже не проходит порог надёжности. По размеру HTML вышло 0,128, по DOM 0,775, а нужно меньше 0,05.

Между группами целиком разрыв по HTML составлял +157 075 байт, по DOM +492 узла.

Строка со словами показывает +108 при интервале [−50; 418]. Объём текста внутри домена тоже не задаёт направления, потому что на одном сайте верхняя страница длиннее, на другом короче, и в сумме это ноль.

А если взять пары по одному и тому же запросу?

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

Во всех трёх случаях страница, которая стоит выше, короче своего же соседа снизу. 734 слова против 1247, 1602 против 1754, 59 против 111. По размеру документа направления нет, два раза верх крупнее и один раз мельче.

Первая мысль была простая: может, я просто выбрал странные 111 сайтов? Проверил, добавив промежуточный шаг.

Внутри домена от исходной разницы остаётся 7% по HTML, и эта часть от нуля не отличима. По DOM не остаётся ничего.

Одно уточнение, чтобы не сказать лишнего. Схлопывается именно величина. Направление слабо держится: если перебрать все 1801 пару «верхняя страница против нижней» внутри тех же 111 сайтов, крупнее оказывается верхняя в 58 случаях из 100 — почти как между разными сайтами. Но 58 из 100 при монетке в 50 не двигают ничего, когда сама разница усохла со 157 килобайт до одиннадцати.

Если сравнивать ещё строже, тот же сайт и тот же тип страницы, таких пар 95, размер HTML даёт +15 021 байт с границами [2302; 28 831] и p = 0,04. Разница слабая и на грани, но уже не нулевая. DOM и время ответа по-прежнему на нуле.

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

Есть и обратная проверка. Может, всю разницу между сайтами создала пара огромных маркетплейсов или одна ниша? 2585 страниц пришли всего из 160 выдач, так что я пересчитал всё заново, сравнивая внутри каждой выдачи отдельно.

В 119 запросах из 160 медианный размер HTML наверху оказался больше. По DOM тоже 119 из 160. Оба результата с p < 0,001. Разница повторяется в трёх четвертях выдач по отдельности, так что дело не в паре гигантов вроде Авито или Яндекс Услуг.

Быстрее ли отвечают серверы из топа? под вопросом

А со скоростью вышло поучительнее всего.

Сервер наверху отвечает за 553 мс против 634 мс внизу. Разрыв около 80 мс, и с размером документа он не связан вообще. Единственная скоростная метрика во всём замере, которая различает верх и низ, — я уже собирался ставить её в выводы.

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

У Яндекса скорость сайта в официальной документации описана как комплекс из серверного кода, HTML, CSS, JS, изображений, CDN и кэша. Выделить из этого комплекса время ответа как то, что двигает позиции, мои данные не позволяют.

robots.txt: рабочий инструмент или след старой конфигурации? под вопросом

Clean-param совсем не декоративная строка. Яндекс пишет, что директива избавляет робота от повторной загрузки дублей, снижает нагрузку на сервер и, в отличие от Disallow, позволяет передать часть накопленных показателей на основной адрес. Рабочий инструмент управления обходом, а не галочка в аудите. С 2026 года GET-параметрами можно управлять и через соответствующий раздел Вебмастера, а Clean-param остаётся поддерживаемым способом сделать это в robots.txt.

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

На этом месте я решил проверить ещё раз: может, Clean-param просто чаще стоит у крупных проектов, а наверх их тянет размер, а не настройка обхода?

Связь с размером есть. У сайтов с Clean-param страницы крупнее — 359 КБ против 281 в топе и 236 против 196 в хвосте. Сам файл у крупных тоже толще: 2032 байта против 1242.

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

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

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

Какого размера robots.txt у сайтов из топа

Раз уж файл читается как след обслуживания, полезно знать его нормальные габариты. Вот распределение по 807 сайтам из топ-10 и 1129 с позиций 31–49 — тем, у которых robots.txt вообще отдался.

Пустой или почти пустой файл встречается редко в обеих группах: меньше ста байт у 13 сайтов топа и у 30 снизу. А вот совсем короткие файлы наверху заметно реже — до 500 байт укладываются 14,6% сайтов топа против 23,7% внизу, до килобайта 29,9% против 41,7%.

Что из чеклиста не работает вообще

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

Ни одного разрыва, который стоило бы обсуждать. У Last-Modified и мягких 404 картина вообще обратная ожидаемой. Их больше у хвоста, а не у топа.

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

Мягкий 404 — настоящая проблема, его чинят ради робота. Отсутствие Last-Modified — не ошибка, а контекстный сигнал. no-store на HTML часто выставлен намеренно. HTTP/2 — характеристика инфраструктуры, а не дефект проекта.

Балл качества HTML стоит разобрать отдельно, потому что его любят показывать клиенту. В моём движке он собирается так: пятьдесят баллов страница получает просто за то, что существует, до тридцати добавляется за семантические теги по 2,5 за штуку, до двадцати — за плотность текста в коде. Больше там ничего нет.

Отсюда и результат. Семантических тегов в обеих группах медианно по семь, в потолок упираются 31,5% страниц топа и 31,7% хвоста. Половина балла вообще константа. Такая оценка по своей конструкции не может различать группы. Она не меряет ни валидность кода, ни его чистоту.

Ни одно из перечисленного по этим данным не отличает первую десятку от четвёртой.

Где топ выглядит хуже хвоста

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

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

Полезными дубли от этого не становятся, и чинить их надо. Вывод другой. Сильный production-сайт не выглядит как идеальный результат чеклистового аудита.

Сколько «грязи» несёт на себе средняя страница из топа

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

Считались ошибки микроразметки, параметры в URL, смешанный контент, картинки без alt и почти-дубли текста. 1215 страниц топ-10 против 1370 с позиций 31–49.

Две трети страниц топа несут на себе хотя бы одну из этих претензий. У каждой пятой их две и больше. И — главное — чистых страниц наверху меньше, чем внизу: 35,8% против 37,6%.

По отдельным пунктам разрыв ещё нагляднее. Ошибки в микроразметке есть у 16,7% страниц топа против 9,4% внизу, параметрические адреса у 8,1% против 2,8%, почти-дубли текста у 3,2% против 1,2%. По трём признакам из пяти верх выдачи проигрывает хвосту, и это не мешает ему стоять наверху.

Сходится ли это с чужими исследованиями?

Прямых аналогов по Яндексу я так и не нашёл. Русскоязычные разборы факторов ранжирования за 2026 год, которые я открывал, цифр, выборок и ссылок на данные не приводят вообще. Так что сравнивать приходится с работами по Google, помня, что это другой поисковик и другая методика.

По HTML результаты расходятся, и это стоит проговорить прямо. У Backlinko на 11,8 млн результатов Google связи нет, у меня на выборке по Яндексу — есть, и заметная. Объяснений может быть несколько. Другой рынок, другой поисковик, другая методика отбора, влияние чего-то третьего, что тянет за собой и размер HTML, и позиции. Отделить их этими данными нельзя. Само по себе расхождение — повод для повторного замера, а не готовый вывод.

Ещё одно место, где ожидание не сходится с замером. Наверху существенно больше ресурсов — загрузка на 51%, запросы на 61%, — а измеренные времена не различаются вовсе. Первая отрисовка выше на 106 мс с интервалом [−104; +310], событие load на 329 мс с интервалом [−165; +760], браузерное время ответа на 15 мс с интервалом [−118; +217]. Все три ноль не исключают.

Почему полуторакратный рост объёма не даёт видимого проигрыша по времени, этот эксперимент не показывает. Гипотез хватает — параллельная загрузка, async и defer, отложенные картинки, CDN, приоритизация ресурсов, — но выбирать одну без измерения я не буду.

В какой нише разрыв больше?

Верх крупнее по HTML в каждой из шестнадцати ниш. А вот насколько крупнее — зависит от ниши, и это меняет смысл любых ориентиров. Сравнивать свою страницу нужно с её нишей, а не со средним по выдаче.

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

Обратите внимание на стройматериалы и товары для дома. Разрыв по HTML там минимальный, а по DOM остаётся крупным — 817 и 595 узлов. Документ такого же объёма разворачивается в куда более сложное дерево. Килобайты HTML и сложность DOM здесь явно измеряют разные свойства страницы, и один показатель нельзя использовать как замену другому.

В каких нишах топ не отдаётся краулеру

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

В среднем по выборке недоступными остаются 17,8% верхней выдачи против 8,5% хвоста, и топ закрывается сильнее хвоста в пятнадцати нишах из шестнадцати. Исключение одно — образование, там верх парсится даже легче низа, 5,0% против 7,1%.

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

Скорость ответа: почти везде верх быстрее

Третий разрез по нишам — время ответа сервера, та самая находка, которую не подтвердил браузер.

Верх отвечает быстрее в четырнадцати нишах из шестнадцати. Сильнее всего в окнах — на 257 мс, в IT-услугах на 191. Исключений два: автосервис и образование, там верх медленнее на 44 и 56 мс.

Ровная картина — причина, по которой находку я не выбросил. Но это тот же краулерный замер, разложенный по нишам, а не новая проверка: браузер разницы по-прежнему не видит. Обещать клиенту позиции за снижение TTFB на этом всё равно нельзя.

Коридор страницы, которая уже стоит в топ-10

Самая полезная цифра ниже — не медиана, а ширина разброса. 395 килобайт — середина топ-10, а 200 килобайт уже мало или ещё нормально? Поэтому ниже по каждому признаку показаны пять точек: где лежит самая лёгкая десятая часть топа, где половина, а где начинается самая тяжёлая десятая.

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

Два практических следствия. Размер HTML в топе идёт от 109 до 1525 килобайт, так что единого «правильного» веса документа в выдаче не существует. Любой аудит с порогом вроде «не больше 100 КБ» спорит не с Яндексом, а с реальностью его топа. И строка про заголовки безопасности: у четверти страниц топа их нет вообще.

Где начинается край

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

Браузерный замер 88 адресов топ-10, по три прогона с холодным кэшем, снимок 09.09.2026.

Чеклист: сверить свой сайт с топом

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

Шкала с распределением — в коридоре выше, здесь только границы и что с ними делать. Читается чеклист так. Попадание в коридор ничего не гарантирует, выход за него ничего не ломает. Это повод задать вопрос, а не поставить задачу в спринт. Дальше по каждой строке — что именно спрашивать.

Что меняется на самой странице

Что уходит в браузер

Считано по тем 88 адресам топ-10, которые открывались в браузере.

Что задаёт хост

Настройки обхода

Что чинить, хотя у топа с этим тоже плохо

Разбор реальной страницы

Правило отбора я задал до того, как посмотрел на результат. Беру страницу с позиций 31–49, у которой все шесть технических признаков лежат внутри коридора топ-10. То есть техничка идеальна по любому чеклисту, а страница внизу. Под правило подошли 58 адресов из 1370, беру самый высокий по выдаче.

deloremonta.moscow, место 31 по запросу «ремонт квартиры под ключ», ниша ремонта квартир.

Шесть из шести в коридоре. Любой технический аудит выдаст по ней зелёный отчёт, а страница болтается на тридцать первом месте. Такую страницу я бы раньше показал клиенту как образец.

Выбивается единственное — 795 слов, и это уже не техничка.

А теперь зайдём с другой стороны. Возьмём сами страницы топ-10 и посмотрим, многие ли укладываются во все шесть коридоров разом.

Что делать в четырёх ситуациях

Вот что я делаю в каждом из четырёх случаев.

Что с этим делать в 2026

Никаких «сделай X — получишь позиции». Только три категории по назначению.

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

Чего этот замер не знает

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

Ни один отдельный признак не показал сильной связи с позицией. Самый крупный коэффициент во всей работе — 0,224 при шкале от нуля до единицы. Это уровень «различает группы, но ничего не предсказывает для конкретной страницы».

Огромный технический разрыв, который виден в начале, живёт между сайтами. Стоит сравнить адреса внутри одного сайта — и большая часть различий по HTML и DOM пропадает. Что за этим стоит: бренд, ссылки, архитектура, масштаб бизнеса, поведение — замер не говорит.

Зато трактовку «сделайте страницу тяжелее, и она поднимется» он ломает всерьёз.

Методология и ограничения

Выборка. 160 запросов, 16 ниш по 10, регион Москва, 9 сентября 2026. Верхняя группа — топ-10, 1589 обработанных страниц; контрольная — позиции 31–49 через одну, 1582 страницы. После отсева заглушек бот-защиты осталось 1215 страниц с 833 доменов и 1370 страниц с 1161 домена. Пересечений по URL нет.

Направление внутри домена. Помимо парного теста по доменам я перебрал все пары «страница из топ-10 против страницы с 31–49» внутри одного сайта — 1801 пара на 111 доменах. Доля пар, где крупнее оказалась верхняя страница, — 58,0%. Метрика показывает направление, но не величину: медиана самой разницы там +11 463 байта против +157 075 между сайтами.

Проверка «дело в размере». Сайты разбиты на четыре равные группы по медианному размеру HTML их страниц в выборке, внутри каждой группы посчитана доля доменов с Clean-param отдельно для топ-10 и для позиций 31–49. В группах n = 108/285, 162/232, 187/207 и 201/193 сайта. Медианный вес страницы — грубая замена числу страниц сайта: точных данных о размере каталога в замере нет.

Как считался robots.txt. Замер идёт по сайтам: 843 в верхней группе против 1190 в нижней. 148 сайтов, попавших сразу в обе группы, из подсчёта исключены — иначе один и тот же файл голосовал бы за оба лагеря.

Как считалось. Корреляция Спирмена, n = 2585, стандартная ошибка около 0,020, порог отличимости от нуля принят как 0,06. Внутри домена: парные разницы по 111 доменам, bootstrap-интервалы на 5000 итераций, знаковый тест. Проверка по запросам: 160 разниц на уровне запроса, bootstrap по запросам. Браузерный замер: единица анализа — URL, по которому взята медиана трёх прогонов.

Пересчёт на уровне отдельных выдач. Размер HTML: медиана разницы +136 617 байт, интервал [99 757; 195 742], больше наверху в 119 запросах из 160, p < 0,001. DOM: +352,5, интервал [214; 524], 119 из 160, p < 0,001. Время ответа: −69,8 мс, интервал [−112; −27], верх быстрее в 100 запросах из 160, p = 0,002.

Почему перф-балл движка не отдельная находка. Перф-балл движка коррелирует с размером HTML на −0,847, потому что в коде штраф считается напрямую из размера документа. Это не отдельное измерение, и как отдельную находку я его не использую.

Поправка на число проверок. Шестнадцать коэффициентов проверены процедурой Бенджамини–Хохберга при уровне ложных открытий 5%. Порог проходят одиннадцать, включая длину описания с −0,056. Это ровно та ситуация, когда статистическая значимость не означает практической. К тому же p-значения посчитаны так, будто все страницы независимы друг от друга, а они сгруппированы внутри 160 выдач. Из-за этого надёжность выглядит выше, чем она есть, и ради этого сделаны отдельные проверки по запросам, по доменам и браузером.

Доступность выдачи для сбора данных. Парсинг верхней выдачи идёт тяжелее, чем парсинг хвоста, и это смещает любой конкурентный анализ на краулере. Обычному HTTP-клиенту не отдали код 200 17,8% адресов топ-10 против 8,5% на позициях 31–49. Stealth-браузер вернул около половины, недоступными остались 9,3% и 4,5%. Ещё 7,0% страниц топа против 5,4% в хвосте ответили кодом 200, а внутри отдали капчу или экран проверки браузера — формально доступны, фактически пусты. Это и есть заглушки, отсеянные из выборки. Под DDoS-Guard и Qrator наверху 21% доменов, внизу 14%.

Чего эти проценты не означают. «Недоступно стороннему краулеру» — не то же самое, что «недоступно YandexBot». Яндекс ходит с собственных адресов, которые сайты пропускают, и цифры выше говорят только о доступности для внешнего анализа. Часть блокировок относится к IP, а не к user-agent. Замер шёл с финского дата-центрового адреса, на выборке из 60 закрытых URL код ответа совпадал у браузерного и краулерного user-agent в 78% случаев, и лишь 18% открылись от одной смены user-agent. Поэтому 9,3% — верхняя оценка.

Что осталось непроверенным внутри домена. Попарно я сравнивал размер HTML и DOM, а браузерный замер парным не был. Верхняя группа тяжелее и по скриптам, +388 КБ с интервалом [68; 509], но относится ли этот разрыв тоже к различиям между сайтами, текущий тест не проверяет.

Насколько надёжен сам парный тест. 111 доменов — небольшая выборка, интервалы широкие, и верхняя граница по HTML допускает до +26 килобайт реального эффекта. Сравнение внутри домена заметно уменьшает влияние постоянных сайтовых различий, но подглядыванием за чужой выдачей остаётся. Это не эксперимент, где меняют одну переменную и смотрят результат.

Ограничения. Один регион, одна дата, один поисковик. Только технические факторы. Корреляция без причинности. 9,3% верхней группы не измерены вообще; пропуски распределены между группами неслучайно, поэтому характеристики этих страниц могут смещать оценки, но направление смещения неизвестно. Тест внутри домена слишком мал, 111 доменов дают широкие интервалы.

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

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