Сайтът се отваря за хора, но роботът получава 403: как да проверите CDN и защитата

Страницата се отваря нормално на вашия телефон, но инструмент за обхождане получава 403. Това е възможно, когато CDN, WAF, сървър или плъгин прилагат различни правила според заявката. Преди да редактирате SEO текста, установете кой слой отказва достъп и дали засегнатият посетител е действително търсещ робот.

Какво означава HTTP 403 в тази проверка

403 означава отказан достъп. Статусът не казва сам по себе си кой го е отказал или дали това е грешка. За административен адрес отказът може да е правилен; за публична продуктова страница към легитимен търсещ робот може да е нежелан.

Проверете и отговори 200, които съдържат само защитна проверка вместо страницата. Успешният HTTP статус не доказва, че ботът е получил полезното съдържание. Снимка на вашия браузър също не представя условията на автоматизираната заявка.

Съберете данни преди промяна

Запазете поне една успешна и една неуспешна заявка към същата публична страница. Отбележете разликите, без да заключавате предварително, че причината е „SEO настройка“.

Как да проверите дали това е Googlebot

Низът „Googlebot“ в User-Agent може да бъде подправен. Google публикува методи за проверка чрез актуални IP диапазони или обратен DNS, последван от forward DNS до първоначалния IP. Съпоставяйте с правилната категория crawler или fetcher: не всички заявки от Google имат една и съща роля.

За други платформи използвайте техните официални методи за идентификация. Не прилагайте правило за Google автоматично към всеки AI робот. Различните системи могат да извършват търсене, извличане по потребителска заявка или други дейности, за които собственикът на сайта има различна политика за достъп.

CDN, WAF или origin: къде е отказът?

1. Потърсете заявката в наличните security events на CDN и вижте действието и съответното правило.
2. Съпоставете със server access и error логовете.
3. Ако заявката е спряна преди сървъра, започнете от защитния слой.
4. Ако достига сървъра и той връща 403, проверете сървърни правила, права за достъп и защитни плъгини.
5. Ако данните липсват, проверете обхвата, периода и ограниченията на логването; липсата на запис не е окончателно доказателство.

Техническа проверка към origin може да бъде полезна за администратор с разрешен достъп и правилна конфигурация. Не разкривайте origin адреса публично и не променяйте защитата му като общо решение.

Какво да проверите в защитните правила

Възможните причини включват custom WAF правило, ограничение по държава или мрежа, bot защита, rate limiting, защитен път или сървърна конфигурация. Установете кое правило е съвпаднало с реалната заявка. Наличието на Cloudflare не доказва, че той е източникът на отказа.

Cloudflare поддържа сигнали за verified bots, но наличието им не прави всички собствени правила автоматично съвместими. При нужда използвайте ограничено изключение за правилния публичен път и потвърдения тип заявка. Skip действието има конкретен обхват и ред на изпълнение; проверете кои продукти и проверки действително може да пропусне във вашия план и конфигурация.

Не създавайте глобално „Allow“, основано на съдържащ се в заглавката текст. Не изключвайте всички защити за сайта, когато проблемът е едно правило. Запишете промяната, очаквания резултат и начин за връщане.

Robots.txt, noindex и canonical решават други задачи

HTTP отказът възниква при достъпа. Robots.txt управлява допустимото обхождане за спазващите го роботи; noindex и canonical имат отделни роли при обработка на съдържанието. Промяна на meta description не поправя блокирана заявка.

След като достъпът работи, проверете дали самата публична страница има желаните robots директиви и canonical, дали robots.txt е достъпен и дали основното съдържание присъства. Разрешаването на робота не гарантира индексиране, позиция или включване в AI отговор.

Проверка след поправката

• Повторете засегнатия реален тест към същия URL.
• Проверете крайния статус, пренасочванията и получения HTML.
• Потвърдете в логовете, че правилото вече не блокира легитимната заявка.
• Проверете представителни страници и robots.txt, а не само началната.
• Уверете се, че административните и чувствителните пътища остават защитени.
• Следете повторни откази и последващите сигнали за обход и индексиране.

Локален тест с подменен User-Agent може да покаже как реагира едно правило, но не доказва достъп на истинския робот от неговата инфраструктура. Използвайте го като помощна диагностика, а не като финално потвърждение.

За следващите проверки вижте защо сайтът не се индексира в Google. DigitaL+ свързва техническо SEO с достъпност и индексиране в AI търсачки. Общият подход към видимостта е в AEO и GEO без обещания за автоматично класиране.

Често задавани въпроси

Щом браузърът ми отваря сайта, роботът има ли достъп?

Не непременно. Браузърът може да премине проверка, да има бисквитка или да идва от различна мрежа.

Да разрешим ли всички автоматизирани посетители?

Не е нужно. Определете кои публични ресурси искате да са достъпни и за кои проверени категории заявки.

403 винаги ли е причината за липса на индексиране?

Не. Той е конкретен проблем за достъп. След поправката могат да останат други технически или съдържателни причини, които трябва да се проверят отделно.