tridentcrew.com was a WordPress site running the Renev theme before we rebuilt it on Next.js 15. The migration was not a vanity project — we needed Core Web Vitals to pass on real-user mobile data, we wanted to ship per-service landing pages without fighting a page builder, and we wanted the same modernization path we now sell to clients to be something we had done ourselves. This post is the full playbook: the technical migration, the URL strategy, the schema work, and what actually happened in Google Search Console during the first 30 days. It is the post we wish had existed when we started.
Why we migrated
WordPress was fine for what it was — a content management system that lets a non-technical person edit pages. It is not fine when you want a custom design system, predictable performance, integrations with services like Appwrite for blog management, or schema markup that is not constantly being overwritten by a theme update. Every problem we wanted to solve had a WordPress plugin answer, but each plugin added load time, security surface, and another version dependency. We did the math on plugin license fees over five years and the number embarrassed everyone.
The breaking point was Core Web Vitals. The Renev theme shipped with render-blocking scripts that pushed LCP past 4 seconds on mid-range Android phones — typical for our Indian audience. We tried the standard WordPress performance plugins. Nothing got us below 3.2 seconds. Lighthouse mobile scored 58. Google's CrUX field data was worse than the lab.
We started the Next.js rebuild with three non-negotiable targets: LCP under 2.0 seconds on real-user mobile data, INP under 200ms, and a build process where shipping a new page does not involve clicking through a wp-admin UI.
The 47 URLs we did not know about
The first surprise was Google Search Console reporting 47 URLs returning 404 after we launched the Next site. We had migrated the pages we knew about — Home, About, Services, Contact, FAQ — but Google had indexed dozens of URLs we had forgotten existed. Sample tag archives (/tag/marketanalysis/, /tag/brandstrategy/), category pages (/category/blog/, /category/web-design-trends/), author archives (/author/yuvraj/), date archives (/2025/04/14/), WordPress sample posts (/hello-world/, /blog-one/, /blog-two/), the standard Renev demo content (/from-concept-to-clicks-master-your-online-web-design-space/), and various /projects/{slug}-2/ entries created by WordPress's duplicate-slug suffix.
Every one of these had been crawled and indexed by Google during the WordPress era. After the migration, they all 404'd. Left alone, Google would retry-crawl them every few weeks, keep them in the “Not found” report indefinitely, and not consolidate any latent link equity.
The right answer is not “leave them as 404.” HTTP 410 Gone is a much stronger signal — it tells Google the URL is permanently removed and intentional, and Google drops 410s from the index in 1–2 weeks instead of months. For the URLs that mapped cleanly to a current canonical page (/contact-us/ → /contact, /about-us/ → /about, /faqs/ → /faq, /service/ → /services), we 301 redirected. For the WordPress/Renev placeholder content that never had unique value, we 410'd via Next.js edge middleware. We classified all 47 URLs into one of those two buckets and shipped both responses in one deploy.
The redirect map
The legitimate-redirect bucket has 11 entries. Each is a 1:1 mapping where the old WordPress URL has a clear modern equivalent. We codified the list in a data file so anyone can audit and extend it as new 404s appear in GSC. Sample entries: /contact-us → /contact, /about-us → /about, /our-team → /about (the team lives on the About page), /faqs → /faq, /privacy-policy-2 → /privacy-policy, /testimonials → /#testimonials, /service → /services (singular form), /project and /projects → /work (WordPress permalink style; we use /work).
For the /services/web-development URL specifically — which existed under WordPress as a Renev portfolio CPT — we initially redirected it to a hash anchor on /services. After per-service landing pages shipped, that URL now resolves naturally to /services/web-development as a real route. No additional redirect needed.
The 410 strategy
The 36-URL gone bucket lives in a Next.js edge middleware with a path matcher restricted to known legacy patterns. The matcher only fires for paths that could plausibly be legacy URLs — /category/*, /tag/*, /author/*, /project-cat/*, the WordPress sample-post slugs, and the YYYY/MM/DD date-archive regex. Anything not matching the patterns skips the middleware entirely. The hot path (/, /services, /blog/*, /api/*) pays zero latency cost.
When middleware returns 410, the response includes a small HTML body with noindex meta and X-Robots-Tag headers, plus links back to the five main pages. The rare human visitor who hits one of these URLs gets a friendly explanation, not a Next.js default 404.
Schema migration
WordPress had Yoast SEO generating Schema.org JSON-LD that we did not control directly. The migration was a chance to do this properly. We hand-wrote Organization + LocalBusiness + ProfessionalService for the company, Service for each service offering, BlogPosting for posts, FAQPage for FAQs, BreadcrumbList for navigation, and SpeakableSpecification for AI/voice extraction.
Google's Rich Results Test flagged three warnings on the first deploy. Each turned out to be a real bug, not a tool quirk. AggregateRating contained itemReviewed: {@id: #organization} — invalid when nested inside the Organization itself because it creates a circular reference. ProfessionalService was applied to each service offering — wrong, because ProfessionalService is a LocalBusiness subtype and each service does not have its own address. OfferCatalog had a provider property on the root — not a valid property on OfferCatalog at all. We shipped the fixes in two follow-up commits. Zero warnings now.
The lesson: validator.schema.org is stricter than Google's Rich Results Test. Run both. Fix the warnings the strict validator flags, because Google's algorithm is moving toward stricter parsing over time.
Going live: HSTS, IndexNow, sitemap
Pre-launch checklist:
Strict-Transport-Security header with
max-age=63072000, includeSubDomains, preload. After the header has been live for a month, submit at hstspreload.org to bake the upgrade into Chrome's preload list.Server-side sitemap.xml that pulls from the actual data layer (not a hard-coded list), so admin-created blog posts auto-appear.
robots.txt expanded from the 8 user-agents Yoast had configured to 22 — adding explicit allows for AI answer-engine bots (GPTBot, ChatGPT-User, OAI-SearchBot, ClaudeBot, Claude-Web, Claude-SearchBot, PerplexityBot, Perplexity-User, Google-Extended, Applebot, Applebot-Extended, Meta-ExternalAgent) and explicit disallows for
/tcadminpanel/and/api/.IndexNow integration. Generate a key, set
INDEXNOW_KEYenv var, expose the key at a verifiable URL. Wire the admin POST/PUT/DELETE for blog posts to fire-and-forget ping IndexNow with the affected URL plus/blogplus/. Bing, Yandex, Naver, and Seznam pick up changes within minutes instead of waiting for their own crawl schedule.Domain consolidation. We owned
tridentcrew.comandtridentcrew.in. Vercel handles the apex/www redirects; we added Next.js host-based redirects as a defensive backup.tridentcrew.in301s totridentcrew.comat every path.
Costs and timeline
Total engineering time for the migration: 60 hours over four weeks, including the URL audit, schema work, post-launch GSC monitoring, and the two follow-up commits that resolved schema warnings. At a fair internal rate that values founder time, the project came in around ₹1,80,000 of effort.
We did not bill ourselves for this work, obviously. For a client migration of similar scope — typical WordPress agency site with 15–30 pages, 5 forms, a blog, and standard plugins — TridentCrew quotes ₹1,50,000 to ₹3,50,000 depending on plugin complexity and legacy URL volume.
Should you migrate?
The math works for any business where the answer to “do you care about Core Web Vitals, real performance on Indian mobile, control over schema, and not paying perpetual plugin license fees” is yes. For a personal blog or a small content-only site where the owner edits prose weekly via wp-admin, WordPress is still the right answer.
If you are evaluating a migration, the right first step is a 30-minute audit call. We will look at your current Lighthouse scores, your plugin stack, your indexed-pages count, your hosting bill, and your post-launch maintenance pattern. The output is a written recommendation — migrate, do not migrate, or migrate in two phases — with a cost estimate either way. The audit is free.
Book it via the contact form or read more about how we work on the Web Development service page.