We're considering rebuilding our company website in React, possibly using Replit. The current site runs on HubSpot CMS, contains around 500 service and location pages, depends heavily on organic search, and uses HubSpot for forms, CRM data, and tracking. A custom frontend could give us more control and make it easier to add features, but we're concerned about SEO, server-side rendering, location-page management, redirects, metadata, structured data, sitemaps, Core Web Vitals, HubSpot integrations, design consistency, non-developer editing, security, hosting, maintenance, and reliance on one developer or AI-generated code. Would it be better to use a production framework such as Next.js, keep the marketing site in HubSpot and build only custom booking tools separately, or migrate everything in stages? What problems commonly appear after launch that may not be obvious during planning?
4 Answers
The page count isn’t necessarily the hard part. If the location pages follow a consistent template, they can be generated from structured content with unique titles, descriptions, canonical URLs, headings, schema, and metadata. The dangerous parts are losing URL coverage during migration, creating incorrect canonical tags, missing redirects, breaking internal links, and changing content patterns that currently perform well in search. Build a complete URL and redirect inventory and compare the old and new sites with automated crawls before launch.
I wouldn’t make Replit the production foundation for a search-dependent business site. React itself isn’t the main issue, but hosting, deployment, security, and long-term maintenance need to be treated as production engineering rather than a quick build experiment. If you want a custom frontend, use a production-oriented framework such as Next.js with server rendering or incremental regeneration, and connect it to a proper CMS so non-developers can still update content.
My default recommendation would be to leave the main marketing site in HubSpot and build the booking or other interactive tools separately in React. If HubSpot is causing serious technical or business constraints, consider a phased Next.js migration instead of a one-shot rewrite. Keep the content source and URL structure stable where possible, test HubSpot forms and tracking end to end, and use a parallel crawl plus regression checks for redirects, metadata, schema, sitemaps, and Core Web Vitals. Don’t let AI-generated code replace architecture, testing, and ownership decisions.
Before deciding, identify the specific limitations you’re trying to solve in HubSpot. A custom build can improve flexibility, but it also transfers responsibility for deployments, accessibility, analytics, security updates, backups, uptime, SEO controls, and content tooling to your team. The biggest surprise is often that marketing can no longer make a simple page change without waiting for a developer. If you migrate, include a headless CMS or a genuinely usable editing interface rather than making the frontend the only place content lives.
A staged migration is much safer than moving all 500 pages at once. Keep the existing site running, launch a representative group of pages on the new stack, and compare rankings, crawlability, page speed, forms, attribution, and publishing workflows before expanding.