Ларавель часто дає прості інструменти для задач, які з часом стають складнішими, ніж здавалися спочатку. У цій категорії я збиратиму невеликі спостереження з реальної роботи: про Pipeline, сервіси, черги, події, тестування та інші рішення, які допомагають упорядковувати код.
Після інтеграції власного localization package в ICanUp мені було недостатньо просто побачити, що Laravel route:cache завершується без помилки. Я перевірила реальні localized routes, logical route names, default locale без префікса, /en, locale switch, redirects, параметри URL і роботу застосунку після повторного завантаження cached routes.
У ICanUp robots.txt, sitemap і canonical з'являлися не одночасно, але на production вони мають описувати один і той самий набір публічних URL. Я зібрала свій практичний SEO checklist: що дозволяємо сканувати, що додаємо в sitemap, який URL оголошуємо canonical і як перевіряю все це через raw HTML та HTTP-відповіді після deploy.
У ICanUp visible breadcrumbs і BreadcrumbList JSON-LD описують одну й ту саму hierarchy сторінки. Показую, як я пов’язую навігацію зі structured data, формую sequential positions, використовую localized canonical URLs і не додаю окрему SEO hierarchy поверх application breadcrumbs.
У ICanUp JSON-LD BlogPosting пов’язує статтю не тільки з SEO metadata, а й з реальною author entity. Показую, як я представила автора як Person, узгодила structured data з canonical URL і localized metadata та чому JSON-LD має рендеритися одразу в SSR HTML.
У multilingual Laravel-проєкті x-default легко сприйняти як ще одну мовну версію сторінки. У ICanUp я використовую його інакше: x-default вказує на URL default locale. Розбираю реальний HreflangService, зв’язок із canonical та edge cases для різних content types.
У ICanUp Post і Category мають один shared slug, а локалізовані URLs відрізняються locale prefix і контентом. Розбираю, чому я відмовилася від translated slugs, як це спростило routing, hreflang, sitemap та IndexNow, і в яких проєктах language-specific slugs все ж можуть бути кращим вибором.
У ICanUp delayed IndexNow job планується на майбутній published_at, але до моменту виконання дата, slug або public state можуть змінитися. На реальному Laravel-коді показую, як job повторно перевіряє актуальний state, відкидає stale scheduling і використовує поточні URLs замість snapshot з минулого.
У ICanUp я запускаю IndexNow notifications і пов’язані queue operations тільки після успішного DB commit. На реальному Laravel-коді показую, чому dispatch усередині transaction може побачити ще незафіксовані дані або пережити rollback, і як DB::afterCommit() робить межу між database state та зовнішніми side effects явною.
У мультимовному Laravel-проєкті недостатньо просто мати окремі UK та EN URLs. Розбираю, як я налаштувала canonical і hreflang у ICanUp, зв’язала мовні версії сторінок, додала x-default і перевірила, щоб search engines не сприймали localized pages як дублікати.
Під час роботи із sitemap я помітила неочевидну проблему: public page могла змінитися через translation table, але updated_at основної моделі залишався старим. Розбираю, як я перевірила цей кейс і як визначила правильний lastmod для локалізованих сторінок.
Я не хотіла вручну повідомляти Bing про кожну нову або оновлену сторінку ICanUp. Тому інтегрувала IndexNow у Laravel: key endpoint, HTTP client, queue job, генерацію URL для постів, сторінок і категорій, локалізації, deduplication та tests.
Звичайні сторінки працювали, browser console була чистою, а в Laravel log усе одно з’являвся Inertia SSR exception. Розбираю реальний кейс, де проблему вдалося ізолювати до 404 error page за допомогою контрольного request і log marker.