HTTP статус кодове за SEO: как да управлявате премествания, изтрити страници и сървърни грешки

Когато страница бъде преместена, изтрита или временно недостъпна, сайтът трябва да даде ясен отговор както на посетителя, така и на Google.

Този отговор се предава чрез HTTP статус код.

Проблемът е, че страницата може да изглежда напълно нормално в браузъра, а сървърът да изпраща грешен сигнал. Така собственикът на сайта вижда едно, а Google получава друго.

Чести примери са:

• стара услуга води към началната страница, вместо към реален заместител;
• изтрит продукт показва празен шаблон, но връща 200 OK;
• постоянна промяна на URL е направена с временен redirect;
• сайтът е в режим на поддръжка, но всички страници връщат 200;
• важни категории периодично връщат 500, 502 или 504;
• custom 404 страница изглежда правилно, но технически връща 200;
• няколко последователни redirects забавят достъпа до крайната страница.

Тези грешки могат да доведат до отпадане на важни URL адреси, индексиране на невалидни страници, загуба на сигнали при миграция и неточни отчети в Google Search Console.

Затова най-полезният въпрос не е:

Кой код е правилен по принцип?

А:

Какво е реалното състояние на конкретния URL и какъв отговор трябва да получат потребителят и Google?

Най-важното накратко

Това е основната логика. Всички по-технически разлики имат значение само след като е изяснено реалното състояние на URL адреса.

Защо грешният статус е бизнес проблем, а не само технически детайл

HTTP статусът влияе върху начина, по който търсачките разбират жизнения цикъл на страницата.

Когато сигналът е грешен:

• важна страница може да отпадне от индекса;
• стара страница може да продължи да се обхожда;
• новата страница може да не получи очакваните сигнали;
• потребителите могат да попадат в redirect loops или нерелевантни страници;
• Google може да третира празни страници като soft 404;
• server errors могат да намалят crawling-а;
• XML sitemap може да съдържа адреси, които вече не са валидни;
• вътрешните връзки могат да продължат да водят през стари URL адреси.

При сайт с десетки хиляди продукти или филтърни комбинации една грешна template настройка може да засегне огромен брой URL адреси наведнъж.

Затова системните проблеми не трябва да се поправят страница по страница. Трябва да се установи кой шаблон, модул или server rule създава грешния отговор.

Сценарий 1: променили сте URL на важна страница

Представете си, че адресът на услуга е променен:

/stara-usluga/

към:

/nova-usluga/

Ако промяната е постоянна, старият адрес трябва да изпраща посетителя директно към новия чрез permanent redirect.

Обичайният избор е 301. 308 също е permanent redirect, но е по-важен при заявки, при които трябва да се запази request method-ът.

За стандартна публична страница най-важни са следните условия:

1. Старият URL води директно към новия.
2. Новият URL връща 200.
3. Няма междинни redirects.
4. Вътрешните връзки вече сочат към новия URL.
5. XML sitemap съдържа само новия URL.
6. Canonical на новата страница сочи към самата нея.
7. Новата страница е реален тематичен и функционален заместител.

Грешен подход е старият URL да се redirect-не към началната страница само защото тя е активна. Ако няма точен заместител, често е по-коректно да се върне 404 или 410.

Google описва server-side redirects като предпочитан метод при преместване на URL адреси. Подробностите са в официалното ръководство за redirects.

Сценарий 2: обединявате две конкуриращи се страници

Когато две страници покриват един и същ intent, понякога правилното решение е да бъдат обединени.

Тогава трябва:

• да се избере един owner URL;
• полезното съдържание да се запази в него;
• другият URL да се redirect-не към owner-а;
• вътрешните връзки да бъдат обновени;
• старият URL да бъде премахнат от sitemap;
• резултатът да бъде проверен на live сайта.

Redirect-ът не трябва да се използва като автоматична реакция при всяко сходство между две страници. Първо трябва да се потвърди, че те действително решават един и същ потребителски проблем.

Сценарий 3: изтрили сте страница без реален заместител

Не всеки 404 е SEO проблем.

Ако ресурсът вече не съществува и няма подходящ заместител, 404 е нормален и коректен отговор.

Това важи например за:

• грешно въведен URL;
• премахната кампания;
• стар файл;
• продукт или обява, които няма да се връщат;
• несъществуващ profile или listing ID;
• стар URL без релевантна нова страница.

