How we migrated TechTenstein from WordPress: 540 legacy URLs, one decision each

21 routes were kept at their URLs (19 rebuilt pages and 2 reviewed articles), 111 were 301-redirected to genuinely equivalent pages, and 408 were retired with HTTP 410. We then checked route outcomes, canonicals, sitemap inclusion, HTTPS and rollback evidence before and after cutover. This note covers our own website. It is not a client result.

The project at a glance

Property	techtenstein.com (TechTenstein’s own website)
Starting platform	WordPress
Replacement	A custom-built, server-rendered PHP 8.3 service site, with no Composer packages, no frontend framework and no build step
Legacy routes inventoried	540, each with an explicit decision
Canonical public pages checked at release	38
Release	September 2026 deployment
Timeline	Inventory captured 12 September 2026; every route decision reviewed and the cutover verified live on 13 September 2026; follow-up releases through 25 September 2026

The problem: a service site buried in a historical footprint

A new design alone would not have fixed the old site. The former WordPress site mixed relevant service information with a much larger historical footprint. Swapping the theme would have left broken links, duplicate or thin search surfaces, and an uncertain handover.

We wanted a faster, clearer service website that still handled every existing URL deliberately. Two easy shortcuts were ruled out early:

• Keep everything. Old volume would have stayed indexable whether or not anyone needed it.
• Redirect everything to the homepage. Visitors and search engines would land somewhere that did not answer the request.

The approach: one decision for every legacy URL

The rule was simple to state and slow to apply: no legacy route gets a default outcome. Each of the 540 routes was looked at and given a decision on its own merits.

1. Back up and inventory before touching anything

We kept a recoverable copy of the old site before cutover and built an inventory of 540 legacy routes. The inventory came from a read-only WP-CLI script run against the live WordPress install. It listed every published, public, non-attachment post of any type (pages, posts, services, portfolio items and theme template surfaces) plus every populated public taxonomy archive, and recorded only public canonical URLs, never drafts or customer data. We then pulled page-level Google Search Console data so that pages with real search traffic, such as the homepage, careers, contact and about pages, were flagged for preservation or review before any decision was made.

2. Four possible outcomes per route

Outcome	When we used it	Routes
Rebuilt at the same URL	Established pages with search history or a fixed role (homepage, about, contact, legal pages, tools, blog and category hubs), given new content at their existing address	19
Kept indexable	Articles that passed an individual review	2
Redirected (301)	Only where a genuinely equivalent destination exists. 106 of these send old service, service-category and service URLs to the five new service pages	111
410 Gone	No replacement exists (166 old posts, 183 portfolio entries, theme template surfaces and other pages)	408
Total		540

Two of the 19 rebuilt pages, careers and testimonials, stay at their URLs but are marked noindex until a real vacancy or approved customer evidence exists. None of the 111 redirects points at the homepage.

Today the blog lists only articles that have passed a dated claims-and-sources review. Historical WordPress posts stay out of search until they meet that standard.

3. Why we returned 410 instead of redirecting to the homepage

When an old page has no true equivalent, saying so is more honest than a redirect that lands nowhere useful. Google’s own site-move guidance points the same way. It tells site owners to return 404 or 410 for content they are not moving, and warns against redirecting many old URLs to one irrelevant destination such as the homepage, which “might be treated as a soft 404 error”.

Our former /case-studies/ and /portfolio/ URLs are examples: they now return 410, because no approved replacement exists yet.

4. A smaller public journey

The new public site is deliberately smaller. Service pages explain scope and ownership. Free planning and bounded audit tools help visitors prepare before they enquire. Private workspace, monitoring and checkout features stay gated separately until their operational checks are complete.

The stack

• Application: a custom, server-rendered PHP 8.3 application. It has no Composer packages, no frontend framework and no build step, and it loads no third-party scripts or fonts. It is new source, not a converted copy of the WordPress site.
• Hosting: Hostinger shared hosting.
• Redirects and 410s: handled in application code. The web server sends every request to one PHP front controller. That controller reads a version-controlled redirect map and returns a 301 to the mapped page, or returns 410 for a version-controlled list of retired paths plus a few retired path prefixes (old portfolio entries and theme template surfaces).
• Release record and route read-back: an automated read-back script requests every one of the 540 inventoried URLs on production and checks the response against its recorded decision. Each release is logged as a dated record in the private source repository, with the assertion counts, file checksums and a rollback copy. A full test suite also runs in CI on pushes and pull requests.
• The old WordPress install: before cutover, the full WordPress files and database were backed up with checksums, and the database dump was test-restored into an isolated database. The old site is kept as a private, recoverable backup outside the public web root. The old database was not changed.

