Background
I work at Luminous Digital Visions as a Senior Frontend Engineer. The first version of the company website was built in React and TypeScript. That stack made sense during the early build because it allowed fast component-driven development and gave us a clean way to organize the interface.
After launch, we noticed an important issue: Google was struggling to index the pages properly. For a company website that depends on discoverability, service clarity, and organic visibility, that was not a small technical detail. The site was mostly a static marketing website, so depending heavily on a JavaScript-rendered frontend introduced complexity that did not match the real content need.
The Problem
The problem was not that React or TypeScript were bad choices in general. The problem was fit. The website needed crawlable service content, direct HTML output, predictable metadata, and fast page rendering. A React application was adding a layer of client-side behavior that was not necessary for the majority of the website.
For an agency site, the content is the product. Search engines and potential clients need to see clear service pages, positioning, process information, and contact paths. If that content is harder to crawl or slower to interpret, the frontend architecture becomes a business problem.
Team Decision
As a team, we decided to rewrite the site in semantic HTML, CSS, and vanilla JavaScript. The goal was to make the frontend simpler, more crawlable, and easier to reason about from an SEO perspective. This was an engineering judgment call: choose the implementation style that best serves the page, rather than keeping a framework because it is familiar or popular.
The rewrite prioritized direct content rendering, semantic page structure, and lighter JavaScript. We kept interactivity only where it supported the user experience.
Implementation
The rewrite focused on rebuilding the page sections in plain HTML and CSS while preserving a polished agency feel. We structured the homepage around the core service offer, supporting proof, process sections, and a clear contact path. JavaScript was used selectively for interactions that needed it, not as the foundation of the entire site.
The services section was especially important because it needed to communicate what the company does in a way that both people and search engines could understand. We paid attention to headings, section order, copy hierarchy, and internal page flow.
SEO And Content Structure
The SEO improvement work was mostly about removing friction. Instead of asking Google to interpret a client-rendered app shell, the rewritten pages expose the content more directly. The structure became easier to scan, easier to index, and easier to maintain.
This also made future edits more straightforward. A static agency website changes through content updates, service adjustments, and campaign messaging. The simpler codebase made those updates less dependent on a heavy frontend runtime.
Engineering Judgment
This project is a good example of practical frontend decision-making. Senior frontend work is not always about adding more tooling. Sometimes the stronger decision is removing unnecessary layers and matching the architecture to the business goal.
React and TypeScript were useful for the first version, but the production need shifted toward crawlability, simple delivery, and reliable static content. The rewrite reflects that shift.
Result
The final site became leaner and more appropriate for an agency marketing presence. The pages render content directly, the structure is easier for search engines to interpret, and the site is simpler to maintain. It also gave the team a stronger foundation for future SEO-focused service pages and campaign updates.
