Rebuilding TicketingHub without breaking the SEO engine

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

The job was migrating a live acquisition surface. It had hundreds of indexed pages, 11 locales and years of backlink equity. It carried legacy Webflow and Weglot URL patterns. The marketing team needed a CMS they could operate themselves, without asking engineering to move every comma.

By mid-May 2026, early SEMrush signals were encouraging. Organic traffic was at 9.7K (+85.95%) and organic keywords at 6.4K (+6.63%). US non-branded traffic was at 761 (+76.57%). Those numbers are early and directional. What I can stand behind is a safer system: cleaner URLs, structured content and better migration control. The team can now keep improving the site.

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. That meant product pages, industries, integrations, case studies, legal content and blog content. Webflow had become a bottleneck. Content structure was loose and localization was awkward. SEO-critical URL behaviour lived in 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 or breaking localized URLs. It also could not leave the team with another system only one person understands.

The constraints

I worked solo. Design, frontend and CMS architecture were mine. So were migration scripts, i18n, SEO, accessibility and launch hardening.

The project had real constraints:

• About four weeks 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. Editable pages were not enough. Every content type needed a schema the marketing team could trust: blog posts, case studies, industries, integrations, alternatives, FAQs, testimonials, authors and legal pages.

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

I treated the migration as a product. The scripts were dry-runnable, resumable and verifiable. That mattered with hundreds of documents and thousands of inline images. Each pass went: run, inspect, patch, verify, repeat.

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

Working with Cursor as a pair

A job this size is normally a multi-person effort over several months. I did it alone in about four weeks. I treated Cursor (Claude / GPT) as a second engineer, mostly on three kinds of work:

• Scaffolding at speed. The agent generated Sanity schemas, GROQ queries, page templates and redirect tables from a plain-language spec. I reviewed them 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. It took minutes instead of days.
• Self-review on my own PRs. After each phase I asked the agent for a frank critique. That caught several real bugs: 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. It was also one of the easiest places to break production.

In Next.js, /sitemap.xml could be read as a locale segment if it passed through the wrong route. Crawlers hitting the sitemap could then accidentally trigger localized page logic, with "sitemap.xml" as the locale. The fix was a dedicated proxy rewrite and a shared sitemap chunk registry. Now generateSitemaps() and the sitemap index cannot 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. It patched 589 documents until the external-image inventory hit zero.

The redirect layer then absorbed the long tail: 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. They are the ones that would have shown up in production first.

Early signals

By mid-May 2026, SEMrush showed 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 gets stronger with measurement. That means capturing baseline traffic, Search Console coverage, Core Web Vitals and conversion events before launch. It also means reporting them 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.
• 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.