Три различни количества

Физическата наличност е това, което е отчетено в склада. Резервираното количество е заделено за конкретни операции. Продаваемото количество е това, което позволявате на канала да предлага според правилата на бизнеса.

Примерна формула е „продаваемо = физическо − резервирано − защитен запас“. Тя е условна: складовата система може вече да връща свободно количество и второ изваждане ще е грешка. Запишете значението на всяко поле преди разработване.

Източник на истина и посока на обмена

Двупосочно обновяване без собственик може да върне стара стойност към правилната система. Избягвайте цикъл „магазин → склад → магазин“, който няма правило за версия и произход.

Стабилните продуктови ключове са задължителни

Съпоставете SKU, вариант, мерна единица и склад. Един продукт, продаван на брой и на пакет, не може да използва една стойност без ясно преобразуване. Комплект може да зависи от наличността на няколко компонента.

Проверете липсващи и дублирани ключове. Не свързвайте продукти само по име. Ако идентификаторът се променя, актуализирайте съпоставянето контролирано, за да не получите нов запис вместо обновяване на съществуващия.

Пример с две едновременни поръчки

Условният склад има една продаваема бройка. Двама клиенти виждат наличност и започват поръчка. Ако системата само чете числото и го намалява по-късно, и двамата могат да получат потвърждение.

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

Дори обновяване всяка секунда не премахва този риск, ако проверката и резервирането не са съгласувани.

Повторения и събития извън реда

Известия могат да пристигнат повторно или със закъснение. Повторена операция не трябва отново да намали наличността. Стар snapshot не трябва да презапише по-ново потвърдено състояние.

Използвайте идентификатори на операции, версия или друг поддържан механизъм за подреждане. Само часът на клиентския компютър не е надежден универсален ред. Записвайте какво е получено, обработено и отхвърлено като остаряло.

Отмяна, връщане и неуспешно плащане

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

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

Възстановяване след прекъсване

1. Отбележете кога обменът е спрял и кои операции са засегнати.
2. Запазете необработените събития с уникални ключове.
3. Възстановете връзката без дублиране на вече изпълненото.
4. Сверете наличностите с актуалния източник.
5. Отделете несъответствията за проверка.
6. Уведомете екипа за поръчки, които изискват действие.

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

Критерии за приемане на интеграцията

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

За онлайн магазини DigitaL+ свързва интеграции с WooCommerce решения. Изборът на технология е отделна тема в n8n или готова интеграция; първо опишете бизнес правилата за наличност.

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

Колко често да обновяваме наличностите?

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

Защитният запас решава ли проблема?

Може да намали риска, но не поправя грешни ключове, повторни операции или лоша логика.

Достатъчен ли е успешен импорт?

Не. Проверете действителните крайни количества и поръчки, включително след изключения.

Кои задачи трябва да изпълни менюто?

Менюто не е само списък с имена. Гостът проверява дали ресторантът предлага подходяща храна, колко ще струва посещението и къде да резервира. Някои хора търсят конкретна категория, други разглеждат целия избор или се нуждаят от версия на друг език.

Започнете с пет задачи: намиране на основни ястия, проверка на цена, прочит на описание, смяна на език и преминаване към резервация. Оценявайте времето и затрудненията при изпълнение, а не само дали файлът изглежда красиво на голям екран.

PDF и HTML: практическо сравнение

HTML не е автоматично добър: тежки снимки, неудобни раздели и меню като една голяма картинка могат да направят уеб страницата също толкова трудна. PDF с достъпен текст и добро оформление е по-полезен от нечетим скан.

Шаблон за полезно HTML меню

Организирайте съдържанието по действителни категории: салати, основни, десерти и напитки според ресторанта. За всяка позиция покажете име, кратко описание, приложима информация за размер или грамаж и актуална цена с ясна валута. Специални предложения обозначавайте с период или наличност.

Не заменяйте важна информация с изображение. Използвайте логични заглавия, четим текст и връзки към секциите. При дълго меню навигацията трябва да позволява бърза смяна на категория, без да закрива съдържанието.

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

Актуалните данни са по-важни от формата

Определете кой редактира цените и кога промените се публикуват. Ако сайтът, PDF и менюто на място се поддържат отделно, създайте контролен списък за съответствие. Гостът не трябва да гадае коя версия е валидна.

След редакция проверете QR кода, публичната страница, файла за изтегляне и кеша. Стар PDF, запазен в браузъра, може да продължи да се показва. Дайте видима дата на актуализация, когато тя помага да се разбере версията.

