Поддержка сайтов / Влад Ухов

Фейковые сертификаты для Google — что это значит для вашего сайта

Прочитал у xakep, что злоумышленники получили фейковые TLS-сертификаты для Google и других сервисов через атаку на национальные доменные зоны .gh, .sl и .as. Атака позволила обходить проверку владения доменом — хакеры меняли DNS-записи и получали действительные сертификаты для чужих сайтов, включая крупные бренды. Сертификаты были заблокированы в Chrome, но не во всех браузерах, и отозвать их официально — долгий процесс. Важно: это не уязвимость самого сайта, а слабое место в процедуре выпуска сертификатов, которое может повториться в любой момент. Считаю, что это не просто «кейс», а сигнал: если у вас есть домен в любой национальной зоне, особенно с открытым DNS, риск утечки контроля над сертификатом реален. Даже если ваш сайт не пострадал — браузеры не проверяют, кто владеет доменом, а только, есть ли у него сертификат. И если он есть, но не ваш — вы уже не тот сайт, который видит пользователь. На мой взгляд, главная угроза — не в том, что кто-то взломал сервер, а в том, что кто-то может выдать себе сертификат для вашего домена, не имея доступа к нему. Это не фишинг, это прямое нарушение доверия к HTTPS. И это может случиться с любым, кто не защищает DNS-записи и не настроил CAA. Уже начал проверять у клиентов: есть ли у них CAA-записи, и разрешены ли только проверенные УЦ. У тех, у кого их нет — в план на неделю добавил настройку. Не жду, пока браузер заблокирует, а закрываю причину заранее.

Почему ИИ не знает о вашем сайте

В подборке за неделю встретил статью про то, как нейросети читают сайты — и понял, что это не про «контент», а про то, как он доходит до ИИ. Это меняет всё. Почему ИИ не знает о вашем сайте Прочитал статью, где рассказывали, что ChatGPT называет трёх конкурентов, хотя сайт в топе поиска. На первый взгляд — странно. Но потом понял: нейросеть не читает сайт как человек. Она получает контекст из того, что дошло до её инфраструктуры. А если контент не дошёл — значит, он для неё не существует. Считаю, что это важнее, чем SEO-оптимизация. Если сайт не виден ИИ-ассистентам, он теряет доступ к новому трафику — и к доверию, которое ИИ передаёт пользователям. Как ИИ на самом деле читает сайты Нейросети не «заходят» на сайт. Они берут фрагменты из уже проиндексированных данных. Краулеры ИИ — это не браузеры. Многие из них не выполняют JavaScript. Значит, если сайт собирается в браузере, а сервер отдаёт пустой HTML, ИИ получает каркас — и ничего больше. На мой взгляд, важнее другое: не сколько текста, а где он лежит. Если контент в исходнике — он может быть извлечён. Если он появляется только после скриптов — он для ИИ невидим. Это не ошибка, а архитектурная особенность. Как проверить, что ИИ видит ваш сайт Я уже начал проверять это первым делом. Открываю исходный код страницы — не через инспектор, а через «Просмотреть исходный код» в браузере. Если ключевые данные — заголовки, цены, описание — не видны в HTML, значит, до ИИ они не дойдут. Проверяю через curl с user-agent GPTBot. Если в ответе — только теги и скрипты, а текста нет — проблема в рендеринге. Это не про «плохой контент» — это про то, что контент не в том месте. Что я делаю, когда ИИ не видит сайт Сначала не лезу в тексты. Сначала проверяю, что сервер отдаёт. robots.txt, WAF, логи — всё это может блокировать ИИ-краулеров. Потом смотрю, как рендерится страница. Если клиентский рендеринг — пререндерим критичные блоки: контакты, цены, основные абзацы. У себя сделал так: для ключевых страниц генерирую статику на этапе сборки. Остальное — по-старому. Это не требует переписывания всего сайта, но даёт результат сразу. Что здесь даёт поддержка На нашей поддержке это закрывается заранее. Мы не ждём, пока ИИ не знает о сайте — мы проверяем, что он может его прочитать. Каждый месяц — проверка доступности, рендеринга, файлов разметки. По моему опыту, сайты, которые понятны ИИ, выглядят лучше и в поиске, и в результатах. Они не просто «оптимизированы» — они построены так, чтобы быть видимыми. Это не про технические фишки — это про понятность. работаем с 2002 года, более 100 клиентов по всему миру. Приглашаю на бесплатный аудит сайта — проверим, как он виден ИИ-ассистентам.

