Расскажу честно, как коллегам за чаем, а не как методичка.
Самый обидный бан в моей практике — это не тот, что прилетел за агрессивный креатив или за слишком резкий заход. Самый обидный — когда аккаунт прогрет, отлёжка выдержана, креативы вылизаны, а тебя срезают на ревью из-за вайта. Из-за белой стороны, которую ты собрал за полчаса «лишь бы было» и забыл. Меня это бесит до сих пор, потому что 80% таких отказов — это не «алгоритм невзлюбил», а тупо забытый редирект, чужой трекер или пустая страница About.
Я занимаюсь технической частью whitepage не первый год, и вывел для себя простую вещь: модератор не читает твои тексты. Он смотрит на сигналы. Чем отдаёт сервер, что лежит в <head>, есть ли редирект, не совпадает ли твой HTML один в один с сотней таких же паков. И вот это всё палится в DevTools за десять секунд — я сам так чужие вайты «вскрываю», когда меня просят посмотреть, почему связка не идёт.
Ниже — тот самый список, по которому я гоняю белую сторону перед сдачей. Не про то, как лить. Про то, как собрать сайт, который не сольётся на технике. Где могу — добавляю, на чём сам обжигался.
1. Сначала — полный сайт, без «потом дозаполню»
На мой взгляд, это пункт номер один не случайно. Ревьюер (или его скрипт) первым делом ищет признаки «сайта не для людей». И пустая About с lorem ipsum, Coming soon, кнопка «Accept» в куки-баннере, которая ни на что не влияет — это для него как красная тряпка.
Я для себя держу минимум, который должен быть и реально работать:
главная с внятным оффером (без агрессивного «жми сюда»);
About — кто вообще стоит за проектом, хоть пара живых абзацев;
Contact с реальным способом связи;
Privacy Policy, Terms, Cookie Policy;
для финансов, крипты, здоровья — ещё и отдельный Disclaimer.
Как проверяю. Тупо прохожу по футеру руками — каждая ссылка должна вести на заполненную страницу, а не на # или void(0). Логотип в шапке — на главную. Дальше прогоняю сайт через Screaming Frog или Sitebulb, они показывают битые ссылки, дубли и страницы без контента.
И отдельно про почту: меня лично раздражает, когда «коммерческий проект» пишет контакт на Gmail или Mail.ru. Поставь e-mail на своём домене — это пять минут, а доверия к сайту сразу больше. Мелочь, а в сумме такие мелочи и решают.
2. Один HTML для всех. Это, по-моему, главное
Если бы меня попросили оставить из всего списка один пункт — я бы оставил этот. Белая страница должна быть самостоятельным продуктом, а не обёрткой над оффером.
Как только сервер начинает отдавать разный HTML под разные User-Agent, IP или гео — это и есть сигнал клоаки. Причём именно на той стороне, которую модератор как раз и крутит. Сюда же я отношу meta-refresh, location на чужой домен, <iframe> на сторонний ресурс, спрятанные в том же HTML блоки «настоящего» оффера.
И вот что я понял по опыту: палятся обычно не на хитрых схемах. Палятся на забытом после тестов редиректе. Ты что-то проверял, воткнул временный location, связка пошла — и оно так и осталось висеть. Я сам пару раз так попадал, теперь это первое, что грепаю.
Как проверяю. Делаю curl -A "Mozilla/5.0" https://мой-домен/ и сравниваю с тем, что видит обычный браузер. Содержимое должно совпадать. Потом грепаю исходник на location, meta http-equiv="refresh" и посторонние iframe. В DevTools → Network смотрю, нет ли неожиданных 30x-редиректов.
3. Чистый код — без следов чужой жизни
Как проверить чужие следы у себя (DevTools)
Открой лендинг, нажми F12 → вкладка Network, обнови страницу и отсортируй запросы по Domain. Любой коннект на незнакомый трекер-домен, чужой GTM-/G-/UA- идентификатор в gtag()/dataLayer или посторонний analytics/pixel-скрипт — это след чужой жизни в твоём коде. Во вкладке Sources тот же чек: в дереве файлов не должно быть чужих JS, в инлайне — чужих ID. Чисто должно быть пусто.
В сообществе не зря талдычат: уникальность кода критична. Скопированный один в один лендинг-пак отлично ловится по visual similarity и общим HTML-фингерпринтам — это правда.
Но я считаю, что опаснее не сам факт шаблона, а то, что в нём забывают вычистить. Чужие GA/GTM-ID. Копирайт прошлого владельца в футере. Комментарии разработчика. Дефолтный favicon и демо-страницы Elementor. Классика, на которой обжигаются все — забытое Your Company Name в сгенерённой Privacy Policy.
А самое грубое палево, которое я вижу регулярно, — это трекер арбитражной сетки прямо на белой стороне. Ребят, ну вот это вообще не из той жизни: «информационный блог», а в DevTools висит партнёрский трекер. Партнёрские теги должны быть отделены архитектурно, на белом сайте им делать нечего.
Как проверяю. Открываю DevTools → Sources и Elements, прохожусь по скриптам и ID счётчиков — всё должно быть нормальное (GA4, Яндекс.Метрика). Hero-картинку прогоняю через reverse image search: если она выдаёт клонов конкурентов — меняю. И грепаю HTML на UA-, G-, GTM- и всякое Your Company Name.
4. JS, который не мешает ревью
Практики давно заметили, и я с этим согласен на сто процентов: тяжёлый JavaScript на вайтах создаёт проблемы с модерацией, а отрендеренные на сервере страницы (тот же React с SSR) проходят заметно спокойнее.
Причина чисто техническая. Если весь контент рисуется на клиенте через CSR, то curl и краулер модератора видят пустую страницу. И это бьёт сразу с двух сторон: и подозрительно выглядит, и роняет Core Web Vitals. Плюс обфусцированные бандлы с фингерпринтом устройства там, где продукт этого вообще не требует, — для меня отдельный повод ждать отказа.
Как проверяю. Отключаю JS в браузере (или смотрю голый curl) — основной контент и тексты должны остаться на месте. Если без JS страница пустая — для вайта я бы переехал на статику или SSR/SSG. Astro, Hugo, Next.js в режиме SSG — мой личный выбор, когда нужно, чтобы краулер увидел нормальный HTML, а не белый лист.
5. Валидный SSL и ноль mixed content
Тут коротко, потому что пункт скучный, но без него никак. Просроченный, self-signed или сертификат, который покрывает только корень, — это предупреждения в браузере и mixed content на поддоменах.
Само по себе mixed content (картинка или старый виджет по HTTP на HTTPS-странице) — мелочь. Но эта мелочь стабильно роняет оценку, и обиднее всего, что чинится она за минуту.
Как проверяю. Гоняю через SSL Labs (ssllabs.com/ssltest), целюсь в A/A+, TLS 1.2 и 1.3 включены, старьё выключено. HTTPS форсится 301-редиректом с HTTP. И смотрю в консоль браузера — там не должно быть ни одного warning про mixed content.
6. Core Web Vitals в зелёной зоне
Реальный отчёт PageSpeed Insights (mobile): Core Web Vitals в зелёной зоне — LCP, INP, CLS пройдены.
Скорость — это и фактор ранжирования, и, на мой взгляд, косвенный сигнал «нормальности» сайта. Актуальные пороги Google, на которые я ориентируюсь: LCP ≤ 2,5 с, INP ≤ 200 мс (он заменил FID ещё в марте 2024), CLS ≤ 0,1.
По моему опыту, LCP чаще всего валят две вещи: несжатые PNG в hero на несколько мегабайт и подключённые «на всякий случай» 6–8 начертаний Google Fonts. А CLS — это баннеры и блоки, которые подгружаются с задержкой и дёргают вёрстку. Меня лично такие прыгающие страницы бесят и как пользователя, так что чиню их с удовольствием.
Как проверяю. PageSpeed Insights строго в mobile-режиме (он основной) плюс Lighthouse в DevTools, ориентир — Performance 80–90 на мобиле. Картинки в WebP/AVIF, loading="lazy" для всего, что ниже первого экрана, шрифты с font-display: swap, gzip/brotli и HTTP/2-3 включены.
7. Мобильная адаптивность по-настоящему, а не «вроде открылось»
Модератор вполне может открыть сайт с телефона, причём с разных. Горизонтальный скролл на узком экране, развалившийся landscape, попап, перекрывающий контент сразу после загрузки — всё это видно мгновенно.
Отдельная боль — шрифт основного текста меньше 16px на мобильном. На iOS он вызывает зум при фокусе на input, и сайт сразу выглядит криво. Я на это напарывался, теперь проверяю в первую очередь.
Как проверяю. DevTools → device toolbar, прогоняю 360px ширины и обязательно landscape. Тач-таргеты ≥ 48×48 px. И проверяю, что viewport-мета на месте: <meta name="viewport" content="width=device-width, initial-scale=1">.
8. Контент, который не выдаёт генерацию
Скажу прямо: я не против AI-контента, сам им пользуюсь. Но без редактуры он палится за километр. Фразы в духе «как языковая модель…», одинаковая до запятой структура всех статей, выдуманные факты, один и тот же текст на пяти страницах с подменой пары слов (это внутренний дубль, его тоже видно). И ревью, и алгоритмы Google к таким артефактам давно чувствительны.
Как проверяю. Уникальность ≥ 90% по text.ru или Copyscape — и тут сразу оговорюсь: проверь, что сервис на 2026-й вообще жив и не сменил модель, я этим инструментам не доверяю вслепую. Дальше — читаю текст глазами на предмет «модельных» оборотов. Картинки — свои скриншоты или стоки с указанием источника, а не reverse-search-клоны конкурентов.
9. Мета-теги и SEO-базис под оффер
Моя любимая классика отказа — title про крипту на сайте про садоводство. Это остаток от прошлой жизни домена, который забыли переписать. Контент страницы обязан совпадать с тем, что обещано в объявлении: обещал «обзор брокера» — будь добр, страница про обзоры, а не рецепты.
Плюс базовая гигиена, которую я просто держу в голове как привычку: один <h1>, <html lang="ru">, canonical, charset, alt-теги у значимых картинок.
Как проверяю. Тот же Screaming Frog показывает страницы без title/description, дубли мета, отсутствующие или, наоборот, множественные <h1>. title держу в 50–60 символов, description — 140–160. Open Graph добавляю, чтобы при шаринге было нормальное превью, а не обрубок.
10. Домен, robots и заголовки
robots.txt с Disallow: / читается ровно как «сайт не для людей» — и это, по сути, выстрел себе в ногу. Сюда же: отсутствие sitemap.xml, 404 на favicon, открытые наружу .git, .env, phpinfo.php. Вроде мелочи, но они всплывают в логах модерации и в сканерах, а значит работают против тебя.
Про домен скажу отдельно. Свежезареганный — это не криминал, а вот домен с историей дропа и сменой тематики отлично пробивается через Wayback. И правило сообщества «1 аккаунт — 1 вайт — 1 домен — 1 платёжка» я считаю не суеверием, а здравым смыслом: любое пересечение связывает всю связку, и потом «прилетает» по цепочке.
Как проверяю. robots.txt и sitemap.xml отдают 200 и ничего не блокируют. securityheaders.com — смотрю базовые заголовки (X-Content-Type-Options, Referrer-Policy, по возможности CSP). Whois плюс Wayback Machine — убеждаюсь, что у домена чистая история без чужой тематики в прошлом.
Что я в итоге для себя понял
Ревью на технике — это не «угадайка» и не лотерея, как многие в чатах любят жаловаться. Это проверяемый список. Я для себя собрал прогон из шести утилит и гоняю его до подачи, а не после бана: curl (сравнить HTML), SSL Labs, PageSpeed Insights mobile, Screaming Frog, securityheaders.com, Wayback плюс whois.
И главный мой вывод за эти годы такой: подавляющее большинство отказов на белой стороне — это не магия алгоритмов. Это забытый редирект, чужой трекер, пустая About или CSR-страница, которая краулеру кажется белым листом. Всё это чинится руками за один вечер.
Почини технику — и белая сторона перестанет быть слабым звеном твоей связки. Меня в своё время именно это сэкономило кучу прогретых аккаунтов, поэтому и делюсь.
YouTube 
Telegram 