Езикови версии и връзка с резервацията

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

Покажете резервацията на логично място и уточнете какво следва: директно потвърждение или заявка към ресторанта. При няколко обекта запазете контекста на избрания адрес. Телефонът трябва да е удобен за натискане, ако приемате резервации по телефона.

Мобилен тест преди публикуване

1. Отворете QR кода на обикновен телефон през мобилна връзка.
2. Намерете конкретна категория без увеличение.
3. Прочетете дълго описание и сравнете две позиции.
4. Проверете цените и смяната на език.
5. Преминете към резервация и се върнете към менюто.
6. Проверете нова редакция на цена и наличност от друг браузър.

Измервайте отваряне на меню, използване на навигацията и започнати резервации при допустимо проследяване. Не приемайте изтеглянето на PDF за реализирано посещение.

За ресторанти и заведения DigitaL+ свързва UX анализ с локално SEO. Общите проверки на конверсиите са в ръководството за CRO и UX; тук началната задача е четимо меню и ясен път до резервация.

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

Трябва ли да премахнем PDF менюто?

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

QR кодът решава ли проблемите с менюто?

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

HTML менюто гарантира ли по-добри позиции?

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

Какво влиза в базовата оперативна поддръжка

Започнете от резервните копия: колко често се създават, къде се пазят, какъв е срокът за съхранение и кога е тествано възстановяване. Копие, което никога не е възстановявано, не е доказан план за възстановяване. След това уточнете обновленията на WordPress, темата и плъгините; критичните разширения се тестват спрямо конкретните функции на сайта. Официалната документация на WordPress за обновяване е отправна точка, но реалният процес зависи от настройките и зависимостите на вашия сайт.

Проверявайте функции, не само наличността на началната страница

Сайтът може да се зарежда и пак да губи запитвания. Договорете проверки на контактна форма, имейли, мобилно меню, ключови страници, аналитични събития и, ако продавате онлайн, процеса за поръчка. При сайт с персонализирани интеграции проверявайте дали данните пристигат там, където трябва.

Запишете кой получава сигнал при грешка и какво е работното време за реакция. „24/7 наблюдение“ и „24/7 човек, който поправя“ са различни услуги.

Разделете дефект, редакция и нова функционалност

Собственост и възстановяване

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

Как да оцените месечния отчет

Полезният отчет описва извършени обновления, проверени функции, инциденти, резервни копия, оставащи рискове и предложения, за които трябва решение от собственика. Броят „обновени плъгини“ без проверка на сайта казва малко. Ако планирате редизайн, прочетете и кога промяната решава бизнес проблем; поддръжката и редизайнът имат различни задачи.

За конкретен обхват на наблюдение и реакция разгледайте поддръжка на уебсайт от DigitaL+.

Примерна месечна проверка

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

Уточнете срока за реакция на различни проблеми

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

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

Дайте на всеки кандидат едно и също задание

Опишете приблизителния брой продукти и варианти, нужните езици, типовете клиенти, начина на обработка на поръчка и задължителните външни системи. Изпратете примери за реален продукт с варианти, доставка до адрес или офис, плащане, фактура, връщане и продукт, който временно не е наличен. Ако магазинът заменя стар, добавете списък с важните URL адреси и съдържанието за пренасяне.

Без тези входни данни изпълнителите ще попълнят неизвестното с различни предположения. Това прави цените привидно сравними, но резултатът вече не е един и същ.

Таблица за сравнение на офертите

Проверете интеграциите на реален сценарий

„Интеграция с ERP“ не казва дали се прехвърлят наличности, цени, поръчки, клиенти или всички тези данни. Запишете кой е източникът на истина за всяко поле и какво става при забавяне или дублиране. Поискайте тест със запис в двете системи, преди да приемете проекта.

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

SEO не започва след пускането

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

Приемете проекта по проверими критерии

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

Изборът между платформи разгледайте отделно в WooCommerce или Shopify за български магазин. Ако вече имате задание, екипът на DigitaL+ за онлайн магазини може да го оцени по реалните интеграции и задачи, които проектът изисква.

Пет приемателни теста преди финално плащане

1. Създайте поръчка от телефон за продукт с вариант и промоция.
2. Проверете неуспешно плащане: статусът на поръчката, наличността и съобщението към клиента трябва да са съгласувани.
3. Променете наличност в основната система и проверете кога магазинът я показва.
4. Отворете няколко стари URL адреса, ако има миграция, и проверете дали водят до най-подходящите нови страници.
5. Изпратете тестова заявка или поръчка и я проследете в аналитичната и административната система.