4,2% сайтов медклиник закрыты от индексации в поиске. На этих сайтах robots.txt или тег noindex запрещают Яндексу и Google индексировать сайт целиком: он выпадает из выдачи, а органический трафик и заявки падают до нуля. Чаще всего это забытая настройка тестового сервера. Замер: сентябрь 2026. Выборка для анализа — 5368. Рейтинг качества сайтов медицинских клиник авторства Влада Ухова — https://medicine-rating.ukhov.su #SEO #индексация #сайты #сайтымедцентровухов

Яндекс восстанавливает сервисы после атаки на дата-центр

Утром попалось на глаза — Яндекс объявил о постепенном восстановлении сервисов после атаки БПЛА на дата-центр во Владимире. Повреждения затронули не только внутреннюю инфраструктуру, но и работу множества сайтов в российском интернете: от Магнита и Дикси до TimePad и Спортс. В компании заявили, что сначала восстанавливают самые востребованные сервисы, а часть функций, включая массовое скачивание файлов в Диске, временно отключили для снижения нагрузки. Некоторые сервисы, вроде Яндекс Метрики и Пэй, до сих пор недоступны. На мой взгляд, это не просто технический сбой — это напоминание, что даже у крупнейших игроков есть уязвимые точки. Падение сервисов в масштабе не связано с багами в коде, но приводит к тем же последствиям: сайт не работает, клиенты уходят, позиции падают в поиске. Я уже проверил, какие из наших клиентов используют Яндекс-сервисы — и добавил их в список мониторинга, чтобы не пропустить сбои. Важно не ждать, пока сайт упадёт, а видеть это раньше. Считаю, что отключение массового скачивания в Диске — это не просто техническое решение, а сигнал: когда инфраструктура под угрозой, приоритет — не функциональность, а стабильность. У нас это означает, что даже если сайт работает, но медленно или с ошибками — это тоже падение. Проверяю у клиентов, как ведёт себя сайт при нагрузке, и включаю оповещения на 5xx, 404 и таймауты. Согласен с тем, что сбои в одном дата-центре могут затронуть сотни сайтов. Это не про «хакеров» — это про риски, которые нельзя игнорировать. Уже начал обновлять резервные копии у всех, кто использует облачные сервисы, и проверяю, не зависят ли их сайты от одного узла. Следующая неделя — план по проверке архитектуры у тех, кто ведётся на одном хостинге.

Поисковики и ИИ выбирают понятные сайты