410 Gone е по-конкретен сигнал, че ресурсът е премахнат трайно. За Google Search обаче и 404, и 410 показват, че съдържанието не е налично.

По-важно е да не се връща 200 и да не се прави нерелевантен redirect.

Как трябва да изглежда полезната 404 страница

Custom 404 страницата може да съдържа:

• ясно съобщение;
• основна навигация;
• търсене;
• линкове към важни категории или услуги;
• начин за връщане назад.

Но техническият отговор трябва да остане 404.

Добрият дизайн не превръща липсващия ресурс в валидна 200 страница.

Сценарий 4: страницата изглежда като грешка, но връща 200

Това е типичният soft 404 проблем.

Сървърът казва:

Страницата съществува и е заредена успешно.

Съдържанието казва:

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

Чести примери:

• изтрит продукт с празен шаблон;
• страница с текст "Няма намерени резултати";
• SPA route, който визуално показва 404;
• несъществуващ URL, който зарежда началната страница без redirect;
• празна категория;
• автоматично генериран profile URL без реален профил.

Soft 404 може да доведе до:

• обхождане на невалидни URL адреси;
• объркващи Page indexing отчети;
• индексиране на празни или безполезни шаблони;
• грешна оценка на системите за monitoring;
• натрупване на content debt.

Корекцията зависи от реалното състояние:

• ресурсът съществува - върнете пълно съдържание с 200;
• преместен е - използвайте permanent redirect;
• премахнат е без заместител - върнете 404 или 410;
• временно не работи - използвайте подходящ 5xx;
• достъпът е защитен - използвайте правилен access control.

Не добавяйте произволен текст само за да изглежда страницата по-пълна. Status и съдържанието трябва да описват една и съща реалност.

Сценарий 5: имате временна промяна

Temporary redirect е подходящ, когато старият URL остава основният адрес и пренасочването ще бъде отменено.

Обичайните кодове са 302 и 307.

Примери:

• временна landing page;
• краткосрочна operational промяна;
• временно routing решение;
• контролирана A/B реализация;
• временно пренасочване към информационна страница.

307 запазва request method-а. За стандартна GET страница разликата често не е съществена за собственика на сайта.

Основният въпрос е дали промяната наистина е временна.

Не използвайте 302 за постоянна миграция само защото CMS го създава по подразбиране.

Сценарий 6: сайтът е временно в поддръжка

Когато сайтът или важна секция са временно недостъпни, правилният статус обикновено е 503 Service Unavailable.

Пример:

HTTP/1.1 503 Service Unavailable
Retry-After: 3600

Потребителят може да вижда нормална maintenance страница с обяснение. Сървърът обаче трябва да показва, че състоянието е временно.

Защо 200 е грешен при maintenance

Ако всички URL адреси връщат еднаква maintenance страница с 200, Google може да я обработи като нормално съдържание.

Това създава риск от:

• duplicate maintenance pages;
• soft 404;
• временно заместване на title и content;
• неточни Search Console отчети;
• загуба на нормалния output при crawl.

Защо 503 не трябва да остава дълго

503 е временен сигнал.

Ако остане продължително:

• Google може да намали crawling-а;
• важни URL адреси могат постепенно да отпаднат;
• потребителите ще продължат да виждат недостъпност;
• monitoring системите ще отчитат продължителен outage.

След приключване на поддръжката трябва да се направи live проверка на критичните URL адреси.

Сценарий 7: сайтът периодично връща server errors

Кодовете 500, 502 и 504 показват различни server или infrastructure проблеми, но за собственика на сайта най-важни са обхватът и продължителността.

Трябва да се установи:

• единична ли е грешката;
• засяга ли конкретен template;
• засяга ли целия сайт;
• появява ли се при високо натоварване;
• свързана ли е с deployment;
• засяга ли важни money pages;
• получава ли Googlebot различен response;
• има ли повтарящ се pattern в server logs.

500 Internal Server Error

Обикновено показва application проблем, например:

• PHP fatal error;
• database failure;
• plugin conflict;
• memory exhaustion;
• template crash;
• deployment грешка.

502 Bad Gateway

Често показва проблем между proxy, gateway и application server.

504 Gateway Timeout

Означава, че междинният server не е получил навременен отговор. Причината може да е бавна database заявка, претоварен backend или външна зависимост.

Единичен кратък error не означава автоматично трайна SEO загуба. Системните и продължителни грешки са реалният риск.