Добавете тези проверки като приложение към договора. Ако дадена интеграция изисква трета страна да предостави достъп, запишете кой носи отговорност и как се променя графикът при забавяне.

Въпрос за собствеността

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

Диагностика преди проект

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

Кога по-малка промяна е достатъчна

Една добра услуга с неясно заглавие и липсващи доказателства може да се подобри без нова тема и миграция. Бавна страница може да има проблем в изображенията или скриптовете. Счупен път до контакт може да изисква поправка на формата. CRO и UX анализът помагат да проверите тези хипотези.

Кога редизайнът е оправдан

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

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

Инвентаризирайте адресите с трафик и връзки. Когато URL трябва да се промени, планирайте еднозначен наследник, пренасочване и проверка след пускане. Google предупреждава за възможни колебания при значими промени; следвайте официалните насоки. Вижте и нашата карта за миграция и услугата за редизайн.

Разход: начална оферта срещу цена на притежаване

За WooCommerce сравнете хостинг, разработка, платени разширения, обновления, защита и човек, който поддържа магазина. За Shopify проверете плана, приложенията, таксите според платежното решение, интеграциите и евентуална индивидуална разработка. Цените и условията на доставчиците се променят, затова вземете актуални оферти за вашия случай вместо таблица с универсални суми.

Интеграции в България: проверявайте конкретно

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

Каталог, съдържание и SEO

Тествайте варианти, филтри, категории, продукти без наличност и многоезичност с реални примерни записи. Проверете кои URL адреси се създават, как работят canonical сигналите и дали можете да изградите самостоятелни полезни категории. Ако магазинът вече има органичен трафик, инвентаризирайте адресите преди миграция. Вижте нашето ръководство за SEO на категории и филтри.

Как се взема решение без скъп грешен избор

1. Опишете десет критични сценария за магазина.
2. Изградете пробен каталог с реални варианти, доставки и плащания.
3. Оценете цена и ресурс за поддръжка за 12–24 месеца.
4. Проверете кой е собственик на данните и как се изнасят.
5. При миграция тествайте продуктовите URL адреси и пренасочванията.

За преминаване между платформи официалните инструкции на Shopify и на Google са важни източници за конкретните стъпки.

Кога да потърсите изпълнител

Ако имате сложни интеграции или съществуващ каталог с органичен трафик, изисквайте техническо задание и план за миграция преди избор на платформа. Вижте подхода ни за изработка на онлайн магазин и публикувания ни пример за миграция; казусът показва тип работа, а не обещава същия резултат за всеки магазин.

След избора на платформа сравнете и конкретния обхват: контролният списък за оферти за онлайн магазин покрива интеграции, права и приемателни тестове.

Начална страница: ориентиране, не каталог

За няколко секунди човек трябва да разбере какво правите, за кого и къде може да види доказателство. Началната страница може да води към ключовите услуги, казуси и форма, но не е нужно да повтаря целия текст на всяка услуга. Ако обслужвате различни индустрии, опишете реалната разлика в проблемите и процеса, а не правете почти еднакви страници със сменено име на отрасъла.

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

Читателят иска да прецени дали проблемът му е същият, дали подходът ви е приложим, какво ще бъде направено, какви зависимости има и защо да ви се довери. Използвайте кратък отговор в началото, последван от конкретен обхват, сценарии, ограничения, начин на работа и връзка с казус. За темите, които искат подробно обучение, посочете отделна статия. Така SEO архитектурата и търговската страница имат различни роли.

Формата трябва да събира полезен контекст

Попитайте за цел, мащаб и основно ограничение, но не превръщайте първия контакт в дълъг въпросник. Ако продавате проект по индивидуална оферта, обяснете какво ще стане след изпращането: кой отговаря и каква информация ще е нужна за следваща среща. Проверете форми, телефон и мобилно поведение с реално тестово запитване.

Казусите доказват обхват, когато показват метод

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

Измерване и стартиране

Преди пускане определете основните целеви действия, направете карта на старите и новите URL адреси при редизайн, проверете мобилното показване и събитията в анализа. След пускане сравнявайте не само посещенията, а и квалифицираните запитвания по страница. Ако планирате нов корпоративен сайт, подгответе услугите и критериите за подходящ клиент още преди дизайна.

Започнете от page types

Homepage, service page, category, product и article имат различни bottleneck-и. Изберете representative URLs и измервайте всеки template отделно.