Утром попалось на глаза, как ателье превращает поисковые запросы в заказы. Не просто «ремонт одежды» — а «подшить джинсы на Войковской». И тут в голове всплыл вопрос: а что, если ваш сайт не видят, потому что не умеет говорить с поисковиками и ИИ? Начало не в технических деталях — а в том, как сайты становятся видимыми для тех, кто ищет. Поисковики и ИИ выбирают понятные сайты Попалось на глаза, как ателье снимает видео процесса ремонта — и это работает. Не просто фото, а объяснение, почему шов должен быть аккуратным. Понятно, что поисковики это оценят. Но не только. ИИ-ассистенты, которые теперь цитируют сайты в ответах, выбирают те, где контент не просто есть, а понятен, структурирован и говорит о деле. Это не про «заполнение полей» — это про то, чтобы сайт не был пустой витриной, которую никто не видит. Я уже начал проверять, как у клиентов размечены страницы. Особенно — главная, карточки услуг и страница контактов. Если нет микроразметки, даже если контент хороший — поисковик не поймёт, что это за бизнес. ИИ-ассистенты вообще могут его не учитывать. Что тут вообще происходит Сейчас поисковики и ИИ-ассистенты не просто сканируют текст. Они ищут сигналы: что это за бизнес, где он находится, что предлагает, как работает. Это не про ключевые слова — про структуру. Например, если на главной нет разметки Organization с логотипом и ссылкой на соцсети, поисковик не поймёт, кто вы. Если нет Service или LocalBusiness — не поймёт, какие услуги и где. А если нет Open Graph — даже соцсети не покажут нормальную миниатюру. Даже простая разметка, как og:title или FAQPage, уже даёт преимущества. ИИ-ассистенты используют эти сигналы, чтобы ответить на вопрос «где починить джинсы в Москве?» — и выбирают сайты, которые «говорят на одном языке». Как понять, что это касается вашего сайта Проверяю первым делом: открыта ли главная страница без JavaScript? Если нет — ИИ-ассистенты видят пустоту. Проверяю, есть ли в robots.txt запрет на GPTBot или ClaudeBot — если да, сайт исключён из индексации ИИ. Проверяю, есть ли в корне файл llms.txt — это сигнал, что сайт готов к индексации ИИ. Если нет микроразметки на главной, карточке товара или странице контактов — это уже не просто «недостающая фича», а риск быть незамеченным. Я считаю, что если отсутствует хотя бы одна из ключевых разметок — это проблема. Особенно если сайт не обновляется давно. Что я делаю в таких случаях Сначала делаю резервную копию. Потом — проверяю, что разметка добавляется через серверный рендер, а не через JavaScript. Если сайт на WordPress — вставляю разметку через плагин или вручную в шаблон, чтобы она была в HTML-коде. Не вставляю в через JS — это не видно ИИ. Проверяю, что все важные страницы (главная, услуги, контакты) имеют: заголовок, описание, изображения с alt-текстами, ссылки на соцсети, логотип. Если нет — добавляю. Если сайт на 1С-Битрикс — использую встроенные возможности, но проверяю, что всё выходит в коде, а не в JS. Что здесь даёт поддержка На постоянной поддержке я закрываю эту задачу так: после каждого обновления сайта — проверяю, что разметка есть и работает. Это не разовый аудит, а часть процесса. Мы не просто «поставим» метки — мы обеспечиваем, чтобы они оставались актуальными, даже если сайт меняется. Поисковики и ИИ-ассистенты выбирают понятные и здоровые сайты. А сайт, который «говорит» на их языке, — это не просто SEO. Это возможность быть найденным в нужный момент, когда клиент уже решает, кому доверить вещь. работаем с 2002 года, более 100 клиентов по всему миру. Сайты не просто «работают» — они живут. И мы следим, чтобы они не теряли видимость. Приглашаю на бесплатный аудит сайта — проверим, как он выглядит для поисковиков и ИИ-ассистентов.

Пароль — не про сложность, а про случайность

