Коротко — да, такое встречается. Появление «Предупреждения о мошенническом сайте» в Safari при чистоте Google Safe Browsing обычно означает, что помимо публичного GSBl (Google Safe Browsing) Apple использует свои дополнительные сигнал/данные (телеметрия, локальные on‑device механизмы, собственные/партнёрские блоклисты и эвристики), и именно эти дополнительные данные либо «подсаживают» домен в список, либо заставляют локальную модель классифицировать сайт как подозрительный.
Ниже — более детально: возможные причины, что дополнительно проверить и практические шаги по снятию флага.
1) Почему Safari может помечать сайт при чистом Google Safe Browsing
- Apple использует не только GSBl. У Safari есть собственные источники/эвристики (телеметрия от устройств, машинное обучение, внутренние блоклисты и партнёрские базы), которые могут отличаться от Google по задержке обновления или по чувствительности.
- Локальное кэширование / этапная дистрибуция: часть устройств получает обновлённую базу раньше/позже → у одних баннер есть, у других нет; обновление iOS очищает часть кэша и временно убирает флаг.
- Репутация хоста/IP/ASN: даже если домен чист, хост (IP, соседние виртуальные хосты, ASN) может быть помечен за прошлые злоупотребления. Многие системы учитывают «плохие соседи».
- История домена / сертификата: если домен ранее использовался для фишинга/спама, или одинаковые/похожиe имена попадали в блоклисты, это даёт негативный сигнал.
- Внешние ресурсы: скрипты, виджеты или внешние ссылки с плохой репутацией (трекеры, платёжные шлюзы, файлохосты) на странице могут «подтаскивать» пометку.
- Поведение сайта: редиректы, скрытый контент, user‑agent‑зависимое поведение (cloaking), автоматические скачивания, необычные header‑ы — это подозрительно.
- Новизна домена и «маркетинговые» признаки: новый домен + лендинг с формой заявки + слова, типичные для фишинга/социальной инженерии, могут усиливать подозрение.
- Геополитика/провайдер: иногда блокировки/флаги зависят от региона и оттого, где размещён сервер.
2) Что проверить прямо сейчас (чеклист)
- IP/ASN репутация: проверите IP в AbuseIPDB, Talos Intelligence, Spamhaus, Sucuri, GreyNoise. Соседи по IP — проверить reverse IP.
- История домена/сертификатов: crt.sh, DomainTools / Wayback — были ли раньше другие сайты на домене или сертификаты для похожих имён.
- Внешние ресурсы: просмотреть все подключаемые скрипты/CSS/шрифты/iframe и проверить репутацию источников (VT, URLVoid, Norton, etc.).
- Clustering/обфускация: есть ли обфусцированный JS, Base64‑скрипты, динамическая загрузка исполняемого кода.
- Перенаправления и поведение по UA: curl -I и curl -A "Googlebot" сравнить с обычным браузером; проверить, нет ли условных редиректов.
- DNS/WHOIS: проверьте WHOIS/владелец (privacy protection?), SPF/DKIM не критичны для лендинга, но WHOIS с приватностью и новый домен — вызывают подозрение у автоматов.
- CT‑логи: crt.sh — нет ли множества сертификатов, похожих имён.
- Блоклисты: PhishTank, OpenPhish, SURBL, Yandex, Microsoft SmartScreen, Norton, Bitdefender и т.д. (вы уже проверяли VT и Яндекс — хорошо).
- Логи сервера: посмотреть, не было ли необычных POST/scan/пробоев и прочего.
3) Практические шаги по устранению и снижению риска FP (false positive)
- Убрать/минимизировать сторонние скрипты от непроверенных поставщиков. Если используете CDN/виджеты, временно отключите — проверить влияние.
- Перенести на «хорошо зарекомендовавший себя» хостинг/IP: протестировать через Cloudflare (proxy) или крупные облака (AWS, Google Cloud, DigitalOcean) — если предупреждение исчезнет, проблема была в IP/ASN.
- Добавить «социальные» доверительные элементы: открытая контактная страница с юридической информацией (полное название организации, адрес, ИНН/рег. данные если есть), политика конфиденциальности, публичные профили компании. Чем прозрачнее — тем лучше.
- Убедиться в отсутствии cloaking и что все пользователи и боты видят тот же контент.
- Оставить минимальную форму, показать отсутствие сбора платежей, логично подписать форму («заявка», «опрос»), убрать любую лексику, похожую на фишинговую (например «подтвердите», «необходимо немедленно» и т.п.).
- Включить HSTS, корректный TLS‑chain (проверено), HTTP security headers.
- Если сайт новый — дать ему «социальное время»: регулярно публиковать нормальный контент, получить несколько естественных ссылок с авторитетных ресурсов, верифицировать в Google Search Console и добавить sitemap.
- Сделать полную отчётную страницу (FAQ/О компании) — это помогает системам доверия.
4) Что отправлять в Apple при повторной заявке (чтобы повысить шанс реакции)
В заявке на websitereview.apple.com (и в других каналах) приложите:
- URL(ы) с предупреждением и точные даты/время и пример устройства/версии iOS/macOS, где видно предупреждение.
- Скриншоты предупреждения и страницу, заголовки ответа сервера (curl -I output).
- Результаты проверок: Google Transparency (скрин), VirusTotal, AbuseIPDB/Talos скрин, crt.sh, Sucuri — чтобы показать «веер» чистоты».
- Информацию об IP/ASN и что вы уже поменяли хост/сервер (если меняли).
- Логи запросов на момент появления предупреждения, если есть (анномализуйте IP'ы).
- Подробный список сторонних скриптов, CDN и т. п.
- Перечень мер, которые вы приняли (что именно поменяли на сайте) и просьбу пересмотреть вручную. Чем больше деталей и доказательств — тем лучше.
5) Каналы эскалации / куда ещё жаловаться
- websitereview.apple.com (вы уже отправляли) — продолжать, отправлять с полным отчётом.
- Если есть аккаунт разработчика — через Apple Developer Support (Feedback Assistant, Technical Support) можно попытаться ускорить.
- Попробуйте связаться через @AppleSupport в Twitter + приложить ссылку на форму и скрин — иногда публичные обращения привлекают внимание.
- Попросите знакомых/клиентов на разных сетях/странах протестировать и прислать скриншоты; приложите это как доказательство непоследовательного распространения флага.
- В крайнем случае — временно использовать другой домен/хостинг/Cloudflare proxy как workaround для продаж/рекламы, пока идёт разбирательство.
6) Временные обходы и тесты
- Попробуйте подключить сайт через Cloudflare (режим proxy) — у многих это решало проблему, поскольку меняется исходный IP/ASN и добавляется кэш.
- Проверьте, исчезает ли предупреждение при использовании VPN/из другой страны — это даст подсказку о региональности списков.
- Попросите несколько коллег выполнить «Очистить историю и данные сайтов» в Safari и проверить снова.
7) Ожидание и реальность
- Apple может отвечать медленно или не давать детальную причину (безопасность). Подготовьтесь к тому, что потребуется несколько заявок с улучшенными данными.
- Если причина — IP/ASN или «плохие соседи», смена хоста/Cloudflare почти всегда решает проблему за 1–2 дня (после очистки кэша). Если причина — содержание/история домена/ссылки — потребуется больше времени.
Если хотите, могу:
- составить шаблон письма/отчёта для отправки в websitereview.apple.com с перечислением всех доказательств и шагов;
- проверить конкретные вещи по вашему домену/IP (crt.sh, AbuseIPDB, Talos, поиск по CT, список внешних скриптов) — пришлите домен и IP, я быстро просмотрю и дам конкретные подсказки.
Резюме: дело почти наверняка в дополнительной базе/эвристике Apple или в репутации хоста/внешних ресурсов. Самый быстрый практический тест — поменять хост/IP (или поставить Cloudflare proxy) и повторно проверить; параллельно отправлять детализированные заявки в Apple.