Does SEO work with Inertia?

Yes, via Inertia's server-side rendering (SSR). For a public site we enable it; for an internal application, it isn't necessary.

React or Vue with Inertia?

Both are supported. I mainly work with React/TypeScript, but Vue is just as valid depending on your preferences.

Can Inertia be added to an existing Laravel project?

Yes, gradually: you can modernise certain parts with Inertia without rewriting the whole application at once.

When is a true separate API + SPA preferable?

When several clients consume the data (mobile app + web), or for very demanding interfaces. Otherwise, Inertia is simpler and faster to deliver.

Expertise

Freelance Inertia.js developer

Modern applications with Inertia.js (Laravel + React)

Want a modern, responsive interface without paying the price of a separate API? Inertia connects your Laravel back end to a React front end, and I use it every day, starting with this very portfolio.

Tell me about your project View services

Kylian Bellegarde, freelance web developer in Martinique, working on a Laravel and React application with Inertia.js

Smooth SPA interfaces with no REST API to maintain.

Server-side routing and controllers, React components on the client.

SEO possible via Inertia SSR, native Laravel security and sessions.

Inertia.js connects a Laravel or Symfony back-end to a React (or Vue) front-end without building or maintaining a separate API. The result: modern, smooth SPA-style interfaces with the simplicity of a classic server-side application. It's the stack behind this portfolio.

When you want an interface that responds instantly (no page reloads, smooth transitions, instant forms), the usual instinct is to build the application in two pieces: an API on one side, a React or Vue SPA on the other. It works, but it doubles the workload. You maintain two projects, you version endpoints, you rewrite on the front end part of the logic that already exists on the server, and you spend an enormous amount of time managing token-based authentication.

Inertia removes that middle layer. Your Laravel controllers return data directly to the page's React components, just as if they were returning a Blade view, but the rendering happens in JavaScript in the browser. In practice: you write a server route, a controller, a page component, and that's it. No fetch calls to wire up by hand, no API schema to document, no duplication of business rules.

The mechanism is easy to picture. On the very first load, the server returns a normal HTML page that boots the application. After that, every click on an Inertia link triggers a background request: the server responds with only the data for the new page, in JSON, and the front end swaps the component on screen without reloading the browser. That's what creates that sense of instant response, while keeping real URLs, a working back button, and shareable pages. You can even reload just part of a screen's data, or preload it on link hover, so navigation feels immediate.

The result is an application that behaves like a SPA for your user (instant navigation, preserved state, zero white flash between pages) while being built like a traditional server application. It's precisely that combination that makes Inertia productive: you keep the comfort of Laravel and gain the modern feel of React, without the architectural cost that normally comes with it.

It's also the stack this site runs on. When I recommend Inertia to you, it isn't a gamble: it's the tool I use for my own work, and one I know inside out, including its limits.

The point I find most underrated is security. With a separate API + SPA, you have to manage token-based authentication (often JWT): where you store the tokens, when they expire, how you refresh them, how you protect against token theft. It's a classic source of vulnerabilities and subtle bugs. With Inertia, you keep Laravel's native authentication and sessions, exactly as on a server application. The same battle-tested mechanisms (secure cookies, CSRF protection, middleware) still apply. Less code to write, and a smaller attack surface.

Validation follows the same logic. You validate forms on the server with the Laravel rules you already know, and Inertia automatically brings the errors back into your React components, ready to be displayed under each field. The form component Inertia provides handles input state, the submitting indicator and the reset after success for you: you write very little plumbing code, and you focus on the screen. No need to reimplement validation twice. A single source of truth, on the server, where it belongs.

I add TypeScript on top, which lets me share types between the back end and the front end: the shape of the data a controller sends matches what the component expects, checked at compile time. A good share of integration bugs disappears before the application even runs. When a field changes name or type on the server, the editor immediately flags the screens to update, instead of letting me discover the problem in production.

Inertia also knows how to send only what's needed. Heavy or secondary data for a screen can be loaded on demand rather than on every visit, and the content common to all pages (the logged-in user, flash messages, the theme) is shared once and for all. You avoid needlessly carrying kilobytes on every navigation, which keeps the application lightweight even as it grows.

Day to day, that means a single coherent repository, a single deployment, a single set of business logic. For a freelancer as much as for your team, that's fewer moving parts to understand and maintain over time. Maintainability is one of my four pillars, and Inertia clearly works in its favor here: a bug is fixed in one place, a version upgrade is handled on a single project, and whoever picks up the code doesn't have two worlds to learn.

I always start with scoping: Laravel or Symfony depending on what's already there, React (my main turf, in TypeScript) or Vue depending on your preferences, and above all the question of SSR for SEO, which we settle from the outset. Making these choices early avoids backtracking later. From there, I set up the application's skeleton: server-side routing, a persistent layout that stays in place while pages come and go, the base components and the types shared between back end and front end.