LCP: какво е най-голямото съдържание над fold

Hero image, large heading или video често определят LCP. Оптимизирайте real asset dimensions, preload само когато има смисъл и не зареждайте огромно desktop изображение на mobile.

INP: взаимодействието зависи от JavaScript

Heavy sliders, trackers и builder scripts могат да блокират main thread. Преди да добавите още animation library, проверете дали interaction-ът има реална UX стойност.

CLS: резервирайте място

Images, embeds, cookie bars и динамично content injection могат да разместват layout-а. Width/height, aspect-ratio и стабилни placeholders са базови controls.

Performance budget преди дизайн

• максимален hero asset размер;
• брой font files/weights;
• allowed third-party scripts;
• JS budget за critical interaction;
• image formats и responsive source policy.

Не гонете само laboratory score

Lighthouse е диагностичен инструмент. Field data показва как реалните потребители преживяват сайта. Разглеждайте CrUX/Search Console данни, когато има достатъчно traffic, и комбинирайте с RUM при по-зрял setup.

Cache е последният, не първият слой

Page cache, CDN и minification помагат, но не могат да направят огромен hero asset малък или да премахнат ненужна interaction логика. Оптимизирайте design и payload преди caching layer.

За архитектурата вижте изработка на сайт с SEO архитектура.

Най-евтиният performance fix е елементът, който решавате да не зареждате още в design phase.

Първата задача е URL inventory

Съберете всички известни URL-и от текущия сайт, не само тези в sitemap. Полезни източници са XML sitemap, CMS export, analytics landing pages, Search Console, backlink tools, server logs и crawl на текущия сайт.

За всеки URL отбелязваме поне:

• текущ status code;
• indexability и canonical;
• page type и основен intent;
• organic clicks/impressions, когато данните са налични;
• backlinks или външни mentions;
• нов еквивалент;
• решение: keep, 301, merge, 404/410.

Не сменяйте URL само защото дизайнът е нов

Редизайнът не е причина да променяме адрес, който вече е логичен, кратък и натрупва сигнали. Ако старата `/uslugi/seo-optimizatsiya/` остава основната страница за SEO услугата, най-сигурното решение е да запазим URL-а и да сменим съдържанието и дизайна зад него.

Това намалява redirect зависимостта и риска от временна загуба на сигнали. Именно по тази логика се проектира и SEO архитектурата преди дизайн.

Кога 301 е правилният избор

Permanent redirect има смисъл, когато старата страница има ясен нов наследник със същото или много близко потребителско намерение. Пример: стара отделна страница за Instagram Ads може да се консолидира към нова Meta Ads страница, ако тя реално покрива Facebook и Instagram и отговаря на очакването на потребителя.

Кога да не използвате 301

Ако услугата е премахната и няма реален заместител, redirect към homepage или произволна услуга е лош user experience и може да се интерпретира като soft 404. В такъв случай честен 404 или 410 често е по-доброто решение.

Избягвайте redirect chains

Ако A вече redirect-ва към B, а при новия redesign B трябва да стане C, актуализирайте A → C директно. Chains увеличават crawl overhead, забавят потребителя и усложняват бъдещия maintenance.

Internal links трябва да сочат към финалния URL

301 е safety net за стари сигнали и външни входове, не вътрешна навигационна стратегия. След migration crawl-нете сайта и заменете всички internal links, които минават през redirect.

Проверете header, mega menu, footer, breadcrumbs, related services, blog content, CTA блокове, sitemap и structured data references.

Canonical и robots QA

Всеки важен нов landing page трябва да има self-referencing canonical, освен ако има умишлена consolidation логика. Проверете дали staging noindex не е останал в production и дали robots.txt не блокира важни assets или директории.

• 200 canonical page → canonical към себе си;
• 301 URL → няма нужда от indexable page markup;
• 404/410 → noindex е приемлив допълнителен сигнал, но status code е основният;
• sitemap → само canonical, indexable, 200 URLs.

Schema и breadcrumbs също са част от migration

Ако URL hierarchy или page type се променя, обновете BreadcrumbList, Service/Product/Article relationships и всички hardcoded @id references. Structured data не трябва да продължава да сочи към retired URL.

Tracking трябва да преживее redesign-а

Промяна на form markup, button classes или checkout може да счупи selector-based tracking. Преди launch направете inventory на GA4/GTM events и ги валидирайте на новите templates. Когато е възможно, предпочитайте dataLayer events пред крехки CSS selectors.

Pre-launch crawl