Утром попалось на глаза, как статья про пароли объясняет, почему «P@ssw0rd!2026» — это не защита, а приглашение. И понял: всё, что кажется безопасным, может быть ловушкой. Особенно если это на вашем сайте. Пароль — не про сложность, а про случайность Читал статью про то, как пароли вроде «корова-лампа-поезд-ромашка» устойчивы, а P@ssw0rd!2026 — нет. И понял: дело не в том, насколько он выглядит «сложным», а в том, как он был создан. Если человек придумал его, он уже предсказуем. А если случайно — то даже если выглядит просто, он надёжный. На мой взгляд, главная ошибка — считать, что сложность в символах. На деле — в случайности. И это касается не только пользователей, но и системы: если сайт требует «символ, цифра, заглавная» — он не защищает, он только направляет к шаблонам. А шаблоны — это уже не защита, а дверь. Как это устроено — и почему система может быть сломана Пароли не хранятся как есть. Они превращаются в хеш — длинную строку, которую нельзя обратно прочитать. Но если хеш быстрый, его можно перебрать за секунды. А если медленный — то даже за миллионы лет не получится. И тут ключевое: не столько длина пароля, сколько скорость подбора. Я проверяю это у клиентов: смотрю, какой алгоритм хеширования используется. Если это что-то старое — типа MD5 или SHA-1 — уже не годится. А если нет — значит, система может быть взломана, даже если пароль кажется надёжным. И это не про «кто-то взломал», а про то, что утечка данных — вопрос времени. Как понять, что это касается вашего сайта Проверяю первым делом: как настроена регистрация. Если есть требования вроде «должна быть заглавная, цифра, символ» — это красный флаг. Не потому что это плохо, а потому что это ведёт к одинаковым шаблонам. И если у вас есть форма заявки — вы уже оператор персональных данных, и это отдельный риск. Если сайт на старой платформе, особенно с устаревшими настройками безопасности — вероятность, что пароли хранятся слабо, растёт. У нас это входит в регулярную проверку — не по поводу сбоя, а по поводу уязвимости. Проверяю не «а вдруг», а «а вдруг уже есть». Что с этим делать — и как я это проверяю Сначала — не ломать, а смотреть. Проверяю, какой алгоритм хеширования используется. Если старый — предлагаю заменить. Если нет — включаю проверку на устаревшие настройки. Потому что даже если пароль кажется надёжным, система может быть слабой. Дальше — не только настройки. Я смотрю, как пользователи придумывают пароли. Если видно, что все используют «имя+123» или «@» вместо «а» — это сигнал. И тогда я включаю проверку на уязвимые шаблоны. Не по поводу взлома, а чтобы не дать повода. Что здесь даёт поддержка На постоянной поддержке я закрываю эту задачу не разово, а системно. Проверяю, как хранятся данные, как настроена регистрация, как обрабатываются пароли. И если что-то устарело — меняю, не дожидаясь утечки. Работаем с 2002 года, более 100 клиентов по всему миру. И да — мы не просто «включаем» защиту. Мы смотрим, как она устроена. И если что-то может быть сломано — мы его меняем. До того, как это станет проблемой. Это не про «мы починим», а про то, чтобы не думать об этом вообще.

ИИ-агенты уже сканируют ваш сайт — и это не про «хакеров», а про боты, которые не устают

Наткнулся на разбор о том, как ИИ-агенты теперь находят уязвимости за час, а не за неделю. Это не про «хакеров, выбранных для атаки» — это про боты, которые сканируют всё, что можно. И если у вас есть слабое место — оно уже найдено. О чём речь и почему я считаю это важным для сайта Наткнулся на разбор о том, как ИИ-агенты теперь способны за час найти то, что раньше требовало недель. Это не про кибер-шпионов с мониторами, а про системы, которые методично перебирают всё: конфиги, доступы, устаревшие плагины. Я считаю, что это важно потому, что уязвимость — это не «что-то, что может случиться». Это уже случилось, только ещё не обнаружено. И если боты могут найти дыру за 10 часов, то сайт уже не в безопасности — он в зоне риска. Как это устроено — что тут вообще происходит Представь: бот не ищет «важные» страницы. Он сканирует всё. Даже те, что никто не открывал. Даже те, что не ведут никуда. Он пробует десятки вариантов — с разными параметрами, с разными путями. И если у тебя есть устаревший плагин, открытый доступ или слабый пароль — он найдёт. И это не случай. Это системный процесс. ИИ не устаёт, не сомневается, не пропускает. Он просто пробует. Как понять, что это касается вашего сайта («как я это проверяю») Я смотрю на то, что может быть уязвимо в любом сайте: устаревшее ПО, открытия в конфигах, плагины без обновлений, формы с открытым доступом. Проверяю не только по списку, а по поведению: если сайт хоть раз попал в VirusTotal с меткой «вредоносный» — это сигнал. Если в коде есть скрипты, которые не должны быть — это тоже. Что с этим делать («что я делаю в таких случаях») Я не просто удаляю вредоносный код. Я ищу, откуда он попал. Проверяю, где был открыт доступ. Проверяю, какие плагины устарели. Потом — закрываю дыру. Обновляю всё, что нужно. Проверяю, не осталось ли вредоносных скриптов в скрытых файлах. И не останавливаюсь. Потому что если не закрыть причину — вредоносный код вернётся. Что здесь даёт поддержка На нашей поддержке мы не просто починяем — мы закрываем причину. Потому что заражение — это не «случай». Это результат уязвимости, которую боты находят за секунды. У нас мониторинг каждые несколько минут, 24/7. Это значит, что если что-то пойдёт не так — мы узнаем раньше, чем вы. И не просто узнаем. Мы уже начали действовать. Бесплатный аудит безопасности — это просто. Проверим, что у вас в порядке.