Then development happens page by page, screen by screen. It's a rhythm that gives you visibility: you watch the application fill in progressively, you can test each flow as soon as it's ready, and we adjust along the way rather than discovering everything at the end. Each screen arrives with its server-side validated forms, its polished loading states and its transitions, so the whole thing stays coherent and pleasant to use.

In practice, Inertia is my default choice for anything application-driven and rich in interactions: back-offices, dashboards, client portals, internal applications, SaaS products. As soon as there are lots of screens, forms and states to handle, and you want a smooth experience without taking on heavy architecture, it's often the best trade-off. A management back-office, a space where your clients track their orders or documents, a business tool replacing a cobbled-together spreadsheet: these are the areas where Inertia delivers the most.

It's also an excellent path for modernizing an existing Laravel application without breaking everything. You can switch certain parts to Inertia gradually, screen by screen, while keeping the rest of the back end intact. You don't have to choose between living with an aging interface and funding a complete rewrite: we move in stages, deliver value at each step, and keep the risk under control. The project wraps up with enabling SSR if SEO requires it, an optimized build and a supervised production release.

The question that always comes up is search ranking. By default, an Inertia page is rendered in JavaScript, which isn't ideal for a public page that needs to be perfectly indexed. The answer is Inertia's server-side rendering (SSR): the server generates the page's full HTML on first load, crawlers and visitors receive already-rendered content, and React interactivity takes over afterward. We enable it when SEO calls for it, and either way you keep control over each page's title tags, metadata and structured data.

In practice, I decide based on the use case. For an internal application or a client portal behind a login, SEO is pointless: we don't enable SSR, and it's simpler. For a public site where search ranking matters, I enable SSR and take care over the server rendering, the tags and performance. The choice is made during scoping, not blindly: you only pay the complexity of SSR where it genuinely pays off.

Performance matters as much as markup, for Google as much as for your visitors. A server-rendered page displays quickly, and Inertia's internal navigation avoids full reloads: you keep a fast site, which helps both search ranking and conversion rate. I check Core Web Vitals and accessibility in the browser, because good positioning today goes through a genuinely smooth experience, not just well-placed keywords.

If your project targets a local audience, in Martinique or more broadly across the French Caribbean, SEO is entirely achievable with Inertia: a well server-rendered, fast and accessible application ranks just as well as a traditional site. The challenge isn't the technology, it's enabling it in the right place rather than being subjected to it. And since I'm based here, we can talk easily, in the same time zone, about what your business genuinely needs to put forward.

Inertia 3Version used in production

Laravel + ReactBack end and front end from a single codebase

TypeScriptTypes shared between back end and front end

SSR when neededServer-side rendering for SEO

The advantages

A single coherent codebase for back end + front end: no separate API to build, version and document.
Native Laravel authentication and sessions, with no JWT tokens to orchestrate: simpler and safer.
Server-side form validation, with errors brought back automatically into the React components.
A smooth SPA experience (instant navigation, preserved state) without the usual architectural complexity.
Types shared between back end and front end via TypeScript: integration bugs stand out before production.
Gradual adoption possible on an existing Laravel project, screen by screen, without rewriting everything.
SEO covered when needed thanks to Inertia's server-side rendering (SSR).

Limitations to be aware of

Inertia assumes a back end that renders pages (Laravel, Symfony): it's not the right building block for a purely static front end or a simple showcase site.
If several clients need to consume the same data (a native mobile app in addition to the web), a true separate API remains a better fit.
SEO requires enabling and maintaining SSR: an extra step not to be overlooked on a public site.
For extremely specific interfaces or very complex client-side state, a dedicated standalone SPA can offer more latitude.

Both approaches lead to a modern interface. The real question is how many clients consume your data and how much complexity you're willing to maintain. Here's how I decide.

Choose Inertia if…

Your application is consumed by the web only: a single front end, no native mobile app to feed.
You want to ship a rich interface quickly (back-office, dashboard, client portal, SaaS) without doubling the work.
You want to keep Laravel's authentication, sessions and validation, proven and secure.
You're modernizing an existing Laravel application and want to move gradually, with no big bang.
You prefer a single repository, a single deployment and a single set of business logic to maintain over time.

Prefer something else if…

Several clients consume the same data: web plus a native mobile app, for example.
You're exposing a public API meant for partners or third-party integrations.
Your interface is so specific or so heavy on client-side state that it justifies a fully decoupled SPA.
Your front-end team and your back-end team are separate and want to work on independent repositories.
The back end isn't in PHP: without Laravel or Symfony to render the pages, Inertia loses its point.