How we verified the release

The migration was treated as a release with evidence, not as a design launch. Before and after cutover we tested:

• Route outcomes: each legacy URL returned the decision it was given.
• Canonicals: every public page points to itself as the canonical URL.
• Sitemap inclusion: the sitemap lists the canonical public pages and nothing retired.
• HTTPS: pages are served securely.
• Public pages: the new pages load and behave as expected.
• Rollback evidence: we could return to the previous state if the cutover failed.

Results: what the checks show, and what they do not

Release and page checks

The release record shows 540 migration-route outcomes read back and 38 canonical public pages checked in the September 2026 deployment.

A later bounded run of our website audit scored the homepage 100 after a title correction, and a separate mobile PageSpeed Insights laboratory run also scored 100. These are point-in-time checks. They do not promise a score of 100 on every device, they are not evidence of passing all Core Web Vitals, and they do not prove better rankings or more enquiries.

Measure	Before (WordPress)	After
Mobile PageSpeed Insights lab score, homepage	Not available. PageSpeed Insights returned HTTP 429 (rate limited) at the 13 September 2026 baseline, so no score was recorded	100 (single lab run, 23 September 2026)

We have no before-and-after Core Web Vitals field data to compare: no Chrome UX Report (CrUX) access was set up before cutover.

Search data: too early to judge

Google Search Console reported 47 clicks and 157 impressions for 8–14 September, and 27 clicks and 90 impressions for 15–21 September. Bing recorded no clicks in either window.

We are not drawing a conclusion from those numbers. The two weeks straddle the rebuild, there is too little comparable post-launch data for a causal claim, and brand and misspelling queries dominate the visible Google clicks. We will add a comparison to this note only when the data supports a reading.

The hard part

Building the new site was not the hard part. Deciding what should happen to hundreds of old URLs, without treating every old page as worth preserving, was. Each route needed someone to judge whether it had a real equivalent, whether an article could stand up to review, or whether it should simply be retired.

Five questions we would ask before migrating another site

1. Which pages actually attract qualified visitors or customers, and which exist only because they were once published?
2. Who controls the domain, hosting, analytics, Search Console, content, forms and third-party integrations?
3. Which old URLs have a true equivalent, and which should return 404 or 410 instead of redirecting to the homepage?
4. Can forms, mail delivery, privacy handling and rollback be tested before traffic is switched?
5. What baseline and comparison window will you use to judge search and enquiry results after launch?

Planning your own migration

If you are planning a rebuild, list the decisions before you start. The free website migration risk planner asks five questions, needs no email, and returns work and questions rather than a quote. The free website health audit checks up to five public pages. Our websites and ongoing care service includes a migration plan for existing URLs in the scope, and the process page shows how a scoped project runs from brief to handover. If you are weighing a one-time rebuild against ongoing care, read Website as a Service vs a one-time website build.

Frequently asked questions

Is this a client case study?

No. This note covers TechTenstein’s own website, techtenstein.com, which moved off WordPress in September 2026. It is labelled a first-party project note. TechTenstein does not publish client names, results or testimonials unless the work, the client’s permission and the supporting evidence can all be identified.

How many URLs did TechTenstein migrate from WordPress?

TechTenstein inventoried 540 legacy routes and gave every one an explicit decision. 21 were kept at their URLs, 111 were 301-redirected to genuine equivalents (most to five new service pages), and 408 returned 410 Gone. The release record shows all 540 route outcomes read back and 38 canonical public pages checked.

Why return 410 instead of redirecting old pages to the homepage?

A redirect should take visitors to a page that answers the same need. When no equivalent exists, a 410 states plainly that the page was retired. Google’s site-move guidance recommends 404 or 410 for content that is not moving, and warns that mass homepage redirects may be treated as soft 404s.

Did search traffic go up after the migration?

We cannot say. Search Console showed 47 clicks for 8–14 September and 27 clicks for 15–21 September. Those weeks straddle the rebuild, the post-launch data is too thin for a causal claim, and brand and misspelling queries dominate the visible clicks. We will report again once a fair comparison window exists.

This note describes TechTenstein’s own implementation and recorded checks. It does not claim a customer outcome or guarantee traffic.