Laravel.io Forum RSS Feed

How Much Does It Cost to Build a Candy AI Clone?

2026-10-03T05:32:58+00:00

I’m researching the cost of developing an AI companion platform similar to Candy AI. What factors have the biggest impact on the overall development budget? I’m particularly interested in AI model integration, personalized conversations, voice features, character customization, backend infrastructure, security, and ongoing maintenance. I’d also like to understand how the cost changes depending on whether the platform is built from scratch or using a pre-built solution. https://tripleminds.co/white-label/candy-ai-clone/

Best Practices for Improving Laravel API Performance

2026-10-03T05:32:58+00:00

Hi Laravel community, I’m currently exploring different ways to improve the performance of Laravel applications, especially when working with APIs that handle a large number of requests. I’d like to know what approaches experienced Laravel developers usually follow for improving API performance. For example: How do you optimize complex Eloquent queries? When do you prefer eager loading over lazy loading? How useful are Laravel queues for improving application performance? What caching strategies work well for frequently requested API data? Are there any Laravel-specific tools you recommend for identifying performance bottlenecks? I’d appreciate any practical tips, tools, or best practices you have found useful in real-world Laravel projects. Thanks!

Laravel, Healthcare Compliance and More

2026-10-03T05:32:58+00:00

Hi I am pretty new at laravel and is quite impressed with the massive support in terms of tech stack and more. I am a business analyst with some little experience in coding, i have always been a wordpress person but really impressed with the creativity laravel brings. I am working as a development manager for a UK home care business and just built out (with claude - yes vieb coded somewhat) a healthcare compliance web app with PWA support for carers when they visit client homes. We chose not to go the route of mobile app because of the cost and risks to data and aditional infra requirements which the business cannot afford. Hosted in laravel cloud and guarded by laravel sentry, i want to know if anyone has issues around compliance as i have noticed that the compliance bit is even more work than building out the code base. I also expected laravel cloud would have some documentation i could use to build out my business continuity policies and those related to healthcare compliance. All help will be appreciated.

Teaching Laravel Boost to Use Pragmatic DDD

2026-10-03T05:32:58+00:00

