lunavera.hu — a full custom site replacing a template WordPress
What was on the old site?
The client had lived for years with a WordPress site running on a purchased template. When we saved its full content and went through it line by line, this is what came out:
- two subpages — the crystal bed and the treatments — were byte-for-byte copies of the home page,
- all three course levels contained the same text, belonging to a fourth service,
- exactly one subpage carried real, original copy,
- the privacy notice still had
COMPANY NAME,ADDRESSandTAX NUMBERplaceholders in it.
This is not an opinion and not a sales argument: it came out of a full backup of the old site, at file level. The visitor only sensed that "somehow it does not add up" — but this was exactly the picture the search engine had of the site: pages copying each other, with nothing of their own to say.
What was built instead?
25 custom pages, no plugins
Every page was built with its own design and its own code, server-side rendered: what the visitor sees, search engines and language models get the same way, without executing anything. No page builder, no plugin chain updating itself underneath the owner.
Booking with its own endpoint
Behind the booking and download forms runs custom server code, not a form plugin. In front of it, human verification: without a token, and with a forged token, the submission is rejected with a 403 before any data is created. Incoming requests are logged without passwords and without cookies.
A moon calendar that calculates — and would rather be empty than false
The group sessions section works from real astronomical calculation: the moon phase is a computed value, not a hand-entered icon. The most important decision of the project, however, was not that but this: the section went live empty. During the build it held sample dates with a live countdown. They looked good — but someone could have set out for a session that did not exist. Invented data does not go out on a live site: the section got an empty state with one true sentence and a notify-me button, until the real dates arrived.
A crystal bed you can walk through with a keyboard
For the hardest-to-explain part of the service, a custom interactive element was built: seven crystals, each with its own cone of light, navigable by click and by keyboard alike. Accessibility was not a fix applied afterwards but a condition of writing the component.
One cookie, zero analytics scripts
The site runs a single cookie: the one remembering the visitor's own consent decision, for 12 months. There is no analytics service, no advertising pixel, and no embedded third-party video player either — the videos and the audio come from our own server. This is not a matter of settings: there is no code in the system that would send data to a third party.
The security headers — Content-Security-Policy, frame denial, HSTS — live in the application code, not only in the server configuration. That way a domain change cannot lose them.
Structured data: one person, one entity
In the initial state the same person appeared in the structured data under two different identifiers, with two half biographies — to a machine, two different people. For a one-person service that is the worst possible outcome, because that is where expertise attaches to the person. After the fix, the person, the business, the address and the breadcrumbs are built from a single source on every page; articles got Article, service lists got ItemList, the voucher got Product and Offer markup.
A machine-readable version — from the same source
The site is built on visuals: animations starting on scroll, claims embedded in images. Good for humans, hard for machines. So every page has a factual, machine-readable version (.md mirror), plus an llms.txt and an llms-full.txt — generated from the same data the interface is built from. There is no separately maintained copy, so they cannot diverge: if a price changes, it changes in both places.
How did the move go?
When replacing a live site, the risk is not the design but the addresses and the email. So the order was fixed:
- A fresh, complete backup of the old WordPress — database and files, integrity checked — before anything happens.
- Lifting the search engine block and switching DNS in the same hour. If the domain comes across before the site becomes indexable, the search engine drops the old addresses from the index — and the ranking that was built up is lost.
- Permanent redirects for 11 old addresses to their new equivalents. The list came from the old site's database, not from guesswork: every published page got a target.
- Email was left untouched. Only the web address records changed; the mailboxes and the sending authentication (SPF, DKIM, DMARC) did not change by a single character, and after the switch it was verified that mail goes through.
- Closing the preview address with a redirect, so two competing sites with identical content do not remain.
- Notifying the search engines the same day: sitemap submitted, immediate notification to the others.
The result
| What | How much | Source |
|---|---|---|
| Custom pages in the sitemap | 25 | lunavera.hu/sitemap.xml |
| Tracking and advertising cookies | 0 | the cookie notice + your browser's own interface |
| Analytics or advertising scripts | 0 | the page source |
| Old addresses redirected | 11 | the old WordPress database |
| Response time (TTFB) | 0.05–0.09 s | measured daily from my own server over the public address — today's exact value is in the measurement box on the home page |
| Templates and plugins in the system | 0 | the source code |
The speed figure is a lab measurement: from one machine, on one network. What you measure on your device may differ — which is why you can measure it yourself through the links below.
Check it yourself
- lunavera.hu — the live site.
- lunavera.hu/sitemap.xml — the number of pages and the update dates.
- lunavera.hu/llms.txt — the machine-readable summary.
- PageSpeed Insights — speed measured with Google's own instrument.
- Rich Results Test — the structured data on any page.
- Open
lunavera.hu/reiki-oktatas: one of the old site's addresses. It does not lead to an error page but to its new equivalent — one of the 11 redirects.
What can be learned from it?
That in a site replacement, what can be lost is not the design but the addresses, the email and the position built up in search. Three people usually get this wrong: whoever does not redirect the old addresses, whoever moves the email along with the web address, and whoever pulls the domain across before the new site is indexable. All three mistakes are reversible, but they cost weeks and traffic.
The other lesson belongs to the moon calendar: an empty section with one true sentence is worth more than a full one with invented data. A visitor forgives the first. The second they experience once — when they turn up for a session that does not exist.
If the situation sounds familiar — an existing template site that is now more of an obstacle: custom website development, or first look at whether it is worth fixing or rewriting.