1. Crawl-нете staging с финалната URL структура.
2. Сравнете URL inventory с redirect map.
3. Проверете всички вътрешни links за 3xx/4xx.
4. Проверете title, H1, canonical, robots и structured data.
5. Проверете sitemap само с final URLs.
6. Тествайте mobile и performance на ключовите templates.
7. Валидирайте analytics и conversion events.

Post-launch monitoring

След launch следете server/analytics/Search Console сигнали за 404, redirect issues, indexing changes и спадове по важни landing pages. Не променяйте redirect map хаотично всеки ден — първо потвърдете причината.

За техническата страна вижте Technical SEO, а за самата услуга — миграция на уебсайт.

Добрата SEO миграция не се опитва да запази всеки стар URL на всяка цена. Тя запазва правилните сигнали и прави новата архитектура по-ясна от старата.

Започнете от задачите, не от менюто

„Начало, За нас, Услуги, Контакти“ не е информационна архитектура. За service business трябва да разберем кои решения се търсят, кои услуги имат самостоятелен commercial intent и кои теми трябва да бъдат supporting content.

Например общата страница „SEO оптимизация“ може да бъде hub, а Technical SEO, SEO audit и eCommerce SEO да са отделни specialist pages. Ако всички са еднакви вариации на текста, архитектурата е формално голяма, но семантично плоска.

URL design: стабилност пред clever naming

Добрият URL е четим, кратък и устойчив. Не е нужно да съдържа всяка keyword вариация. По-важно е да не се сменя при всяка редакция на H1 и да стои в логична структура.

• Един canonical URL за всяка реална тема.
• Без staging/test/demo URL-и в sitemap.
• Без дублирани content types за една услуга.
• Предвиден redirect map при замяна на стар сайт.
• Internal links към финалния canonical URL.

Content model преди wireframe

За всяка page type описваме задължителните content blocks. Service page може да има direct answer, scope, process, decision criteria, evidence, FAQ и related services. Case study има problem, constraints, approach, execution и result evidence. Blog guide има answer-first intro, decision framework, examples и source layer.

Това помага на дизайна да създаде различни section families според съдържанието, вместо всеки текст да бъде поставен в еднакви cards.

Навигация и internal PageRank

Главното меню не трябва да съдържа всеки URL. Неговата задача е да отрази основните тематични клъстери и да даде бърз път до money pages. Детайлните specialist services могат да бъдат достъпни през hub pages, mega menu и contextual related links.

Добър модел за голяма service архитектура е: Homepage → Services hub → Cluster hub / core service → Specialist service → Guide / Case. Breadcrumbs добавят още един ясен структурен сигнал.

Migration mapping е част от дизайна на новия сайт

При redesign първо inventory-ваме старите indexable URLs и техните еквиваленти. URL с backlinks, impressions или историческа стойност не трябва автоматично да изчезва. Когато има нов еквивалент, правим one-to-one 301; когато няма, решаваме според реалната стойност и user expectation.

Google препоръчва URL mapping и permanent redirects при site moves. Вижте официалната документация за site moves.

Schema се планира според съдържанието

Organization, Service, BreadcrumbList, AboutPage и ContactPage имат смисъл, когато описват реално съдържание. Не чакаме launch day, за да открием, че дизайнът не показва информацията, която искаме да структурираме.

Tracking plan преди разработката

Формите, CTA, телефоните, checkout, lead stages и ключовите micro-interactions трябва да бъдат известни преди implementation. Така dataLayer и events могат да бъдат част от component logic, а не крехки selector-based patches след launch.

Core Web Vitals започват от design decisions

Огромен autoplay video hero, шест custom font weights и JavaScript slider за съдържание, което може да бъде статично, са design choices преди да са performance проблеми. Performance budget трябва да бъде част от acceptance criteria.

Pre-launch SEO QA

1. Crawl на staging с финалните URLs.
2. Проверка на status codes, canonical и robots.
3. H1/H2 hierarchy и page titles.
4. Structured data validation.
5. Redirect map test без chains.
6. Internal links и orphan pages.
7. XML sitemap само с canonical indexable URLs.
8. GA4/GTM/Ads conversion QA.
9. Mobile layout и Core Web Vitals.

Най-евтиният момент да решите SEO архитектурата е преди дизайна. Най-скъпият е след launch, когато вече трябва да пазите URL-и, tracking и натрупани сигнали.

След пускането на сайта уговорете кой проверява критичните функции и архивите. Използвайте списъка за договор за WordPress поддръжка.