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.

The job 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%). Those numbers are early and directional. What I can stand behind is 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 behaviour lived across too many places, and the site could not easily support the next phase of growth.

The question was whether we could 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. The scripts were dry-runnable, resumable, and verifiable, which mattered with hundreds of documents and thousands of inline images. Each pass went: 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, 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. This is the repetitive work an LLM is 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: a missing 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. Those stayed with me.

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.

These are small bugs, and they are the ones that would have shown up in production first.

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, a 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. After a rebuild like this, the team finally has enough control to keep improving the site on its own.

Working together

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

I am open to full-time, part-time and contract work, whether that means joining a product team or taking on a project like this one. Write to hello@edigil.com or use the contact page.