Валидатор RSS-ленты

Валидатор W3C проверяет синтаксис ленты — и делает это очень подробно. Но он ничего не знает о том, как лента ведёт себя в жизни: доступна ли она по HTTPS, отдаёт ли сервер 304 Not Modified, не уводит ли адрес по цепочке редиректов, как выглядят записи и соберётся ли из ленты письмо. Мы проверяем и синтаксис, и весь этот транспортный слой, а сверх того — пригодность ленты для email-рассылки, чего нет ни в одном валидаторе. Отчёт на русском, с объяснением каждой ошибки, а не только с номером строки.

RSS 2.0 (и старые ветки 0.91/0.92), RSS 1.0 на RDF, Atom 1.0 по RFC 4287, Atom 0.3 (с предупреждением об устаревании) и JSON Feed 1.0/1.1. Формат определяется автоматически по корневому элементу — указывать его руками не нужно. Правила проверки для каждого формата свои: в RSS даты должны быть в RFC 822, в Atom и JSON Feed — в RFC 3339, и валидатор не путает одно с другим.

Укажите адрес сайта. Если по нему отдаётся HTML-страница, мы разберём её разметку и найдём в ней ссылку вида <link rel="alternate" type="application/rss+xml"> — именно так ленту находят браузерные расширения и читалки. Дальше проверка пойдёт уже по найденному адресу, и он будет виден в отчёте. Если такой ссылки на странице нет, валидатор об этом скажет: это само по себе проблема, из-за неё вашу ленту не найдут ни агрегаторы, ни подписчики.

Сервисы email-рассылок умеют превращать новые записи ленты в письма — это называется RSS-кампания. Но их требования строже, чем спецификация RSS: например, картинку поста рассылка Dashamail берёт только из тега <enclosure type="image/…">, и если у вас изображения переданы через media:content или просто <img> внутри описания — в письме будет пустое место. То же с датами: неразобранный pubDate означает, что рассылка не поймёт, какие посты новые, и выпуск вообще не уйдёт. Этот блок показывает такие вещи заранее и перечисляет, какие макросы шаблона письма у вас заработают.

Читалки и агрегаторы опрашивают ленту постоянно — от раза в час до нескольких раз в минуту, и делают это тысячи клиентов сразу. Если сервер отдаёт ETag или Last-Modified и корректно отвечает 304 Not Modified на условный запрос, при отсутствии новых записей передаётся несколько сотен байт вместо всей ленты. Без этого каждый опрос — полная выгрузка. Мы не просто смотрим наличие заголовков, а делаем повторный запрос и проверяем, что сервер действительно отвечает 304.

Старт — 100 баллов. Нарушения спецификации стоят дороже всего: отсутствующий обязательный элемент, неверный формат даты, неэкранированный HTML в описании, дубликаты идентификаторов. Дешевле — рекомендации и best practices: нет atom:link rel="self", нет guid, лента не сжимается, не отсортирована по убыванию даты. Проблемы с пригодностью для рассылки тоже снижают оценку. Вердикт: «валидна» — нарушений спецификации нет, «с замечаниями» — есть предупреждения, «невалидна» — есть ошибки, из-за которых лента сломается у части потребителей.

Да — переключитесь на вкладку «Вставить XML» и вставьте содержимое ленты целиком, до 2 МБ. Все проверки синтаксиса, спецификации, содержимого и пригодности для рассылки отработают точно так же. Пропустятся только те, для которых нужен живой HTTP-ответ: коды состояния, редиректы, Content-Type, сжатие и заголовки кэширования. Это удобно, когда лента ещё на стенде за авторизацией или генерируется скриптом.

Каждая проверка получает постоянную ссылку и хранится 24 часа — её удобно приложить к задаче для разработчика или отправить в поддержку CMS. Повторная проверка того же адреса в течение суток отдаёт результат из кэша мгновенно. Лимиты — 5 проверок в минуту и 30 в сутки с одного IP, размер загружаемой ленты — до 5 МБ, вставки — до 2 МБ. Приватные и служебные адреса (localhost, 10.x, 192.168.x и подобные) намеренно не проверяются.