Google посочва, че при 5xx и 429 може временно да намали crawling-а. Продължителните server errors могат да доведат до премахване на URL адреси от индекса.

Сценарий 8: защитата на сайта блокира Googlebot

401 и 403 са нормални за private ресурси, но са проблем, когато се появят на публични страници.

Причината може да е:

• WAF правило;
• bot protection;
• IP restriction;
• hosting firewall;
• geo restriction;
• грешни file permissions;
• прекалено агресивен rate limit.

Не приемайте автоматично, че Google има проблем с достъпа. Проверете security и hosting logs.

Не whitelist-вайте crawler само по user-agent string. Реалните Googlebot заявки трябва да бъдат проверени по официалния начин.

Redirect chains и loops

Redirect chain

Chain възниква, когато стар URL води към междинен адрес, който води към следващ.

/old-url/ -> /old-target/ -> /new-target/ -> /final-url/

Практическата цел трябва да бъде:

/old-url/ -> /final-url/

Chains създават:

• допълнителни server requests;
• по-бавен достъп;
• по-голям риск от timeout;
• натрупване на стари правила;
• по-трудна диагностика;
• остарели вътрешни връзки.

Redirect loop

Loop възниква, когато URL адресите се пренасочват циклично:

/a/ -> /b/ -> /a/

Причината често е конфликт между:

• WordPress;
• hosting настройки;
• HTTPS правила;
• language plugin;
• trailing-slash правила;
• application router;
• cache.

Loop-ът прави страницата недостъпна и трябва да се третира като критичен проблем.

Какво означават основните групи кодове

За повечето собственици на сайтове не е необходимо да запомнят всеки HTTP код. Полезно е да разбират петте групи:

Най-често срещаните SEO решения са свързани с 200, 301, 302, 404, 410, 429, 500 и 503.

Google публикува отделно обяснение как HTTP статус кодовете влияят на crawlers.

200 OK не гарантира индексиране

200 означава, че заявката е обработена успешно и съдържанието е върнато.

Това не означава, че Google задължително ще индексира страницата.

Причините може да включват:

• duplicate съдържание;
• избран друг canonical URL;
• липса на самостоятелна стойност;
• слаб intent match;
• noindex;
• rendering проблем;
• липса на вътрешни връзки;
• soft 404 съдържание.

Status code описва server response-а. Той не оценява качеството или полезността на страницата.

Как да проверите реалния статус

Не разчитайте само на това, което виждате в browser window. Браузърът често следва redirects автоматично и показва само крайната страница.

Browser DevTools

В Network panel проверете:

• initial document request;
• status;
• redirect sequence;
• Location header;
• final URL;
• response headers;
• failed resources.

Command line

За основните headers:

curl -I https://example.com/page/

За redirect trace:

curl -I -L --max-redirs 10 https://example.com/old-page/

Проверете и нормален GET request, защото някои server конфигурации обработват HEAD различно.

Site-wide crawler

Crawler може да открие:

• вътрешни links към 3xx;
• 4xx destinations;
• 5xx страници;
• redirect chains;
• loops;
• soft 404 candidates;
• sitemap URL адреси с грешен status.

Server logs

Logs показват какво реално получава Googlebot:

• честота на 5xx и 429;
• templates с повтарящи се errors;
• стари redirects, които продължават да се обхождат;
• Googlebot requests към 404;
• различен response според user agent.

Google Search Console

Google Search Console може да покаже:

• soft 404;
• not found 404;
• server error 5xx;
• redirect проблеми;
• last crawl;
• URL Inspection резултат.

Search Console не заменя live HTTP проверката. Данните могат да отразяват по-старо обхождане.

Status, sitemap, canonical и вътрешни връзки трябва да съвпадат

Една коректна URL система изпраща последователни сигнали.

За активна страница:

• URL връща 200;
• canonical сочи към същия owner URL;
• sitemap съдържа този URL;
• вътрешните връзки водят директно към него.

За преместена страница:

• старият URL връща permanent redirect;
• redirect target-ът връща 200;
• sitemap съдържа target-а;
• вътрешните връзки са обновени;
• няма chain.

За премахната страница без заместител:

• URL връща 404 или 410;
• не присъства в sitemap;
• вътрешните връзки са премахнати или поправени.

Canonical не е заместител на redirect. Noindex не е заместител на 404. Redirect към homepage не е заместител на lifecycle решение.

