Rebuilding TicketingHub without breaking the SEO engine

I rebuilt TicketingHub’s public marketing site from Webflow to Next.js 16 + Sanity in about four weeks.

This was not a redesign brief disguised as engineering work. It was a migration of a live acquisition surface: hundreds of indexed pages, 11 locales, legacy Webflow and Weglot URL patterns, years of backlink equity, and a marketing team that needed a CMS they could actually operate without asking engineering to move every comma.

By mid-May 2026, early SEMrush signals were encouraging: organic traffic at 9.7K (+85.95%), organic keywords at 6.4K (+6.63%), and US non-branded traffic at 761 (+76.57%). I treat those numbers as directional, not a victory lap. The real outcome was a safer system: cleaner URLs, structured content, better migration control, and a site the team can now keep improving.

The problem

TicketingHub sells ticketing software for tours, attractions and experiences. The old marketing site worked, but it had become hard to evolve safely.

The business needed to move faster across product pages, industries, integrations, case studies, legal content, and blog content. Webflow had become a bottleneck: content structure was loose, localization was awkward, SEO-critical URL behavior lived across too many places, and the site could not easily support the next phase of growth.

The risk was not only “can we rebuild the website?” The risk was: can we rebuild it without losing organic traffic, breaking localized URLs, or leaving the team with another system only one person understands?

The constraints

I worked solo across design, frontend, CMS architecture, migration scripts, i18n, SEO, accessibility, and launch hardening.

The project had real constraints:

• About four weeks to get from rebuild plan to production.
• 725 Webflow documents to move into Sanity.
• 3,503 inline images to migrate off the Webflow CDN.
• 11 locales to support with clean path-based routing.
• 19 page templates across marketing, product, blog, industries, alternatives, integrations, case studies, legal, and press.
• 52+ explicit redirects, plus dynamic legacy-locale and case-study slug handling.
• No appetite for a launch that looked good but quietly damaged search.

That last constraint shaped most of the architecture.

The decisions that mattered

I chose Sanity because the site needed structured content, not just editable pages. Blog posts, case studies, industries, integrations, alternatives, FAQs, testimonials, authors, and legal pages all needed schemas the marketing team could trust.

I chose path-based locale URLs because the old Weglot subdomain setup had created a lot of SEO surface area, but not enough control. The new model keeps English clean at /, makes non-default locales explicit, and lets metadata, canonical URLs, sitemap entries, and CMS content follow one routing model.

I treated the migration as a product, not a one-time import. The scripts were dry-runnable, resumable, and verifiable. That mattered when migrating hundreds of documents and thousands of inline images: the goal was not “run script once and hope,” it was “run, inspect, patch, verify, repeat.”

I also kept the app sized for the real surface area, not just the homepage. The rebuild shipped 19 templates driven by GROQ against 12 Sanity schemas, with loading states, error boundaries, breadcrumbs, JSON-LD, and sitemap coverage where they mattered.

Working with Cursor as a pair

A job this size would normally be a multi-person effort over several months. I did it alone in about four weeks by treating Cursor (Claude / GPT) as a second engineer rather than a toy autocomplete — mostly on three kinds of work:

• Scaffolding at speed. Sanity schemas, GROQ queries, page templates and redirect tables generated from a plain-language spec, then reviewed diff-by-diff before committing.
• Brute-force runs done safely. 11-locale translation syncs with --dry-run fingerprinting, and the 725-document migration scripts — the repetitive work an LLM is genuinely good at, done in minutes instead of days.
• Self-review on my own PRs. After each phase I asked the agent for a frank critique. Several real bugs were caught that way: urlFor null guard, 9 unsafe as Locale casts, a ContactForm sessionStorage guard, a Pagination a11y gap.

What it didn’t do: make design decisions, pick the product story, judge the brand, or push to production. That was on me — which is the point.

What almost went wrong

The sitemap was one of the smallest pieces of code and one of the easiest places to break production.

In Next.js, /sitemap.xml could be interpreted as a locale segment if it passed through the wrong route. That would mean crawlers hitting the sitemap could accidentally trigger localized page logic with "sitemap.xml" as the locale. The fix was a dedicated proxy rewrite and a shared sitemap chunk registry so generateSitemaps() and the sitemap index could not drift.

The image migration also had teeth. Webflow-hosted inline images were scattered through rich content. Leaving them behind would keep the new CMS dependent on the old platform. The final pass migrated 3,503 unique image URLs into Sanity and patched 589 documents until the external-image inventory hit zero.

The redirect layer then absorbed the long tail of Webflow slug renames, legacy locale subdomains, and funnel consolidations. An excerpt:

The review rounds were useful too. I caught and fixed things that would have been easy to miss while moving fast: unsafe locale casts, null image handling, session storage guards, pagination accessibility gaps, missing metadata cases, and contrast/focus issues.

None of those bugs are glamorous. They are exactly the kind of bugs that decide whether a rebuild survives contact with production.

Early signals

By mid-May 2026, SEMrush was showing positive directional movement:

• Organic traffic: 9.7K, up 85.95%
• Organic keywords: 6.4K, up 6.63%
• Referring domains: 1.1K
• Backlinks: 7.7K
• US organic traffic: 965, up 52.93%
• US non-branded traffic: 761, up 76.57%

These are early third-party signals, not final attribution. Search needs time. But they suggest the migration did what it needed to do first: preserve the engine, reduce risk, and create a cleaner base for growth.

What I’d do differently

I would set up the post-launch measurement story earlier.

The rebuild had strong technical proof: migration counts, redirect coverage, sitemap structure, accessibility checks, and build/test gates. But the public case for the work becomes stronger when baseline traffic, Search Console coverage, Core Web Vitals, and conversion events are captured before launch and reported cleanly after launch.

I would also separate the rebuild story from the growth story sooner. The rebuild made the system stable. The next layer is content expansion: solution pages, calculators, stronger internal linking, refreshed competitor pages, and a weekly GSC/GA4 cadence.

What's next

The rebuild gave TicketingHub a marketing platform instead of a fragile website.

The next phase is growth: solution hubs for high-intent search, better internal link mesh between blog, industries, integrations, and alternatives, and tools that turn operator pain into useful product-led acquisition.

That is the part I like most about this kind of work. A good rebuild is not the finish line. It is the moment the team finally has enough control to start compounding.

Closing

I owned every layer of this rebuild — design, app architecture, CMS model, routing and SEO edge cases, and the process that made all of it deliverable in four weeks instead of four months. The case study is the narrative; the proof is the live site: ticketinghub.com.

If you’re planning something similar — a Webflow-to-Next migration, a multilingual product site, or a full marketing rebuild without pausing for a year — I’m booking new work. Reach me at hello@edigil.com or through the contact page.