На сервере, где живёт этот сайт, работают и тестовые копии рабочих проектов. Им в поиске делать нечего, поэтому прокси на входе вешает заголовок «не индексировать» на все ответы разом. Когда этот сайт пришло время открыть для поисковиков, оказалось, что снять запрет для одного сайта настройкой этого сайта нельзя.

Это десятая часть цикла «Сервер для WordPress».

Как закрыто всё

В traefik middleware с заголовком подключено не к отдельным роутерам, а ко всей точке входа HTTPS — так ни один новый тестовый сайт не забудут закрыть:

# traefik.yml
entryPoints:
  https:
    address: ":443"
    http:
      middlewares:
        - noindex@file    # X-Robots-Tag: noindex, nofollow — на всё

Это хорошее правило по умолчанию. Плохо то, что из него нет исключений.

Что не сработало

Первая мысль — на роутере нужного сайта поставить свой middleware, который очищает заголовок. Не помогает: middleware точки входа обрабатывает ответ последним и снова дописывает noindex. Роутер сайта не может отменить то, что делает точка входа.

Решение: вторая точка входа

Если запрет висит на точке входа — нужна другая точка, без запрета. Наружу она не публикуется: на неё по имени сайта пробрасывается зашифрованное соединение с основной точки.

  1. внутренняя точка https-public на порту 8443, без middleware noindex, наружу не открыта;
  2. TCP-роутер на основной точке: соединения с именем сайта в SNI пробрасываются как есть, без расшифровки, на внутреннюю точку;
  3. PROXY protocol между ними — иначе в журналах сайта вместо адресов посетителей будет 127.0.0.1;
  4. роутер сайта слушает только новую точку.
# traefik.yml — внутренняя точка
entryPoints:
  https-public:
    address: ":8443"
    proxyProtocol:
      trustedIPs: ["127.0.0.1/32"]
# providers/public-sites.yml — проброс по имени
tcp:
  routers:
    public-sites:
      entryPoints: [https]
      rule: "HostSNI(`site.ru`) || HostSNI(`www.site.ru`)"
      service: public-sites
      tls:
        passthrough: true
  services:
    public-sites:
      loadBalancer:
        servers:
          - address: "127.0.0.1:8443"
        serversTransport: proxy-v2
  serversTransports:
    proxy-v2:
      proxyProtocol:
        version: 2
# метка контейнера сайта
- "traefik.http.routers.site.entrypoints=https-public"

Последняя метка обязательна. Пока HTTP-роутер сайта слушал и основную точку, он перехватывал имя раньше TCP-роутера, и запросы шли по старому пути — с noindex.

Не потерять защиту

Всё, что было подключено к основной точке, на новой нужно подключить заново. У нас на точке висел фильтр типовых атак на WordPress — запросы к .env, перебор пользователей через REST. Его роутеры добавлены и на https-public, и проверено, что .env по-прежнему отвечает 403.

Проверка

  • корень домена — 200 без X-Robots-Tag;
  • www и http — 301 на канонический адрес;
  • остальные сайты сервера — по-прежнему с noindex;
  • в журнале сайта — настоящие адреса посетителей;
  • сертификат — тот же, что был.

Открыть следующий сайт теперь — два действия: добавить его имена в правило TCP-роутера и поставить метку точки входа.

Не забудьте и сам WordPress: «Настройки → Чтение → Попросить поисковые системы не индексировать сайт» должна быть снята, иначе запрет придёт уже из robots.txt и мета-тега.

Сайт закрыт от поиска, а где именно — непонятно?

Пришлите адрес — найду, кто ставит запрет: прокси, сервер или сам WordPress.

· полезно?
АЧ
Алексей Чикун веб-разработчик, команда TRIOHEAD

Делаю сайты и сервисы целиком: от вёрстки до сервера. Пишу о том, что проверил на своих проектах.

Комментарии

// загружаю комментарии…

Комментарии публикуются после проверки. Ссылки и HTML не принимаются.