Версия для слабовидящих: доля сайтов медклиник без версии для слабовидящих за месяц выросла с 63,2% до 63,5%. август 2026 → сентябрь 2026, изменение +0,3 п.п. В штуках: 17 759 из 28 081 → 18 344 из 28 895 проверенных сайтов. Выборка для анализа — 28895. Рейтинг качества сайтов медицинских клиник авторства Влада Ухова — https://medicine-rating.ukhov.su #динамика #доступность #слабовидящим #сайты #сайтымедцентровухов

SSL-сертификат от GlobalSign: риск для медицинских клиник

Разобрал свежий срез рейтинга «Клиник-Радар» — за сентябрь 2026 года проверено 26 793 сайтов, проблема с безопасностью обнаружена у 12,7% из них. SSL-сертификат от GlobalSign: риск для медицинских клиник 12,7% — это не просто цифра. Это почти каждый восьмой сайт в отрасли. Для клиники, где доверие — основа, это тревожный сигнал. Пациент заходит на сайт, чтобы найти врача, узнать цену, записаться — и видит предупреждение в браузере. Даже если он не понимает, что это значит, он уходит. Не потому что не хочет, а потому что не доверяет. Когда сайт становится «небезопасным», он теряет доверие. Пациенты не оставляют заявки, не жмут на «записаться». А ведь именно через сайт клиника получает новых пациентов. И если это происходит системно — бизнес страдает. Уверен, что для руководителя это не просто технический нюанс, а прямой удар по репутации и доходу. Почему это критично для клиники Сайт — это первый контакт с пациентом. Если он выглядит подозрительно, человек не дождётся, пока увидит цену или расписание. Он уходит. И это не про «всего один ушедший». Это про сотни потенциальных записей, которые не состоялись. Доверие к клинике, построенной на профессионализме, начинается с того, как выглядит сайт. Когда браузер блокирует доступ, это не просто «неприятность». Это потеря доверия, которое трудно вернуть. Особенно в медицине, где пациент выбирает клинику не по цене, а по ощущению безопасности. Если сайт не защищён, он не вызывает доверия — даже если в реальности всё в порядке. Как понять, что это касается вашего сайта Если сайт использует SSL-сертификат, выпущенный западным центром — GlobalSign, риск существует. Это не про технические сложности. Это про то, что сертификат может быть отозван или не продлён из-за санкционного режима. И тогда сайт в один день перестанет быть безопасным. Первым делом смотрю, какой УЦ выдал сертификат. Если это западный, то ставлю это в план — проверить, заменить, закрыть риск. Не жду, пока пользователь уйдёт. Делать это нужно заранее. Убеждён, что лучше устранить проблему до того, как она станет публичной. Как я закрываю такие риски у клиентов Следю за тем, чтобы сайт открывался без ошибок, чтобы сертификат был актуальным и выдан российским центром. Это часть поддержки — не просто «всё работает», а «всё работает и безопасно». Проверяю, обновляю, закрываю риски до того, как они повлияют на пользователей. Поставил в план — регулярно проверять сертификаты у всех клиентов. Это не разовое действие. Это постоянная работа. Уверен, что безопасность сайта — это не вопрос «а что, если» — это вопрос «когда» и «как».

Уязвимый WordPress: доля сайтов медклиник на уязвимой версии WordPress за месяц снизилась с 4,7% до 4,5%. август 2026 → сентябрь 2026, изменение −0,2 п.п. В штуках: 253 из 5 339 → 249 из 5 478 проверенных сайтов. Выборка для анализа — 5478. Рейтинг качества сайтов медицинских клиник авторства Влада Ухова — https://medicine-rating.ukhov.su #динамика #безопасность #WordPress #CVE #сайтымедцентровухов