Сменили сте адресите на продуктите, но клиент отваря запазен линк и вместо желания артикул вижда грешка. Redirect 301 е постоянно пренасочване от стария адрес към новия, с което посочвате на браузъра и търсачките, че страницата е преместена окончателно. Така старият линк може да остане полезен, вместо да прекъсне пътя към поръчката.
Самото правило е кратко. По-трудната работа е да изберете правилната крайна страница, да обхванете забравените адреси и да проверите какво се случва с рекламите и поръчките след промяната. Точно там техническата настройка се превръща в решение за надеждността на магазина.
Съдържание
- Кога да използвате 301 и кога друг код
- Как да планирате миграция с карта на пренасочванията
- Как да напишете правилото в .htaccess, Nginx или CMS
- Вериги, цикли и други грешки при пренасочванията
- Как да проверите след смяната и какво да направите следващия път
Кога да използвате 301 и кога друг код
Използвайте 301 при окончателно преместване, а не като универсална поправка за всеки неработещ адрес. При заявка към старата страница сървърът връща статус 301 и заглавката Location, която съдържа новия адрес. Браузърът сам изпраща следващата заявка и посетителят обикновено стига до целта без допълнително действие, както описва документацията на MDN за HTTP 301.
Този механизъм е подходящ при промяна на адресната структура, смяна на домейн, преминаване към защитена връзка HTTPS и обединяване на страници. Важното условие е новата страница действително да замества старата. Работещ адрес сам по себе си не означава подходящ заместител.
Кой код за пренасочване да използвате
| Случай | Код | Защо |
|---|---|---|
| Страницата е преместена окончателно на нов адрес | 301 | Новият адрес става основният, а старият пренасочва към него |
| Домейнът се сменя, например от старо име към ново .bg | 301 | Старите линкове насочват към съответните страници на новия домейн |
| Временна промяна, например сезонна страница или поддръжка | 302 | Преместването е временно, а старият адрес остава предвиденият основен адрес |
| Постоянна промяна, при която методът на заявката трябва да се запази | 308 | Запазва метода, например POST, при пренасочването |
| Страница премахната без подходящ заместител | 410 | Показва, че ресурсът е премахнат окончателно |
| Адрес, който никога не е съществувал | 404 | Връща коректен отговор за липсваща страница |
302 не е неправилен код, когато промяната е временна. Грешката е да оставите временно правило по подразбиране след окончателна миграция, без да проверите какъв отговор връща сайтът.
При форми и интеграции изборът изисква повече внимание. POST е метод за изпращане на данни, например при подаване на формуляр. Ако трябва да запазите този метод при постоянно преместване, разгледайте 308 и тествайте реалното изпращане, а не само отварянето на адреса.
Практическо правило: При постоянна промяна пренасочвайте към подходящ заместител. Ако такъв липсва, коректната страница за грешка е по-честно решение от начална страница, на която клиентът трябва отново да търси продукта.
Как да планирате миграция с карта на пренасочванията
Картата на пренасочванията е работна таблица, която свързва всеки стар адрес с конкретна нова цел. Подгответе я преди публикуването на новия сайт, когато още можете да променяте структурата без спешни поправки.
Подготовка на адресите и целите
Съберете старите адреси от различни места. Използвайте XML картата на сайта, аналитиката, Google Search Console и наличните външни препратки. XML картата, наричана sitemap, съдържа адреси за обхождане, но не бива да бъде единственият ви списък.
Съпоставете страниците по съдържание и намерение. Човек, отворил конкретна услуга, трябва да стигне до същата услуга, а не до общото представяне на фирмата. Отбелязвайте неясните случаи за преглед, вместо да ги попълвате механично.
Разделете списъка по типове. Продукти, категории, услуги, статии и кампанийни страници изискват различни решения. Добавете приоритет за адресите, които носят посещения, външни връзки или поръчки.
Проверете всяка крайна страница. Тя трябва да връща статус 200, тоест успешен отговор, и да е достъпна за индексиране. Проверете
robots.txt, който управлява достъпа на обхождащите роботи, иnoindex, който указва страницата да не се индексира.Запазете езиковото съответствие. Българска продуктова страница трябва да води към българския си заместител. Не приемайте, че английската версия е равностойна цел само защото представя същия артикул.
Изпробвайте правилата в тестова среда. Проверете крайните адреси и междинните пренасочвания преди публикуване. След старта обновете вътрешните връзки, рекламните адреси и техническите указания към търсачките.
Планирайте дългосрочно запазване. Не премахвайте правилата веднага след индексирането на новите страници. Поддържайте пренасочванията поне една година според насоките на Google за постоянни сървърни пренасочвания.
Примерна карта на пренасочванията
Следващите пътища са примерни, а не адреси на действителен сайт.
| Стар адрес | Нов адрес | Група | Решение |
|---|---|---|---|
/stara-usluga |
/nova-usluga |
Услуга | 301 към еквивалентната страница |
/kategoriya-stara |
/kategoriya-nova |
Категория | 301 към еквивалентната категория |
/kategoriya-obshta |
Няма определен еквивалент | Категория без еквивалент | Решение след преглед, без автоматично пренасочване към началната страница |
/statia-stara |
/statia-nova |
Статия | 301 към актуализираната статия |
В примерен магазин с около 300 продукта, 20 категории и 15 статии продуктовите съответствия може да са ясни, но стара обща категория да няма заместител. Тогава собственикът трябва да реши дали да запази полезна категория, да създаде подходяща страница или да премахне ресурса.
Лесно пропусканата стъпка е обновяването на собствените връзки след старта. Пренасочването осигурява достъп, но не заменя поддръжката на структурата. При по-широка промяна използвайте и насоките за редизайн на сайт със запазване на SEO, за да съгласувате адресите със съдържанието.
Как да напишете правилото в .htaccess, Nginx или CMS
Логиката е една и съща: стар път, нов пълен адрес и код за постоянна промяна. Мястото на настройката зависи от сървъра и системата за управление на съдържанието, позната като CMS. Изберете подход, който екипът ви може да поддържа и проверява.
Apache и Nginx
При Apache настройката може да бъде във файла .htaccess, когато хостингът позволява това. Следващите адреси и правила са примерни и трябва да бъдат съобразени с вашата конфигурация.
Примерно правило:
Redirect 301 /stara-usluga https://example.bg/nova-usluga
След записването проверете отговора с:
curl -I https://example.bg/stara-usluga
Командата curl -I показва HTTP заглавките. Търсете статус 301 и Location с правилната цел, след което проверете и самата крайна страница.
За съпоставяне по шаблон в Apache може да се използва RewriteRule с флагове [R=301,L]. Това е удобно при последователна промяна на цяла група адреси, но не заменя прегледа на изключенията. Поставяйте специфичните правила преди общите и не смесвайте различни подходи без проверка на взаимодействието им.
При Nginx примерното правило се добавя в съответния server блок:
location = /stara-usluga { return 301 https://example.bg/nova-usluga; }
Проверете конфигурацията с nginx -t, преди администраторът да я презареди. След това изпълнете:
curl -I https://example.bg/stara-usluga
Не редактирайте сървърната конфигурация без резервно копие и начин за възстановяване. Грешката тук може да засегне не само старата страница, а достъпа до магазина.
WordPress, WooCommerce и хостинг панел
В WordPress можете да използвате плъгин за пренасочвания, например Redirection. Примерният запис е стар път /stara-usluga, цел /nova-usluga и код 301. След запазване проверете със същия външен тест:
curl -I https://example.bg/stara-usluga
За WooCommerce подходът е приложим и към продуктови адреси. Проверявайте отделно вариантите с филтри и параметри, защото правилото за основния път не е достатъчно доказателство за тяхното поведение.
| Среда | Подходящ избор | Ограничение |
|---|---|---|
| Apache | .htaccess за сървърни правила |
Изисква внимание към наличните правила |
| Nginx | Настройка в сървърния блок | Необходим е административен достъп |
| WordPress и WooCommerce | Плъгин за управление през администрацията | Проверявайте конфликти и параметри |
| Хостинг панел | Раздел за пренасочвания при ограничен достъп | Първо проверете дали правилото вече съществува другаде |
Ако използвате раздел за пренасочвания в хостинга, не добавяйте паралелно същата настройка в плъгин. След записването отново проверете примерния адрес с curl -I https://example.bg/stara-usluga.
За предпочитаната версия с или без www и за HTTPS следвайте принципа на MDN за нормализиране чрез пренасочвания. Не копирайте общо правило за домейна върху работещ магазин без преглед на съществуващите настройки.
Вериги, цикли и други грешки при пренасочванията
Браузърът показва съобщение за твърде много пренасочвания и клиентът не стига до продукта. Това е характерен симптом на цикъл: адресите препращат един към друг, вместо заявката да завърши със страница. Например настройка за HTTPS може да противоречи на друго правило за предпочитаната версия на сайта.
Веригата е различен проблем. Старият адрес води към междинен, а той към крайния. Всяка допълнителна заявка удължава пътя до съдържанието и добавя още място за грешка, затова насочвайте стария адрес директно към окончателната цел.
Симптоми при пренасочванията, причини и корекции
| Симптом | Вероятна причина | Корекция |
|---|---|---|
| Браузърът показва твърде много пренасочвания | Цикъл, например между HTTP и HTTPS заради противоречиво правило за www |
Подредете правилата и тествайте всяка стъпка с curl -I |
| Старият адрес минава през три адреса | Верига вместо директна връзка | Насочете стария адрес директно към крайния |
| Пренасочването връща 302 вместо 301 | Временно правило или стойност по подразбиране | Сменете кода на 301 за постоянна промяна |
| Целевият адрес връща 404 | Грешен път, различна кирилица или проблем с процентното кодиране | Проверете целта и кодирането на адреса |
| Всички стари адреси водят към началната страница | Масово правило без съпоставяне по страница | Прегледайте съответствията и използвайте 410 за окончателно премахнатите без заместител |
| Старото поведение продължава след промяната | Кеш на браузъра или CDN | Изчистете кеша и тествайте в нов браузърен профил |
При адреси на кирилица проверявайте както видимия текст, така и процентното кодиране, тоест представянето на символите чрез кодирани последователности. Не разчитайте само на визуално сравнение. Проверете също главните букви и крайната наклонена черта.
Кешът е запазено копие на предишен отговор. Той може да бъде в браузъра или в CDN, мрежа за доставка на съдържание пред сайта. Затова сравнявайте резултата от браузъра с HTTP проверката, преди да заключите, че новото правило не работи.
Успешното пренасочване не означава само да няма грешка. Клиентът трябва да получи съдържанието, което старият линк му е обещал.
Ред на проверката
- Започнете с отделна страница. Проследете всеки отговор и потвърдете крайната цел.
- Проверете категория и продукт. Така ще видите дали общо правило засяга различните типове адреси по различен начин.
- Изпълнете проверка на целия списък. Отделете липсващите цели, временните кодове и междинните стъпки за корекция.
Ако проблемът обхваща повече от отделно правило, използвайте подхода за технически одит и оптимизация на сайт. Така ще разграничите грешка в пренасочването от проблем в съдържанието или индексирането.
Как да проверите след смяната и какво да направите следващия път
Преди промяната запазете базова снимка за последните три до шест месеца с органични сесии, заявки, поръчки, приходи и класирания, разделени по типове страници. След старта планирайте наблюдение поне четири до осем седмици като работен контролен период, а не като обещан срок за възстановяване. Съгласувайте този контрол с официалните насоки на Google за миграция с промяна на адресите.
Общият оборот не е достатъчен за оценка. Рекламна кампания може да прикрива спад в органичните посещения, а силна продуктова група да компенсира проблем в друга. Сравнявайте съответстващи групи и отбелязвайте паралелните промени в наличности, съдържание и кампании.
Контролен списък след публикуването
Google Search Console. Проверете отчета за страници за липсващи адреси и сравнете старите и новите страници по заявки и посещения от търсенето. Изпратете актуалната XML карта, а при смяна на домейн прегледайте приложимостта на инструмента за промяна на адреса.
Сървърни логове. Това са записи на заявките към сървъра. Потърсете стари адреси, които продължават да връщат грешки, и проверете дали правилата обхващат реално посещаваните варианти.
Google Analytics 4. Съпоставете старите и новите пътища в аналитиката. Разделете българските и английските страници, мобилните и настолните потребители, както и органичните и платените посещения.
Google Ads и Meta Ads. Обновете крайните адреси в рекламите и тествайте реалното отваряне. Проверете UTM параметрите, тоест добавките в адреса, чрез които разпознавате кампанията в аналитиката.
Поръчки и запитвания. Направете реален тест на ключовите действия. Отварянето на продуктова страница не доказва, че формата, кошницата и измерването работят правилно.
Не очаквайте redirect 301 да поправи автоматично останалите указания в сайта. Canonical посочва предпочитаната версия на страница, а hreflang свързва езиковите варианти. Проверете ги заедно със структурираното описание на съдържанието и адресите, използвани от рекламите.
Когато кодът е правилен, но поръчките намаляват
В хипотетичен магазин категория губи поръчки в продължение на две седмици след миграцията. Старият адрес връща правилния код, но води към по-обща категория, където клиентът трябва отново да избира и филтрира.
Това е проблем на съответствието, не на синтаксиса. Прегледайте продуктите и намерението зад стария адрес, след което изберете или създайте еквивалентна цел. Не добавяйте още едно общо пренасочване върху вече неподходящото.
Критерий за приемане: Новите страници са достъпни, ключовите действия работят и няма необясним спад в запитванията, поръчките и приходите по важните групи адреси.
Ако новите страници не се появяват в търсенето, използвайте отделната проверка защо сайтът не излиза в Google. Не приписвайте всеки проблем след миграцията на кода за пренасочване.
За следващата промяна поддържайте таблица стар адрес, нов адрес, код и отговорник. Изпробвайте представителна страница от всеки тип и отделяйте промяната на адреси от големи редакции на съдържанието, когато това е практически възможно. Така ще можете по-лесно да установите причината за отклонение.
Първият ви ход днес е конкретен: експортирайте адресите от аналитиката и Search Console и ги сравнете с текущата XML карта. Отбележете липсващите съответствия, преди да възложите написването на правилата.
Studio Algorithm предлага уеб разработка, техническа поддръжка и SEO, включително планиране и проверка на пренасочвания при промяна на сайт или магазин. Ако подготвяте смяна на домейн, многоезична структура или продуктов каталог, изпратете конкретния случай за обсъждане със списък на старите адреси и планираната нова структура.
Да приложим това във вашия бизнес?
Разкажете ни за сайта и целите си. Ще обсъдим подходящите следващи стъпки.
Свържете се
