Как сделать сайт-каталог сайтов: структура и проверка в 2026

Сайт-каталог сайтов лучше начинать не с сотен ссылок, а с одной узкой темы, одной категории и небольшого набора проверенных карточек. Минимальная версия должна хранить данные отдельно от шаблона, не публиковать пользовательские добавления без модерации, распознавать дубли адресов и показывать дату последней проверки.

Какой каталог здесь строится

Речь о справочнике внешних сайтов: например, сервисов для дизайна, музеев региона или инструментов для малого бизнеса. Это не интернет-магазин, не поисковая система по всему интернету и не копия чужого каталога.

Правило выбора ниши: вы должны уметь сформулировать единый критерий включения и регулярно перепроверять каждую карточку. Если критерий звучит как «все полезные сайты», тема слишком широкая. Сузьте её по задаче, аудитории или региону. Общую сборку страницы можно сверить с инструкцией как сделать сайт самому с нуля.

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

Карта результата и границы минимальной версии

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

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

Схема данных для одной карточки

Данные карточки не должны жить только внутри HTML. Отдельная запись позволяет менять шаблон без ручной правки каждой страницы, проверять обязательные поля и искать дубли. Минимальный объект может выглядеть так:

{
  "id": "design-tools-example",
  "name": "Название сервиса",
  "url": "https://example.org/",
  "normalized_url": "https://example.org/",
  "category": "design-tools",
  "summary": "Что делает сайт и кому подходит.",
  "language": "ru",
  "status": "review",
  "checked_at": "2026-08-13",
  "source": "editorial"
}

id остаётся стабильным при переименовании. url хранит переход, normalized_url служит для поиска дублей, status управляет публикацией, а checked_at показывает свежесть проверки.

По теме: Как сделать женский сайт без стереотипов в 2026 году

Как убрать дубли адресов до публикации

Один ресурс может прийти с HTTP или HTTPS, с www, якорем либо рекламными параметрами. Нормализация должна быть осторожной: привести имя хоста к нижнему регистру, убрать фрагмент после #, удалить только известные рекламные параметры и выровнять завершающий слеш. Путь и значимые параметры не удаляйте, они могут обозначать другой раздел.

Разбирайте адрес стандартным URL-парсером, а не регулярным выражением. Конструктор URL() создаёт объект URL и отклоняет невалидный адрес ошибкой, что описано в документации MDN. Но синтаксическая валидность не доказывает, что сайт безопасен или принадлежит заявленному владельцу.

1. Примите адрес только с протоколом http или https и разберите его URL-парсером.
2. Сохраните исходную строку, затем приведите имя хоста к нижнему регистру и уберите фрагмент.
3. Удалите только заранее известные метки перехода, не очищайте все параметры.
4. Сравните нормализованный адрес, домен и название с каталогом и очередью.
5. При совпадении обновите существующую карточку или отправьте заявку редактору.

Если одна и та же страница каталога открывается по адресам с сортировкой и фильтрами, выберите основной URL. Google объясняет, что параметры сортировки часто создают дубли, а редирект и rel="canonical" служат сильными сигналами выбора основной версии: руководство по каноническим URL. Не закрывайте дубли в robots.txt вместо канонизации.

Очередь модерации вместо автоматической публикации

Используйте состояния draft, review, published, rejected и needs-check. Публичная страница читает только published. При отказе сохраняйте причину, чтобы повторная заявка не создала тот же спор заново.

1. Проверьте обязательные поля на сервере и найдите дубли.
2. Откройте сайт вручную в отдельном профиле браузера.
3. Сверьте назначение и важные свойства с официальной страницей.
4. Отредактируйте описание своими словами и выберите категорию из закрытого списка.
5. Только после проверки смените статус на published и запишите дату.

Проверку формы повторяйте на сервере. OWASP рекомендует список разрешённых значений вместо попытки перечислить все запреты: руководство по проверке ввода. Категорию и статус выбирайте из закрытого списка.

Как проверять внешние ссылки безопасно

Не заставляйте сервер автоматически ходить по любому адресу из формы. Пользовательский URL может привести его к локальному или служебному ресурсу. Руководство OWASP по SSRF предупреждает, что полные URL трудно валидировать, а редиректы могут обходить исходную проверку.

• Разрешайте только http и https.
• Блокируйте localhost, частные, служебные и link-local адреса для IPv4 и IPv6.
• После каждого редиректа повторяйте проверку нового адреса.
• Ограничьте время ответа и размер данных, не выполняйте внешний JavaScript.
• Используйте автоматический результат только как сигнал для редактора.

По теме: Как сделать макет сайта: от структуры до проверки в 2026

Какие rel ставить у внешних ссылок

Редакционная ссылка на проверенный источник не требует специального rel. Ссылку из пользовательской карточки помечайте rel="ugc", а при недостатке доверия добавляйте nofollow. Google прямо рекомендует ugc для пользовательского содержимого и допускает комбинацию ugc nofollow: официальная справка Google о внешних ссылках. Платное размещение нужно помечать sponsored, а не маскировать под редакционный выбор.

<a href="https://example.org/" rel="ugc nofollow">Название сайта</a>

Разметка ItemList для списка

Каталог делайте обычным видимым HTML. Дополнительно можно добавить JSON-LD типа ItemList: Schema.org определяет его как список объектов с элементами itemListElement: канон ItemList. Разметка должна повторять видимый порядок.

{
  "@context": "https://schema.org",
  "@type": "ItemList",
  "name": "Каталог сервисов для дизайна",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "item": {
        "@type": "WebSite",
        "name": "Название сервиса",
        "url": "https://example.org/"
      }
    }
  ]
}

Проверьте JSON-LD в валидаторе Schema.org. Валидный синтаксис не обещает специальный вид в поиске, а только подтверждает читаемость разметки.

По теме: Как сделать виджет на сайте в 2026: iframe, script или код

Проверяемый чек-лист перед запуском

• Критерии включения и дата обновления видны на странице.
• Карточки берутся из данных, а не продублированы в шаблоне.
• Повторная заявка не создаёт вторую карточку.
• Черновики и отклонённые записи не видны публично.
• Пользовательские ссылки имеют ugc, недоверенные также имеют nofollow.
• JSON-LD совпадает с видимым порядком, а фильтры не создают бесконтрольные дубли.
• Каталог читается на телефоне, данные резервируются, карточку можно быстро снять.

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

Частые сбои и диагностика

Если появились дубли, сравните исходный и нормализованный URL. Если ссылки устаревают, переводите самые давние в needs-check. При спаме отключите автопубликацию и ограничьте частоту заявок. Если фильтры попали в индекс, сверяйте canonical, внутренние ссылки и sitemap. Когда выбирать становится трудно, сократите категории и добавьте измеримые поля сравнения.

Когда каталог сайтов не подходит

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

Частые вопросы

Нужна ли база данных для первого каталога?

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

Можно ли публиковать ссылки автоматически?

Не стоит. Автоматическая проверка доступности не подтверждает соответствие теме, владельца и качество описания. Первая версия должна отправлять заявку в очередь редактора.

Нужно ли ставить nofollow на все сайты?

Нет. Для редакционных проверенных ссылок специальный атрибут не требуется. Пользовательские ссылки помечайте ugc, недоверенные можно дополнительно пометить nofollow, платные размещения требуют sponsored.