Laravel Boost is widely used to give coding agents context about Laravel projects. It can provide guidelines and skills that shape how agents create and change files. That made me ask a question: could Boost also be a place to guide an application toward Domain-Driven Design? I wanted to try that without asking people to remove Laravel from their domain code. Eloquent models, policies, events, queues, service providers, and the usual Laravel entry points are useful parts of an application. DDD, as I wanted to apply it, should help decide where behaviour belongs, not require replacing those tools with a framework of our own. So I built **Laravel Boost DDD**. GitHub: [maiobarbero/laravel-boost-ddd](https://github.com/maiobarbero/laravel-boost-ddd) The package provides Laravel Boost with a set of guidelines, 11 task-specific skills, and Pest architecture tests for applying a pragmatic form of Domain-Driven Design to Laravel applications. The important word there is **pragmatic**. ## I didn't want DDD to replace Laravel There are many ways to implement DDD, and some approaches can make a Laravel application stop feeling like Laravel. Controllers, commands, jobs, listeners, policies, events, service providers, migrations, and factories still live where Laravel developers expect them. The package introduces three main areas when they are useful: ```text app/ ├── Application/ │ └── Orders/ │ ├── Actions/ │ ├── Contracts/ │ └── Data/ │ ├── Domain/ │ └── Orders/ │ ├── Events/ │ ├── Exceptions/ │ ├── Models/ │ └── ValueObjects/ │ └── Infrastructure/ ``` The basic distinction is: - **Domain** owns business behavior and invariants. - **Application** coordinates use cases. - **Infrastructure** implements integrations and technical details. - Laravel's usual entry points remain Laravel's usual entry points. For example, if an order can be cancelled, the rule that determines whether cancellation is allowed belongs close to the order: ```php $order->cancel(); ``` The application layer coordinates the use case: ```php $cancelOrder->handle($order, $actor); ``` The Action might handle authorisation, persistence, transactions, and event dispatch; so the controller only needs to deal with HTTP and invoke the use case. ## The other problem: consistency between AI sessions This was the part that made Laravel Boost particularly interesting for this experiment. I didn't just want a document saying: > "Please use DDD." That leaves a huge amount open to interpretation. Instead, the package contains focused skills for specific tasks: ```text creating-action creating-data creating-domain-model creating-value-object creating-domain-service creating-domain-event creating-integration introducing-repository using-laravel-entry-points testing-domain testing-action ``` So when an agent is creating a value object, introducing an integration, testing a domain rule, or implementing an Action, it can receive guidance specifically for that task. ## Architecture rules should also be executable Instructions for an AI agent are useful, but I didn't want the package to rely entirely on instructions and LLM's interpretation. This is why the package also publishes Pest architecture tests. They check things such as dependency boundaries between Domain, Application, Infrastructure and delivery code, as well as a few conventions used by the package. ## Existing applications shouldn't require a rewrite Installing the package does **not** mean: > "Move the whole application into Domain/Application/Infrastructure." Existing code stays where it is. ## Installation The package currently supports Laravel 12 and 13 and requires Laravel Boost. Install it as a development dependency: ```bash composer require --dev maiobarbero/laravel-boost-ddd ``` If the project doesn't already use Pest: ```bash composer require --dev pestphp/pest vendor/bin/pest --init ``` Then: ```bash php artisan boost-ddd:install ``` The installer registers the package with Boost, installs the guidelines and skills for the configured agents, and publishes the architecture test. ## I'd like feedback on the architectural choices This is a `1.0`, so one reason I'm sharing it here is that I'm interested in feedback from people who build larger Laravel applications. In particular, I'm curious about where other Laravel developers draw these boundaries: - When does an Eloquent model become too responsible? - When is a repository actually worth introducing? - Do you prefer use-case Actions, application services, or another pattern? - How much architecture should be enforced automatically versus left to review? - And if you're using coding agents, how are you keeping architectural decisions consistent between sessions? I'm deliberately trying to stay somewhere between **"everything in controllers/models"** and **"every Laravel feature needs six abstractions"**. If that's a problem you're dealing with too, I'd be interested to hear how you're approaching it. Repository: **[https://github.com/maiobarbero/laravel-boost-ddd](https://github.com/maiobarbero/laravel-boost-ddd)**

PrivacyCI: Discover, Delete, Verify User Data

2026-10-03T05:32:58+00:00

I built PrivacyCI after repeatedly seeing the same backend problem: user deletion works in the main DB, but data survives in secondary tables, Redis, object storage, search indexes, or external systems. PrivacyCI statically discovers user-linked storage, lets you classify it as DELETE/ANONYMIZE/RETAIN/etc., baselines existing debt, and fails CI only when a PR introduces a new deterministic user-data location without a policy. It can also snapshot a user's footprint before deletion and verify it afterward. It’s MIT licensed, completely local, no account, telemetry, or hosted service. I’d particularly like feedback on the discovery model and where people see false positives/negatives. https://github.com/AsterlaneLabs/privacy-ci

Personal Drive - selfhosted alternative to Google Drive

2026-10-03T05:32:58+00:00

Repo: https://github.com/gyaaniguy/personal-drive Demo: https://demo.personaldrive.xyz/ A self hosted alternative to google drive, upload your files on your own server, view photos, download, delete from web UI. Share files with optional password protection. Main Features * File and folder sharing * Password-protected shares * Image, video and audio player * Text, HTML and PDF previews * Audiobook support with saved position and rewind controls * Upload queue with per-upload progress * Drag and drop uploads * List and tile views * Sorting by name, date, size and type * Breadcrumb navigation * Quick folder navigation with Ctrl+G * Rename and move files * Create and edit text files * Markdown support * Favorites * TOTP two-factor authentication * Password-protected uploads using client-side AES-256 encrypted ZIPs Lots of focus has been spent on testing and security. Stack: Coded in laravel and react. Made mostly for learning purposes. Initially I didn't plan to open it, but thought it would be a good exercise in having my code scrutinized and as a portfolio piece. Please have a look and share your thoughts.

I built an open-source native macOS app to manage Laravel de

2026-10-03T05:32:58+00:00

I work on multiple Laravel projects every day, and I got tired of keeping several terminal tabs open just to run artisbetan serve, queues, Horizon, Vite, Reverb, Sail, and everything else. So I started building LaraDeck. It automatically detects Laravel projects and lets you start, stop, and monitor their development services from a native macOS interface. It’s still very early and completely open source. I’m looking for Laravel developers on macOS who are willing to try it, break things, and tell me what sucks. 👉 https://laradeck.brokenice.it

How do you structure safe multi-step forms in Livewire?

2026-10-03T05:32:58+00:00

When a Livewire form spans several steps, the UI is the easy part. The harder questions are usually server-side: - Do you validate only the current step or the whole form? - How do you prevent direct final submission before the review step? - How do you keep select values constrained to configured options? - Where do Laravel rule objects or closures live without exposing them as public Livewire state? - Who owns persistence and authorization? The pattern I settled on is: 1. Validate the current step before advancing. 2. Generate a review step dynamically. 3. Accept final submission only from that review step. 4. Revalidate the complete form on submission. 5. Pass only configured, validated fields to an application-owned hook. 6. Keep persistence, authorization, mail, redirects, rate limiting, and retention in the application. I extracted this into an MIT-licensed package and published v1.0.0 today: `composer require codegenie-be/laravel-livewire-multistep-form` It supports Laravel 12–13 and Livewire 3.6+/4.x, includes accessible markup and EN/NL/FR interface copy, and does not store data or call external services. Repository: https://github.com/Codegenie-BE/laravel-livewire-multistep-form Demo: https://laravel-livewire.codegenie.be Packagist: https://packagist.org/packages/codegenie-be/laravel-livewire-multistep-form Disclosure: I maintain the package through Codegenie. I am mainly looking for technical feedback: what validation, accessibility, or customization edge cases do you encounter in production multi-step forms?

How do you catch Laravel environment drift before deploy?

2026-10-03T05:32:58+00:00

One failure mode I keep seeing is application code that works locally but behaves differently after `php artisan config:cache` because it reads an environment variable directly: ```php $token = env('ACME_TOKEN'); ``` ## The normal Laravel fix The primary solution is to move the environment lookup into a configuration file: ```php // config/services.php return [ 'acme' => [ 'token' => env('ACME_TOKEN'), ], ]; ``` Application code should then read it through Laravel's configuration repository: ```php $token = config('services.acme.token'); ``` I also test deployment builds with configuration cached. That catches the direct-access problem before production. ## Environment-file drift remains A related issue is keeping the key inventories of `.env`, `.env.testing`, `.env.production`, `.env.sample`, or renamed templates aligned without comparing or exposing their values. Some practical questions for teams maintaining several environments: - Do you treat every `.env.*` file as a complete contract, or are some of them partial Vite-style layers? - How do you detect a key used by application code but declared nowhere? - How do you handle keys consumed only by Docker, CI, a process manager, or hosting infrastructure without producing false positives? - Do commented assignments in non-active templates count as documented optional keys in your workflow? - Do you audit raw `getenv()`, `$_ENV`, `$_SERVER`, Vite, Blade, and PHPUnit usage as part of the same review? ## An optional development guard While working through these cases, I built the open-source [Laravel Env Guard](https://github.com/Codegenie-BE/laravel-env-guard): ```bash composer require --dev codegenie-be/laravel-env-guard ``` It runs during guarded Artisan boots in the local environment by default. It checks unsafe `env()` usage and environment-key drift, but reports keys only: no values, telemetry, network calls, automatic `.env` changes, or production scanning by default. The current release supports Laravel 12 and 13 across their valid PHP 8.2–8.5 combinations. Disclosure: I maintain this package through Codegenie. I am looking for technical feedback about real-world environment-file conventions and false-positive or false-negative cases, not stars. Please do not share real environment values or secrets.

Best Practices for Building Secure Payment APIs in Laravel

2026-10-03T05:32:58+00:00

Been building out a payment API in Laravel recently and figured I'd share some of the practices that have made the biggest difference for us. Payment endpoints are a different beast compared to a typical CRUD API — the cost of a mistake is real money, not just a bad UX. Curious to hear what others are doing too. **1. Never Store Raw Card Data** This is the first rule and it's non-negotiable. Use a tokenized payment processor (Stripe, Braintree, etc.) and store only the token/reference ID in your database. Storing raw PANs or CVVs yourself pulls your entire app into PCI-DSS scope, which is a massive compliance burden most teams don't need to take on. ``` php // Good — store only the processor's token $payment = Payment::create([ 'user_id' => $user->id, 'processor_token' => $charge->id, // e.g. Stripe charge/payment intent ID 'amount' => $amount, 'status' => 'pending', ]); ``` **2. Enforce Idempotency on Every Write Endpoint** Network retries, double-taps on the frontend, and queue redelivery can all cause the same charge or transfer request to hit your API twice. Require an Idempotency-Key header and store a hash of processed keys so a repeated request returns the original result instead of creating a duplicate transaction. ``` php if (Cache::has("idempotency:{$key}")) { return Cache::get("idempotency:{$key}"); } ``` Laravel doesn't do this for you out of the box, so it's worth building as reusable middleware if you're handling any kind of money movement. **3. Use Database Transactions + Locking for Balance Updates** Never do a read-then-write balance update without locking the row. Race conditions here are exactly how double-spends happen. ``` php DB::transaction(function () use ($walletId, $amount) { $wallet = Wallet::where('id', $walletId)->lockForUpdate()->first(); if ($wallet->balance < $amount) { throw new InsufficientFundsException(); } $wallet->decrement('balance', $amount); }); ``` **4. Rate Limit Aggressively on Financial Endpoints** Laravel's built-in throttle middleware is a good start, but for payment endpoints specifically, consider tighter limits and per-user (not just per-IP) throttling to blunt card-testing and enumeration attacks. ``` php Route::middleware('throttle:10,1')->group(function () { Route::post('/payments/charge', [PaymentController::class, 'charge']); }); ``` **5. Verify Webhooks Cryptographically** If you're consuming webhooks from a payment processor, always verify the signature before trusting the payload. Don't just check that the request "looks right." ``` php $sig = $request->header('Stripe-Signature'); $event = \Stripe\Webhook::constructEvent($payload, $sig, config('services.stripe.webhook_secret')); ``` **6. Log Everything, But Never Log Sensitive Data** Full audit trails matter a lot for financial systems — who initiated a transaction, when, from where. Just make sure your logging channel scrubs card numbers, tokens, and auth headers before anything hits disk. **7. Use Policies/Gates for Every Financial Action** Don't rely on route middleware alone. Wrap every transfer, withdrawal, or balance-changing action in an explicit authorization check via Laravel's Policy classes, so it's obvious and testable that a user can only act on their own wallet/account. None of this is Laravel-specific in principle — it's standard fintech engineering discipline — but Laravel gives you solid primitives (transactions, middleware, policies, queues) to implement it cleanly if you use them deliberately rather than bolting security on after the fact. At Nimble AppGenie we've run into a lot of these issues while working on [fintech APIs](https://www.nimbleappgenie.com/blogs/top-fintech-apis-for-every-startup/) for wallet and payment products, and idempotency + row locking are consistently where teams get bitten first. What are others doing for fraud detection or velocity checks at the API layer? That's the piece I'm still refining.

Laravel Route / Controller Bypass Issue with Apache

2026-10-03T05:32:58+00:00

Problem Description Hello Laravel Community, I am facing a strange issue with my Laravel application running on Apache + PHP 8.2-FPM. Sometimes a specific route appears to return a response without reaching the expected Laravel controller. I am investigating whether Apache configuration, .htaccess, routing, middleware, caching, or another server-level rule could be bypassing Laravel's normal request flow. Environment Laravel application Apache2 PHP 8.2-FPM Ubuntu/Linux server HTTPS enabled Domain: xxxxxxxx DocumentRoot: /var/results/public Active Apache VirtualHost According to: sudo apachectl Laravel .htaccess The public directory contains the standard Laravel rewrite rule: RewriteEngine On RewriteCond %{REQUEST_FILENAME} !-d RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ^ index.php [L] Therefore, if /master is not a physical file or directory, I expect the request flow to be: Request: /master ↓ Apache ↓ public/.htaccess ↓ public/index.php ↓ Laravel Router ↓ Middleware ↓ Controller However, I want to confirm whether there could be any other Apache-level configuration or caching mechanism causing the route to bypass Laravel. Questions Can Apache serve a response for /master without Laravel receiving the request, even when the Laravel .htaccess rule sends non-existing files/directories to index.php? What is the best way to trace the complete request flow from: Apache → .htaccess → index.php → Laravel middleware → controller Are there any Apache modules, caching mechanisms, VirtualHost directives, or PHP-FPM configurations that could cause a Laravel route to behave unexpectedly? What debugging method would you recommend to confirm whether a request actually reaches Laravel's public/index.php? Any guidance would be appreciated. Thank you!

Where Should Stablecoin Logic Actually Live?

2026-10-03T05:32:58+00:00

Building a stablecoin is not simply a matter of writing a token contract and deploying it. The interesting engineering problem starts when on-chain logic has to communicate with everything happening outside the blockchain. The smart contract can handle token balances, transfers, permissions, and other predefined rules. But what happens when the system needs pricing data, user management, transaction monitoring, analytics, compliance workflows, or administrative controls? That is where the backend becomes important. **What Should Stay On-Chain?** The blockchain is useful when something needs transparent, deterministic execution. Token transfers, balances, minting rules, burning mechanisms, and critical ownership logic are obvious candidates. But putting all application logic on-chain can create unnecessary cost and complexity. A backend can handle operations that don't require decentralized execution, such as indexing blockchain events, serving APIs, managing application data, processing notifications, and coordinating user-facing workflows. The challenge is deciding where that boundary should exist. **So Where Should the Boundary Be?** There probably isn't one universal answer. Critical asset logic generally benefits from deterministic on-chain execution, while application-heavy operations can often remain off-chain. The right architecture depends on the stablecoin model, blockchain network, security requirements, transaction volume, compliance needs, and expected user experience. An end-to-end [stablecoin development](https://devtechnosys.com/stablecoin-development-services.php) approach therefore isn't about putting everything on-chain. It is about designing the right relationship between smart contracts, backend services, databases, wallets, APIs, and blockchain infrastructure. The interesting question for developers is this: **If you were designing a production stablecoin today, which responsibilities would you keep on-chain, and which would you deliberately move to the backend?**

Laravel Rick 0.1.0 - durable AI workflows for Laravel

2026-10-03T05:32:58+00:00

Laravel Rick 0.1.0 — durable AI workflows for Laravel Making a single AI request from Laravel is straightforward. Keeping a multi-step AI workflow reliable after the HTTP request ends is a different problem. What happens when a queue job is delivered twice? When an application must pause for human review? When several model calls finish in a different order? When a paid request times out and it is unclear whether the provider accepted it? I built Laravel Rick to handle that workflow lifecycle inside Laravel. Laravel Rick turns typed workflow definitions into deterministic compiled plans and durable, tenant-aware runs. Workflows can execute synchronously or continue through Laravel queues without relying on PHP process memory. ## Quick example ```php use Rick\Laravel\Rick; $rick = app(Rick::class); $workflow = $rick->workflow('summary') ->rawPrompt('Summarize the latest customer feedback.') ->build(); $run = $rick->run($workflow); echo $run->output(); Installation: composer require rickphp/laravel-rick:^0.1 php artisan migrate ## What it currently supports - synchronous and queued workflow execution; - Laravel AI provider calls; - parallel operations with deterministic result ordering; - manual review, candidate selection and external input; - encrypted, tenant-scoped persistence; - pricing and resource budgets; - run metrics, snapshots and timelines; - transactional outbox delivery; - recovery of interrupted runs; - protection against blindly repeating ambiguous paid requests. One of the included examples generates five independent implementation plans, persists all five candidates, pauses the workflow for human review and continues only after the application selects a candidate. Another example dispatches independent operations through Laravel queues. Results are reduced in declaration order even if workers complete them in a different order. Duplicate delivery of an already completed invocation does not trigger another provider call. Laravel Rick 0.1.0 supports PHP 8.3+ and Laravel 12–13. It is open source under the MIT license. This is the first public release, so the API may still evolve before 1.0. I would especially appreciate feedback on: 1. Is the workflow-building API understandable? 2. Which real Laravel AI workflow would you try to implement with it? 3. What is missing from the installation or use-case documentation? GitHub: https://github.com/para1992/laravel-rick Packagist: https://packagist.org/packages/rickphp/laravel-rick Release: https://github.com/para1992/laravel-rick/releases/tag/v0.1.0 Issues and feature requests: https://github.com/para1992/laravel-rick/issues/new/choose

Preventing stale config after shared-hosting deployments

2026-10-03T05:32:58+00:00

I'm interested in how other teams handle stale Laravel deployment caches on cPanel, Plesk, and FTP-only hosting. A reproducible case is: - the application already has cached configuration; - `.env` or a file under `config/` changes during an FTP deployment; - the host has no SSH or reliable deployment hook, and `exec()` is disabled; - the next request still loads the old cached value. The normal deployment solution remains the best one: ```bash php artisan config:cache ``` If route caching is used, rebuild that too: ```bash php artisan route:cache ``` When configuration caching is intentionally disabled, `config:clear` is appropriate. Application code should also use `config()` rather than `env()` outside configuration files. The awkward case is restricted hosting where none of these commands can be executed reliably. By the time ordinary middleware or a service provider runs, Laravel has already consumed the cached configuration during bootstrap. I've been testing an open-source safety net for that specific edge case. It loads through Composer before `bootstrap/app.php`, compares relevant source metadata, refuses known-stale config or route caches, and repairs them through the PHP CLI when available. Without `exec()`, the current request continues without the stale deployment cache and an internal `Artisan::call()` repair runs after the response. It does not enable caching automatically, expose a repair endpoint, read environment values, or send telemetry. By default, it only refreshes cache types the application already uses. Disclosure: I maintain Laravel Config Cache Guard through Codegenie: https://codegenie-be.github.io/laravel-config-cache-guard/ I'm looking for technical feedback rather than stars. How do you handle this on restricted hosting today? Are there provider-specific race conditions or failure modes that a safety net like this should account for?

Chatify v2 is out 🔥 — here’s everything it ships with

2026-10-03T05:32:58+00:00

Hey Laravel community 👋 Chatify v2 beta is live — a real-time chat package for Laravel with direct messages, groups, saved messages, typing indicators, read receipts, attachments, voice notes, and a complete Vue 3 messenger UI at `/chatify`. What's new in v2: • Group conversations with roles & permissions • Voice notes, attachments, and in-conversation search • Headless REST API for custom frontends (Livewire, Inertia, mobile, etc.) • Real-time over Reverb, Pusher, or any Pusher-protocol driver • Mobile-ready UI, themes, RTL, and full docs and much more to discover! - Official Website — https://chatifyphp.com If you've used v1 — there's a migration guide in the docs. Would love feedback on the beta, especially from anyone building with Reverb or a custom frontend. Happy to answer questions here.

The Ultimate Laravel SEO Handbook for Developers

2026-10-03T05:32:58+00:00

Laravel is one of the most loved PHP frameworks out there, but "loved by developers" and "loved by Google" aren't automatically the same thing. A lot of teams ship a beautiful Laravel app, wire up Blade or Inertia on the front end, launch, and then wonder six months later why organic traffic is flat. Usually it's not one big mistake, it's a stack of small ones: no canonical tags, a sitemap that never updates, meta descriptions that are just {{ $post->title }} copy-pasted everywhere, images with no alt text, and a homepage that takes four seconds to paint. SEO for a framework-driven app is different from SEO on WordPress, where a plugin like Yoast handles 80% of the work for you out of the box. In Laravel, you're building the SEO layer yourself, which is more work upfront, but gives you far more control over exactly how your app is crawled, indexed, and rendered. **Why SEO matters for Laravel websites** Laravel commonly powers SaaS products, marketplaces, e-commerce stores, and content-heavy platforms: exactly the kind of sites where organic search is a primary acquisition channel. Unlike a static brochure site, these apps have dynamic routes, user-generated content, filters, and pagination, all of which multiply the number of ways things can go wrong (or right) from an SEO standpoint. **Common Laravel SEO challenges** The recurring pain points developers run into are fairly consistent across projects: - Routes built for developer convenience (/product/show/1042) instead of search engines and users (/products/ergonomic-office-chair) - No systematic handling of meta tags, so titles and descriptions are either missing or duplicated across thousands of pages - Sitemaps that are hand-written once and never touch again - JavaScript-heavy front ends (Vue, React, Livewire) that render content client-side, leaving crawlers with an empty shell - Database-driven pages with no canonicalization, causing duplicate content across filter and sort combinations - Performance issues from N+1 queries, unminified assets, and unoptimized images that tank Core Web Vitals **What you'll learn in this guide** This handbook walks through Laravel SEO from the ground up: fundamentals like URLs, sitemaps, and meta tags; technical SEO like structured data and indexability; performance tuning specific to Laravel's caching and query layer; and advanced topics like multi-language SEO, programmatic SEO, and SSR for JavaScript-driven Laravel apps. By the end, you'll have a working mental model, and a checklist, for auditing and fixing SEO on any Laravel project. ### Understanding Laravel SEO **What Is Laravel SEO?** Laravel SEO isn't a separate discipline from "regular" [SEO](https://infinitysofthint.com/blog/what-is-seo-and-its-importance/) (Search Engine Optimization): the ranking factors are the same ones Google uses everywhere: relevance, authority, crawlability, and user experience. What's specific to Laravel is how you implement those factors using the framework's tools: routes, middleware, Blade components, service providers, Eloquent models, and the artisan console. In practice, Laravel SEO means things like generating dynamic meta tags from your Eloquent models, building a sitemap that regenerates itself when content changes, configuring middleware to enforce canonical URLs, and using Laravel's caching layer to keep pages fast enough to satisfy Core Web Vitals. **Why Laravel Is a Great Framework for SEO** Despite the extra setup work, Laravel has real structural advantages for SEO: - Full routing control. Laravel's router lets you define exactly what a URL looks like, independent of your database schema or folder structure. There's no forced /index.php?p=123 pattern to work around. - Blade templating. Server-rendered HTML by default means your meta tags, headings, and content are present in the initial HTML response, no waiting on JavaScript to hydrate before Googlebot sees your content. - Eloquent and query builder. Structured data (JSON-LD schema) is trivial to generate because you already have clean, related models, a Product with a belongsTo Category and hasMany Reviews maps almost directly to Schema.org's Product type. - A mature package ecosystem. Tools like Spatie's sitemap and schema packages, or artesaos/seotools, cover most of the boilerplate so you're not writing an XML sitemap generator from scratch. - First-class caching. Route, config, and view caching are built in, and combined with tools like Laravel Octane, response caching, and Redis, you can hit very fast Time to First Byte numbers. **How Search Engines Crawl Laravel Websites** Googlebot crawls a Laravel app the same way it crawls any web app: it requests a URL, reads the HTTP response headers and status code, parses the HTML, follows internal links, and (for JS-rendered content) queues a second rendering pass. A few Laravel-specific things affect this process: - **Route model binding and 404s**. If a route uses implicit binding (Route::get('/products/{product}', ...)) and the model isn't found, Laravel throws a ModelNotFoundException, which should resolve to a proper 404 status, not a soft 200 "not found" page, which confuses crawlers and wastes crawl budget. - **Middleware order**. If auth, locale detection, or redirect middleware run in the wrong order, crawlers can get bounced into login walls or redirect loops. - **Server response time**. Laravel apps with slow queries or no caching will get crawled less frequently, because Googlebot throttles crawl rate based on how quickly your server responds. - **Rendering mode**. A Blade-only Laravel app is crawled like a standard server-rendered site. A Laravel + Vue/React SPA needs to be rendered by Googlebot's second wave (or pre-rendered via SSR) before content is indexed, introducing lag and risk. ## Laravel SEO Fundamentals **Choose an SEO-Friendly URL Structure** URLs are one of the first things both users and search engines evaluate. A clean, descriptive URL builds trust and gives a small relevance signal for the terms it contains. **RESTful URLs** Laravel's resource routing naturally encourages a clean, predictable structure: Route::resource('products', ProductController::class); This generates conventional, readable paths like /products, /products/{product}, /products/{product}/edit, far better than exposing raw controller actions or query-string based routing. **Slugs vs IDs** Never expose a raw database ID as the primary identifier in a public-facing URL if you can avoid it. Compare: /products/1042 /products/ergonomic-office-chair The second is more readable, more clickable in search results, and gives a (small but real) relevance signal. Implement it with route model binding on a slug column: // Product.php public function getRouteKeyName() { return 'slug'; } // routes/web.php Route::get('/products/{product}', [ProductController::class, 'show']); Generate slugs on save using a package like spatie/laravel-sluggable, or manually with Str::slug(), and store them in a dedicated slug column with a unique index. **URL Naming Best Practices** - Use hyphens, never underscores, to separate words (office-chair, not office_chair) - Keep URLs lowercase - Avoid unnecessary parameters and session IDs in the path - Keep URLs reasonably short and human-readable - Don't change slugs after they're indexed without setting up a 301 redirect; orphaned old URLs create broken backlinks and lost rankings ### Configure HTTPS and Security **SSL Certificates** HTTPS is a confirmed Google ranking signal and a baseline trust requirement. In production, terminate SSL at your load balancer or web server (Nginx/Apache), and force Laravel to generate HTTPS URLs by adding this to AppServiceProvider::boot(): use Illuminate\Support\Facades\URL; public function boot() { if ($this->app->environment('production')) { URL::forceScheme('https'); } } **HSTS** HTTP Strict Transport Security tells browsers to only ever connect over HTTPS, preventing downgrade attacks and mixed-content warnings that can hurt trust signals. Add the header at your web server level, or via middleware: $response->headers->set('Strict-Transport-Security', 'max-age=31536000; includeSubDomains; preload'); **Secure Cookies** Set SESSION_SECURE_COOKIE=true in your .env for production so session cookies are only sent over HTTPS, and confirm SESSION_SAME_SITE is set appropriately (usually lax) to avoid breaking cross-site referral tracking. Set SESSION_SECURE_COOKIE=true in your .env for production so session cookies are only sent over HTTPS, and confirm SESSION_SAME_SITE is set appropriately (usually lax) to avoid breaking cross-site referral tracking. **Optimize robots.txt** Your robots.txt file (served from public/robots.txt in Laravel, or dynamically via a route) tells crawlers what they're allowed to access. **Allowing Important Pages** Make sure crawlers can reach your public routes, sitemap, and static assets: User-agent: * Allow: / Sitemap: https://example.com/sitemap.xml **Blocking Sensitive Directories** Block admin panels, auth routes, and internal API endpoints that shouldn't be indexed: Disallow: /admin Disallow: /login Disallow: /api/ Disallow: /cart Disallow: /checkout **Common Mistakes** - Accidentally leaving Disallow: / in a robots.txt copied from a staging environment; this blocks your entire production site from being crawled - Blocking CSS/JS folders, which prevents Google from properly rendering the page for mobile-friendliness and Core Web Vitals evaluation - Using robots.txt to try to "hide" pages from search; it only blocks crawling, not indexing; a blocked page can still appear in results if linked externally. Use noindex meta tags for that instead. **Create an XML Sitemap** A sitemap helps search engines discover URLs faster, especially on large or frequently updated Laravel apps. **Static vs Dynamic Sitemaps** For a small, mostly-static site, a hand-maintained sitemap file is fine. For anything database-driven (products, blog posts, categories), generate it dynamically. The spatie/laravel-sitemap package makes this straightforward: use Spatie\Sitemap\Sitemap; use Spatie\Sitemap\Tags\Url; Route::get('/sitemap.xml', function () { $sitemap = Sitemap::create(); Product::published()->each(function (Product $product) use ($sitemap) { $sitemap->add( Url::create(route('products.show', $product)) ->setLastModificationDate($product->updated_at) ->setChangeFrequency(Url::CHANGE_FREQUENCY_WEEKLY) ->setPriority(0.8) ); }); return $sitemap->toResponse(request()); }); For large catalogs, cache this route's response and regenerate it via a scheduled job rather than rebuilding it on every request. **Image Sitemaps** Include entries for key product/content images so Google Image Search can discover them independently: Url::create(route('products.show', $product)) ->addImage($product->image_url, $product->name); **Video Sitemaps** If your Laravel app hosts video content, add tags with title, description, thumbnail, and duration, this is a distinct ranking surface (video search results) worth targeting separately. **Sitemap Index Files** Once you exceed 50,000 URLs (or just want cleaner organization), split into multiple sitemaps and combine them under a sitemap index: SitemapIndex::create() ->add('/sitemap-products.xml') ->add('/sitemap-posts.xml') ->add('/sitemap-categories.xml'); ### On-Page SEO in Laravel **Dynamic Title Tags** Every page needs a unique, descriptive . Hardcoding one title in a shared Blade layout is one of the most common Laravel SEO mistakes. <title>@yield('title', config('app.name')) @section('title', $product->name . ' | ' . config('app.name')) **Best Practices** - Put the primary keyword or entity near the front of the title - Make every title unique, duplicate titles across product/category pages are a frequent Laravel issue when the layout doesn't override the default - Include your brand name, usually at the end **Character Limits** Keep titles under roughly 60 characters so they don't get truncated in search results. Consider a small helper or Eloquent accessor to auto-truncate long dynamic titles gracefully rather than cutting mid-word. ### Meta Descriptions **Writing Click-Worthy Descriptions** A meta description doesn't directly affect rankings, but it drives click-through rate, which indirectly affects performance. Write descriptions that state a clear benefit or answer, include the target keyword naturally, and end with an implicit reason to click. **Dynamic Meta Descriptions** Generate descriptions from model data rather than a single static string: For pages without natural excerpt text (like faceted category pages), write a templated fallback: "Shop {{ $category->name }}, {{ $category->products_count }} products, free shipping ### Canonical URLs **Preventing Duplicate Content** Laravel apps frequently generate multiple URLs for the same content, via sorting (?sort=price), filtering (?color=red), pagination, or session parameters. Without canonical tags, search engines may treat these as separate pages and split ranking signals between them. **Canonical Tag Implementation** But for filtered/sorted variants, point the canonical back to the clean base URL rather than url()->current(): // In a view composer or controller $canonical = route('products.category', $category); **Heading Structure** **H1 Best Practices** Every page should have exactly one

, matching the primary topic of the page, the product name, article title, or category name. Avoid using the site logo/name as an H1 in the header component, which is a surprisingly common Blade layout mistake. H2–H6 Hierarchy Structure supporting content logically: H2s for major sections, H3s for subsections, and so on, without skipping levels. This helps both accessibility tools and search engines understand content structure, and it maps naturally onto Blade components if you build a component that accepts a heading level as a prop. ### Image SEO Alt Text Every meaningful image needs descriptive alt text, not for keyword stuffing, but so image search and accessibility tools understand what's shown: image_url }}" alt="{{ $product->name }}, {{ $product->short_description }}"> Image Compression Use Laravel's ecosystem (spatie/laravel-medialibrary, or Intervention Image) to automatically compress and resize uploads at the point of storage, rather than serving full-resolution originals to every visitor. Lazy Loading Native lazy loading is a one-attribute fix that meaningfully helps Largest Contentful Paint and bandwidth usage on image-heavy pages: url }}" loading="lazy" alt="{{ $image->alt }}"> Never lazy-load the hero/above-the-fold image, that one should load eagerly, since it's usually your LCP element. Modern Image Formats Serve WebP or AVIF with a JPEG/PNG fallback using : webp_url }}" type="image/webp"> jpg_url }}" alt="{{ $image->alt }}" loading="lazy"> ### Internal Linking Contextual Links Link between related products, articles, or categories directly in your content and Blade templates, this distributes authority and helps users (and crawlers) discover deeper pages. Breadcrumb Navigation Breadcrumbs improve both usability and crawlability, and they double as a valuable structured-data opportunity (see the Breadcrumb Schema section below):
Home / {{ $category->name }} / {{ $product->name }}
Anchor Text Optimization Avoid generic anchor text like "click here" or "read more" for important internal links. Use descriptive phrases that reflect the destination page's topic, this is a small but real relevance signal, and it's better for accessibility too. ### Technical SEO for Laravel Optimize Crawlability Crawl Budget Large Laravel apps (marketplaces, SaaS directories, e-commerce stores) can generate thousands of low-value URL variants (filters, sorts, session parameters). Search engines allocate a finite crawl budget per site, so wasting it on near-duplicate pages means your genuinely important pages get crawled less often. Consolidate with canonical tags, noindex low-value filter combinations, and avoid infinite crawl traps (like calendar widgets generating a URL per day forever). Orphan Pages An orphan page has no internal links pointing to it, it might only exist in your sitemap or database. Audit for these regularly; a page a crawler can't reach through normal navigation is much harder to rank, even if it's in the sitemap. Broken Links Run periodic link audits (Screaming Frog, Ahrefs, or a custom artisan command hitting your own route list) to catch 404s from renamed slugs, deleted records, or typos in Blade templates. ### Improve Indexability Noindex Pages Use noindex for pages that should be crawlable but shouldn't appear in search results, thank-you pages, internal search results, admin-adjacent utility pages: Canonical Pages Reinforce indexability decisions by pairing noindex (where appropriate) with canonical tags on parameterized versions of a page, so link equity consolidates onto the single "real" URL. Pagination For paginated lists (blog archives, product listings), make sure each page has a unique, indexable URL (/blog?page=2, not JS-only pagination with no URL change), and consider noindex, follow on deep pagination pages beyond page 2–3 to avoid diluting the index with thin listing pages, while still passing link equity onward. Structured Data Structured data (JSON-LD) doesn't directly boost rankings, but it enables rich results, star ratings, breadcrumbs, FAQ dropdowns, which significantly improve click-through rate. Laravel's Eloquent relationships make generating this data straightforward, especially with a package like spatie/schema-org. Organization Schema Add sitewide, usually in your main layout: $schema = Spatie\SchemaOrg\Schema::organization() ->name(config('app.name')) ->url(config('app.url')) ->logo(asset('images/logo.png')); Article Schema For blog posts, map your Post model directly to Article schema: Schema::article() ->headline($post->title) ->datePublished($post->published_at) ->dateModified($post->updated_at) ->author(Schema::person()->name($post->author->name)) ->image($post->cover_image_url); Product Schema Schema::product() ->name($product->name) ->image($product->image_url) ->description($product->description) ->offers( Schema::offer() ->price($product->price) ->priceCurrency('USD') ->availability($product->in_stock ? 'https://schema.org/InStock' : 'https://schema.org/OutOfStock') ); FAQ Schema If a page has a genuine FAQ section, map it directly, this is one of the highest ROI schema types for earning extra real estate in search results: Schema::faqPage()->mainEntity( $faqs->map(fn ($faq) => Schema::question() ->name($faq->question) ->acceptedAnswer(Schema::answer()->text($faq->answer)) )->toArray() ); Breadcrumb Schema Pairs naturally with the breadcrumb navigation component from earlier: Schema::breadcrumbList()->itemListElement([ Schema::listItem()->position(1)->name('Home')->item(route('home')), Schema::listItem()->position(2)->name($category->name)->item(route('category.show', $category)), Schema::listItem()->position(3)->name($product->name)->item(route('products.show', $product)), ]); Explore our expert insight on improvement of common laravel mistakes. ### Open Graph & Twitter Cards Social Sharing Optimization Every shareable page needs Open Graph and Twitter Card tags so links look right when shared, this doesn't directly affect Google rankings, but it does affect click-through from social channels: Build this as a reusable Blade component () so every controller doesn't have to redeclare the same block. ## Laravel Performance Optimization for SEO [Core Web Vitals](https://developers.google.com/search/docs/appearance/core-web-vitals) are a confirmed, if modest, ranking factor, and a much bigger factor in conversion rate and bounce rate. Laravel gives you a lot of direct control here. ### Improve Core Web Vitals Largest Contentful Paint (LCP) LCP measures how fast the largest visible element (usually a hero image or heading) renders. Improve it by: eager-loading (not lazy-loading) the LCP element, serving images in modern formats at the right size, caching views and routes, and using a CDN for static assets. Interaction to Next Paint (INP) INP measures responsiveness to user interaction. In Laravel apps this is mostly a front-end JavaScript concern, minimize long JS tasks, defer non-critical scripts, and be careful with heavy Livewire component re-renders on every keystroke (debounce wire:model bindings where appropriate). Cumulative Layout Shift (CLS) CLS measures unexpected layout movement. Always set explicit width/height (or aspect-ratio) on images and embeds, reserve space for ads or dynamically loaded content, and avoid injecting banners above existing content after load. ### Laravel Caching Route Cache php artisan route:cache Compiles all routes into a single file, reducing bootstrap time on every request. Remember to run route:clear before this in your deploy pipeline if routes use closures, which can't be cached. Config Cache php artisan config:cache Combines all config files into one cached file, a small but real win on every request across a high-traffic site. View Cache php artisan view:cache Pre-compiles Blade templates so the first request after deploy doesn't pay the compilation cost. ### Database Optimization Query Optimization Use Laravel Debugbar or Telescope in development to catch slow queries before they hit production. Add indexes on any column used in WHERE, ORDER BY, or JOIN clauses, especially slug columns used for route model binding. Indexing Schema::table('products', function (Blueprint $table) { $table->index('slug'); $table->index(['category_id', 'published_at']); }); Eager Loading The classic Laravel N+1 problem directly hurts page speed and, by extension, SEO. Always eager load relationships you know you'll access in a view: $products = Product::with(['category', 'images', 'reviews'])->paginate(24); ### Asset Optimization CSS Minification Use Vite (Laravel's default bundler since Laravel 9+) for automatic minification and cache-busting in production builds: npm run build JavaScript Optimization Code Splitting Vite automatically splits JS into per-route chunks when you use dynamic imports, so users only download the JavaScript needed for the page they're on: const Chart = () => import('./components/Chart.vue'); Explore [Java Script Performance Optimizations](https://www.sayonetech.com/blog/java-script-performance-optimizations/) guide to master technical audience, and improve website speed faster. Tree Shaking Import only what you need from large libraries (import { debounce } from 'lodash-es' rather than the entire lodash bundle) so Vite can eliminate unused code at build time. ### Image Optimization WebP & AVIF Convert uploads automatically using Intervention Image or a queued job on upload, storing multiple formats/sizes rather than converting on every request. Responsive Images small }} 480w, {{ $image->medium }} 800w, {{ $image->large }} 1200w" sizes="(max-width: 600px) 480px, (max-width: 1000px) 800px, 1200px" src="{{ $image->medium }}" alt="{{ $image->alt }}"> Lazy Loading As covered earlier, apply everywhere except the LCP element. CDN Integration Serve compiled assets and media through a CDN (CloudFront, Cloudflare, Bunny) rather than directly from your app server. This reduces server load, improves Time to First Byte for users far from your origin server, and is a near-zero-effort win once your .env ASSET_URL and storage disk are pointed at the CDN. ## Advanced Laravel SEO SEO-Friendly Routing Group related routes with consistent, descriptive prefixes and route names, and avoid deeply nested route parameters that produce ugly, hard-to-share URLs. Keep route names semantic (products.show, not p.s) since they show up in canonical/sitemap generation code throughout the app. ### Multi-Language SEO hreflang If you serve multiple languages or regions, hreflang tags tell Google which version to show to which audience, and prevent duplicate-content penalties between language versions: Localized URLs Prefer translated URL segments (/es/productos/silla) over a single English slug reused across locales, this is both a UX and relevance improvement for non-English searchers. Language Detection Use middleware to detect locale from the URL segment (most SEO-friendly), not from Accept-Language headers or cookies alone, since server-side redirects based on headers can create crawlability and caching problems for bots. International SEO Beyond language, consider whether you need country-specific domains or subdirectories (example.com/uk/ vs example.co.uk), separate Search Console properties per region, and currency/shipping information that matches the searcher's likely location. ### Programmatic SEO Dynamic Landing Pages Programmatic SEO means generating large numbers of targeted landing pages from structured data: think "Best CRM software for [industry]" pages generated from a database of industries, or city-specific service pages. Laravel's Eloquent and route model binding make this pattern natural: Route::get('/best-crm-for/{industry:slug}', [CrmController::class, 'show']); Database-Driven SEO Pages The risk with programmatic SEO is thin, templated content that reads as spam to both users and Google's quality systems. Make sure each generated page has genuinely unique data (real statistics, real examples) beyond just a swapped noun in a template sentence. ### SEO Automation Automatic Meta Generation Build a model observer or trait that auto-generates a fallback title/description whenever a record is saved without one: protected static function booted() { static::saving(function (Product $product) { $product->meta_title ??= Str::limit($product->name, 60); $product->meta_description ??= Str::limit(strip_tags($product->description), 155); }); } Automatic Sitemap Updates Rather than regenerating your sitemap on every request, dispatch a queued job to rebuild and cache it whenever content changes, or run it on a schedule: $schedule->call(fn () => Artisan::call('sitemap:generate'))->daily(); ### Laravel SEO for JavaScript Applications Laravel + Vue SEO A Vue SPA mounted on a single Blade shell renders empty on first load, crawlers relying on the initial HTML response will see nothing. Mitigate with SSR (via Vue's server renderer or a service like Prerender.io) or by moving to Inertia, which avoids the problem entirely. Laravel + React SEO Same issue applies with a pure React SPA consuming a Laravel API. If you need React specifically, consider Next.js as the front end talking to Laravel as a headless API, since Next handles SSR/SSG natively. Laravel + Inertia.js SEO Inertia is generally the best of both worlds for Laravel SEO: it still does an initial server-rendered response through Laravel's routing and controllers, so meta tags and content are present on first load, while giving you a full SPA experience after hydration. Set page-specific meta via Inertia's Head component (Vue) or Head from @inertiajs/react. Laravel Livewire SEO Livewire renders server-side by default, which is a genuine SEO advantage over a client-rendered SPA; the initial HTML already contains real content. Just be careful with wire:navigate, which can behave like client-side routing; confirm the URL and meta tags actually update per page rather than staying static across navigations. Server-Side Rendering (SSR) If you do need a heavier JS framework, SSR (or at minimum, prerendering) ensures crawlers receive fully-formed HTML rather than an empty
. Test this directly with Google Search Console's URL Inspection tool's rendered HTML view, don't assume it works just because the page looks fine in a browser. ## E-commerce SEO in Laravel Product Page SEO Each product page needs a unique title, description, and Product schema (price, availability, rating). Avoid manufacturer-supplied duplicate descriptions across product catalogs, write unique copy, or at minimum vary it enough to avoid duplicate-content flags across your own catalog and competitors using the same supplier feed. Category Page SEO Category pages should have genuine intro copy (not just a product grid), a clear H1, and pagination handled with unique URLs per page rather than infinite scroll with no URL state. Faceted Navigation SEO Filters (?color=red&size=M) can generate near-infinite URL combinations. Canonicalize filtered views back to the base category URL, noindex filter combinations that don't have significant independent search demand, and block low-value combinations in robots.txt if they're not worth crawling at all. Product Schema Reuse the Product schema pattern from earlier, but for e-commerce specifically, include aggregateRating and review sub-schema when you have real customer reviews, this is what unlocks star ratings in search results. Managing Duplicate Product URLs Products that appear in multiple categories often generate duplicate URLs (/electronics/product-x and /deals/product-x). Pick one canonical URL per product and reference it consistently, regardless of which category page linked to it. ## Local SEO for Laravel Websites Local Business Schema For location-based Laravel apps, add LocalBusiness schema with name, address, phone, hours, and geo-coordinates: Schema::localBusiness() ->name($location->name) ->address(Schema::postalAddress() ->streetAddress($location->address) ->addressLocality($location->city)) ->telephone($location->phone) ->openingHours($location->hours); Google Business Profile Integration Keep your Google Business Profile listings consistent with the NAP (Name, Address, Phone) data on your Laravel site, inconsistency between the two is a common trust signal issue for local search. Location Landing Pages If you serve multiple physical locations, generate a dedicated landing page per location from your locations table, each with unique local content (not just a swapped city name), local schema, and a map embed. ## SEO Monitoring & Analytics Google Search Console Verify your Laravel site via DNS or HTML file/meta tag, then monitor coverage reports, indexing issues, and manual actions. This is also where you'll catch soft-404s and crawl errors specific to your route structure. Google Analytics 4 Install GA4 via gtag.js in your layout, or use a package like spatie/laravel-analytics to pull reporting data directly into an internal dashboard. Bing Webmaster Tools Often skipped, but worth the five minutes of setup, Bing (and by extension, some AI assistants that source from Bing's index) still represents meaningful traffic for many niches. Monitoring Keyword Rankings Use a third-party rank tracker (Ahrefs, SEMrush, or a lighter tool) to monitor target keyword positions over time, and correlate ranking changes with deploys, a performance regression from a bad deploy can quietly tank rankings weeks later. Tracking Core Web Vitals Pull field data from the Chrome UX Report (via PageSpeed Insights API) rather than relying solely on lab data from Lighthouse, since field data reflects what real users on real networks actually experience. ## Laravel SEO Audit Checklist Technical SEO Checklist - robots.txt allows important paths, blocks sensitive ones - XML sitemap exists, is submitted to Search Console, and updates automatically - Canonical tags present and correct across all page types - No orphan pages; internal linking reaches every important URL - HTTPS enforced sitewide with HSTS enabled On-Page SEO Checklist - Every page has a unique title and meta description - One H1 per page, logical heading hierarchy below it - All meaningful images have descriptive alt text - Internal links use descriptive anchor text Performance Checklist - Route, config, and view caches enabled in production - No N+1 queries on high-traffic pages - Images served in modern formats, lazy-loaded below the fold - CDN in front of static assets Content Optimization Checklist - No thin or duplicate content across programmatic pages - Structured data validated (Google's Rich Results Test) - Breadcrumbs implemented sitewide with matching schema Security Checklist - SSL certificate valid and auto-renewing - Secure, SameSite cookies configured - Sensitive routes excluded from indexing ## Common Laravel SEO Mistakes - Blocking search engines, leaving a staging robots.txt (Disallow: /) live in production - Duplicate content, filter/sort/pagination variants with no canonical tag - Missing canonical tags, especially on dynamically generated pages - Slow page speed, no caching, no eager loading, unoptimized images - Broken internal links, from renamed slugs or deleted records with no redirect - Incorrect redirects, using 302 (temporary) where a 301 (permanent) is needed after a slug or URL structure change - Thin content, programmatic pages that are just a template with a swapped variable and nothing else of substance. ## Recommended Laravel SEO Packages Laravel SEO Packages - artesaos/seotools, centralized meta tag, Open Graph, and Twitter Card management - spatie/laravel-sluggable, automatic slug generation and uniqueness handling Sitemap Packages - spatie/laravel-sitemap, programmatic sitemap and sitemap index generation Structured Data Packages - spatie/schema-org, fluent, typed JSON-LD schema builders for all major Schema.org types Image Optimization Packages - spatie/laravel-medialibrary, file handling, conversions, and responsive image generation - intervention/image, on-the-fly image manipulation and format conversion Performance Packages - Laravel Octane, keeps your app in memory between requests for dramatically faster response times - spatie/laravel-responsecache, full-page response caching for cacheable routes ## Laravel SEO Best Practices Do's -Treat SEO as part of the architecture decision, not a post-launch patch - Automate meta tags and sitemaps from your data model rather than hand-maintaining them - Monitor Core Web Vitals with real field data, not just local Lighthouse runs - Canonicalize aggressively on any page type with filter/sort/pagination variants Don'ts - Don't expose raw IDs in public URLs when a slug is possible - Don't let a JavaScript front end ship without confirming crawlers can see rendered content - Don't treat schema markup as optional, it's often the highest ROI, lowest effort SEO win available - Don't skip redirects when changing URL structures Future-Proof Your Laravel Website Search continues shifting toward AI-generated answers (Google's AI Overviews, ChatGPT search, Perplexity) that pull from structured, clearly-attributed content. The technical fundamentals in this guide (clean semantic HTML, accurate structured data, fast performance, and genuinely unique content) are exactly what these systems favor when selecting sources to cite. Investing in them now pays off across both traditional search and this newer generation of AI-driven discovery. ## Frequently Asked Questions Is Laravel good for SEO? Yes. Laravel has no inherent SEO disadvantage compared to any other framework or CMS, it gives you full control over routing, rendering, and performance, all of which are core SEO factors. The tooling just requires manual setup rather than a plugin install. How do I optimize a Laravel website for Google? Start with the fundamentals: clean URLs, HTTPS, a working sitemap, unique titles/descriptions per page, and fast load times via route/config/view caching and query optimization. Layer in structured data and Core Web Vitals improvements from there. Which Laravel SEO package is best? There's no single "best", most teams combine artesaos/seotools or a custom meta component for tags, spatie/laravel-sitemap for sitemaps, and spatie/schema-org for structured data. How can I improve Core Web Vitals in Laravel? Enable route/config/view caching, eliminate N+1 queries with eager loading, serve optimized and lazy-loaded images, minify and code-split JS/CSS via Vite, and put a CDN in front of static assets. Does Laravel support Schema Markup? Yes, Laravel has no built-in schema generator, but packages like spatie/schema-org make it straightforward to generate valid JSON-LD directly from your Eloquent models. How do I create an XML sitemap in Laravel? Use spatie/laravel-sitemap to generate a sitemap programmatically from your database records, cache the output, and regenerate it on a schedule or whenever content changes. ## Conclusion Laravel SEO comes down to the same fundamentals as SEO anywhere else, crawlability, relevance, and performance, implemented through Laravel's specific tools: routing, Eloquent, Blade, caching, and the artisan console. The framework doesn't hand you SEO for free the way a CMS plugin might, but it gives you more precise control once you build the layer yourself. ### Final Laravel SEO Checklist Before calling a Laravel project "SEO-ready," confirm: clean URLs with slugs, HTTPS enforced, a working auto-updating sitemap, unique meta tags per page, canonical tags on every dynamic page type, structured data on key page types, strong Core Web Vitals scores, and no orphaned or thin content across your database-driven pages. ### Next Steps for Improving Your Rankings Run a full technical audit against the checklist above, prioritize fixes by traffic impact (start with your highest-traffic templates, not edge cases), and set up ongoing monitoring in Search Console and GA4 so regressions get caught within days, not months.

I said goodbye to Queues and Horizon

2026-10-03T05:32:58+00:00

I replaced our Queue/Horizon tier with a database-backed job engine; now stable, feedback welcome Background: I run a fairly large Queue/Horizon implementation (six-figure job counts, multi-host workers, nightly batch DAGs hundreds of jobs wide), and I kept hitting the same architectural wall: once a job is handed to a worker, the system can't tell you which process is running it, whether that process is still alive, or whether it's safe to retry. Everything is inferred from timeouts. When a host died mid-batch, healing a complex chain of dependent jobs was effectively impossible — orphaned members, blind retries of non-idempotent work, no audit trail. So I rolled my own. After ten public betas running our entire production background tier, I've cut a stable release and would love eyes on it: **JobWarden** — https://github.com/kpconnell/laravel-jobwarden The summary: the system knows at all times what is running where, and recovers from infrastructure failure using verified process liveness — not timeouts. - Database-backed (no Redis): jobs, attempts, logs, results, and audit events are durable SQL rows - Every attempt runs in its own child process, stamped with host / PID / start time / fencing token - Non-idempotent jobs are never blindly re-run — lost work parks for an operator instead - Batches: fan-out, chains, and arbitrary DAGs with failure policies; retrying a failed upstream revives the dependents that were canceled downstream - Scheduling that handles overlaps and missed cron ticks the way you'd expect, with run history - Livewire operator console + JSON API (screenshots in the README) ![A 239-node production batch DAG](https://raw.githubusercontent.com/kpconnell/laravel-jobwarden/main/docs/images/dashboard-batch-dag.png) Fair warning on requirements: PHP 8.3+, Laravel 11/12, Linux only (it leans on `pcntl` and `/proc` — that's where the process-identity guarantees come from). I'd particularly value feedback on the job-authoring API (constructor param binding, method-injected `handle()`) and on whether the docs make the recovery model clear. Happy to answer anything about the internals — the fencing/orphan-detection design was the hard part. [Laravel JobWarden](https://github.com/kpconnell/laravel-jobwarden) ![](https://github.com/kpconnell/laravel-jobwarden/raw/main/docs/images/dashboard-overview.png)

Released Laravel Cooldown: A Driver-Based Cooldown Manager

2026-10-03T05:32:58+00:00

Hi everyone! 👋 I've just open-sourced **Laravel Cooldown**, a package for managing **action cooldowns** in Laravel. While Laravel's built-in `RateLimiter` is excellent for request throttling, I found myself repeatedly needing a reusable solution for **time-based action restrictions**, such as: * Password reset requests * Email verification * OTP / SMS sending * AI prompt generation * Report exports * Payment retries * Reward claiming * Other workflow-based cooldowns My goals were to make it: * Driver-based (Cache & Database) * Easy to attach to Eloquent models * Middleware-friendly * Extensible with custom storage drivers * Pleasant to use through a fluent API Example: ```php Cooldown::for('password_reset', $user)->enforce(); // Perform the action... Cooldown::for('password_reset', $user)->for(300); ``` Some features include: * Cache & Database drivers * Native Eloquent integration (`HasCooldowns`) * Route middleware * Success-only cooldown triggering (only starts after successful 2xx/3xx responses) * Immutable DTOs * Event dispatching * Automatic database pruning * Custom driver support via `Cooldown::extend()` One design decision I'm particularly interested in feedback on is the middleware behavior. Instead of starting the cooldown before the request executes, it only creates the cooldown after a successful response. That way, validation errors or failed requests don't unnecessarily lock users out. I'd really appreciate any feedback on the API, architecture, naming, or overall developer experience. Suggestions for additional drivers or features are also very welcome. Repository: https://github.com/zaber-dev/laravel-cooldown Thanks!

Open-Source Textile ERP Built with Next.js 16

2026-10-03T05:32:58+00:00

Hey everyone, I recently built an open-source Textile ERP system and wanted to share it with the community here. While this is built entirely in the Next.js ecosystem, I know a lot of us use React/Next.js alongside our typical backend stacks, so I thought it might be of interest or serve as a good frontend architecture reference! It's designed to handle standard ERP operations tailored specifically for the textile industry. **The Tech Stack:** * **Framework:** Next.js 16 * **Styling:** Tailwind CSS * **Database/ORM:** Prisma **Repository:** https://github.com/imranbru99/textile-erp-nextjs I would love for you to check it out. Feedback, code reviews, and PRs are more than welcome. If you find it useful or interesting as a reference for your own full-stack projects, a star on the repo would be highly appreciated. Let me know what you think of the structure or if you have any suggestions for improvement!

I built an Eloquent-style ORM for Node.js

2026-10-03T05:32:58+00:00

Been writing Laravel for years. Every time a project pulls me into Node.js territory, whether it's a side project, a microservice, or just helping a team, the first thing I notice is that nothing feels like Eloquent. Prisma is fine but it's a different mental model entirely. TypeORM is verbose. Drizzle is SQL-first in a way that's almost too raw. None of them have scopes, observers, morph relationships, or that clean fluent API that just *clicks* once you know it. So I built one. It's called **IlanaORM** (`ilana-orm` on npm). It runs on Node.js and TypeScript, built on Knex.js under the hood, and the API is as close to Eloquent as I could get it. Here's what the same pattern looks like side by side: **Laravel Eloquent:** ```php $posts = Post::published() ->with('author') ->orderBy('created_at', 'desc') ->get(); ``` **IlanaORM:** ```ts const posts = await Post.query() .published() .with('author') .orderBy('created_at', 'desc') .get(); ``` Scopes work exactly the same way. Define them on the model, chain them on queries. Relationships (`hasOne`, `hasMany`, `belongsTo`, `belongsToMany`, `morphTo`, `morphMany`, `hasManyThrough`) all work. Soft deletes, casting, events, observers, global scopes, factories, seeders, migrations, all in there. A few things beyond standard Eloquent: - **ULID and UUID primary keys** supported (opt-in) - **pgvector support** built in for AI/embedding search - **Edge runtime support** (Cloudflare Workers, Next.js edge routes) - Supports MySQL, PostgreSQL, SQLite, and Supabase - No code generation step It is live now. Docs are at https://raphwebb.mintlify.com and the package is `npm install ilana-orm`. GitHub: https://github.com/raphyabak/ilana-orm Genuinely curious what you all think, especially if you've worked in both Laravel and Node.js and felt the same frustration. Happy to hear what's missing or what I got wrong.