Как да приоритизирате проблемите

Приоритетът не се определя само от кода. Важни са:

• броят засегнати URL адреси;
• ролята им за бизнеса;
• трафикът;
• вътрешните и външните връзки;
• продължителността;
• template обхватът;
• вероятността проблемът да се повтори.

Практически checklist за собственик на сайт

• [ ] Важните страници връщат реален 200.
• [ ] Изтритите страници без заместител връщат 404 или 410.
• [ ] Постоянно преместените URL адреси използват 301 или 308.
• [ ] Временните премествания използват 302 или 307.
• [ ] Redirect targets са реални заместители.
• [ ] Няма redirects към началната страница без тематична причина.
• [ ] Няма chains и loops.
• [ ] Internal links водят директно към крайните URL адреси.
• [ ] Sitemap не съдържа 3xx, 4xx или 5xx.
• [ ] Custom 404 страницата връща 404, не 200.
• [ ] Maintenance mode връща 503.
• [ ] След maintenance 503 е премахнат.
• [ ] Периодичните 5xx се проверяват в server logs.
• [ ] Security layer не блокира публични страници за Googlebot.
• [ ] SPA routes връщат правилен status.
• [ ] Cache не обслужва стар redirect или error response.

При seo-webdesign.bg кеширащият plugin е WP Rocket и няма CDN. След промени трябва да се проверява live response-ът и при нужда да се отчете WP Rocket cache, без да се предполага външен CDN слой.

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

Трябва ли всички 404 страници да бъдат пренасочени

Не. Redirect е правилен само когато има реален и релевантен заместител. При липса на такъв коректният 404 или 410 е по-добър от пренасочване към homepage или несвързана категория.

По-добър ли е 410 от 404

410 е по-конкретен сигнал за трайно премахнат ресурс. За Google и двата статуса означават, че съдържанието не е налично. Не е необходимо масово да заменяте всички 404 с 410.

Кой е по-добър за SEO: 301 или 308

Google третира и двата като permanent redirects. За стандартни web страници 301 е по-разпространен. 308 е важен, когато request method-ът трябва да се запази.

Кой е по-добър: 302 или 307

И двата са temporary redirects. 307 запазва request method-а. За стандартна GET страница изборът обикновено е operational, не SEO shortcut.

Гарантира ли 200, че страницата ще бъде индексирана

Не. 200 означава, че съдържанието е върнато успешно. Google може да не индексира страницата поради duplicate content, canonical, noindex, rendering или липса на полезност.

Може ли maintenance страница да връща 200

Технически може, но това е грешен сигнал. За временно недостъпен сайт използвайте 503.

Влияят ли server errors на SEO

Да, когато са продължителни или системни. Google може да намали crawling-а, а важни URL адреси могат постепенно да отпаднат от индекса.

Кога е необходим SEO одит

Единичен грешен redirect може да бъде лесна поправка. Системен проблем изисква повече доказателства.

Пълен SEO одит е необходим, когато:

• много URL адреси връщат грешни status codes;
• има redirects от различни системни слоеве;
• Search Console показва ръст на soft 404 или 5xx;
• sitemap и live status не съвпадат;
• SPA routes връщат 200 за несъществуващи страници;
• WAF или hosting защита блокира crawler-и;
• проблемът засяга templates, а не единични страници;
• предстои migration или масова промяна на URL адреси.

Одитът трябва да свърже crawl данни, server logs, Search Console, sitemap, redirects, canonical и реалното business състояние на URL адресите.

Когато е необходима реална implementation работа и последващо наблюдение, SEO оптимизацията изпълнява приоритизираните промени и проследява резултата след повторно обхождане.

Заключение

HTTP статус кодовете не са списък с числа, който собственикът на сайта трябва да запомни.

Те са начин сайтът да каже ясно:

• тази страница съществува;
• преместена е;
• липсва;
• временно не работи;
• достъпът е ограничен.

Най-опасни са несъответствията между status, съдържание и реално състояние.

Error страница с 200, постоянна миграция с 302, maintenance страница с 200 и нерелевантен redirect към homepage скриват проблема, вместо да го решат.

Полезната проверка започва от бизнес решението за URL адреса и завършва с live доказателство, че server response, съдържанието, sitemap, canonical и вътрешните връзки работят като една система.

Официални източници

• HTTP status codes and Google crawlers
• Redirects and Google Search