Corporate websites on Laravel: panel, languages and ownership

A corporate website on Laravel is not painting a ready-made corporate theme. Content types, permissions, who receives the form and language counterparts are written around your work. That flexibility is not free: it needs maintenance, updates and a developer’s hand. The choice is made by how the team will update the site, not by a “it looks more modern” taste.

Yuz Medya runs this site on Laravel 12 and a Filament panel. The point is not a showcase. It is changing everyday copy without opening a code file. The same approach holds for client work. If an editor only posts a notice, WordPress may be enough. If a quote form, a service tree and two languages live on the same record, Laravel leaves less plugin debt. That split sits in Laravel or WordPress.

The panel is the publication

On a corporate site the real product is often the panel you open, not only the page a visitor sees. If adding a service, changing a cover, FAQs, menus and SEO fields do not live there, every comma starts a round-trip to the agency. That is why Filament is chosen: lists, forms and permissions share one language. “The agency can keep the admin password” means that three months later nobody can update the copy. The account is opened in your name. Training is part of delivery.

Content types are written first. Service, project, article and reference are separate records. Piling everything into “a page” is how you forget where a sentence lives a year later. The information architecture in what a corporate website should be becomes models in the panel. If the architecture stays on paper, the panel scatters too.

Languages and SEO on the same record

Two languages are not two copies of the site. The same service keeps separate TR and EN slugs, titles and meta. A record whose translation is unfinished does not publish in the other language. Hreflang and canonicals need a counterpart that does not vanish when the language changes. Those rules sit where technical SEO meets the corporate website. The pre-launch crawl lives on the checklist.

• Forms: a service can be preselected, with a consent box and a trap field. A visible “Website” honeypot is for spam.
• Permissions: the editor changes publishing, the developer changes the schema. One password for both is an accident waiting.
• Backups: a record deleted in the panel is gone without a server copy. The backup calendar is part of launch.

When Laravel is not the choice

A writing-heavy publication that grows through plugins moves with less friction on WordPress. If catalogue and payment already fit a standard shop, a ready ecommerce layer is discussed. Laravel does not refuse those jobs. It raises the cost. Every cost-raising decision wants a written scope. Otherwise custom software behaves like an open-ended invoice.

In discovery Yuz Medya asks three questions: who will update, which record types exist, which integrations are required. If the answer is “two notices a month”, Laravel is not pushed. If the answer is “services, languages, a quote queue, reference approval”, the panel is designed first. That is why WordPress / PHP sits in the same menu. The tool is chosen for the work, not for ego.

FAQ

Is Filament hard to learn?

Not for an editor. List, save, upload an image. The hard part is deciding who fills which field. Training is short after that decision.

Can an existing WordPress site move?

Yes. The URL map, 301s and content transfer are a separate job. “We’ll convert the theme to Laravel” is misleading. Content and redirects move. The theme is built again.

Who owns it?

The code repository, the server and the panel account should sit in your name. The agency has access. It does not take the lock away. That is a technical sentence in the contract.

Book a consultation for a Laravel corporate site.