Heimkoma: Bilingual Static Site Migration

Heimkoma sells fractional ownership of Icelandic homes: a Reykjavík apartment, a holiday home, or a share in three properties. Its website ran on WordPress with a page builder, and every English page was generated at request time by a translation plugin, so none of the English existed as a real page Google could index properly. Content changes meant opening the builder, and anything structural meant a developer.

Two pages had already moved off that model: a Reykjavík landing page and a press page, both published from GitHub, and both working well. The job was to bring the whole site onto the same footing without breaking the parts that already ran independently.

What I built

A full migration from WordPress to a bilingual static site, with deployment and measurement built around it:

• A bilingual static site with 82 pages live, including 41 authored English pages paired to their Icelandic originals in place of machine translation
• Push-to-publish deployment: the client edits content as files in the repository, and a commit publishes the site with automated checks
• One deployment model covering the main site, the Reykjavík page and the press page, replacing four separate arrangements
• Consent-gated embeds for 3D tours, maps and video, with a notice in the visitor’s own language when consent is declined
• Conversion tracking for enquiries, calendar bookings, phone and email clicks, each wired as a distinct event and verified firing on the live site

The interesting problems

Most of the risk in a migration isn’t building the new site. It’s the old site’s hidden behaviour that only shows up when something stops serving it.

The whole cutover turned on one line

The server had no DirectoryIndex set, so WordPress’s index.php won at every directory root, and any static index.html placed alongside it was simply never served. Adding DirectoryIndex index.html index.php switched the site over, and removing it switched it back. Because copying the new files onto the server changed nothing on its own, everything could be staged and inspected in place before going live, and rollback was a thirty-second operation rather than a restore.

Two traps that only showed up in testing

Deactivating the translation plugin didn’t remove its rewrite rules, so the English site would have stayed dead behind them. And one redirect existed only inside a WordPress plugin, in no repository file; it would have started returning errors the moment WordPress stopped serving pages. Neither was visible from reading the code. Both were found by testing, and fixed before the switch.

A privacy defect found by testing the refusal

The property pages embed 3D tours, maps and video. Checking the cookie banner with consent actively declined showed those embeds loading anyway, contacting third parties for a visitor who had said no. The fix moved each embed behind the consent layer already on the site and added a short notice in the visitor’s language, so a declining visitor sees an explanation rather than an empty rectangle. Eighteen embeds across ten pages were tested in both states before the change went near the live site.

Measurement that counts things that happened

Analytics was deliberately left switched off through launch, so data collection would begin only once events were confirmed to be arriving correctly. Wiring the events surfaced two existing problems: a conversion that counted page views of a thank-you page rather than confirmed bookings, and an automatic form-capture setting that would have recorded every enquiry twice once tracking went on. Both were reported before they could contaminate a single figure.

A deploy built so a bad day stays small

Automation that can reach everything is a liability, so the deploy was designed around what it must never be able to touch. When the client pushes a change, this runs without anyone watching:

1. Refuse a draft build. A draft carries no sitemap and a no-index flag, and publishing one would remove the site from Google, so the deploy stops instead.
2. Upload to a staging directory over SSH, using a write-only key that has no shell access and cannot read anything back.
3. Publish directory by directory, so deletions stay inside folders the site owns. WordPress, the uploaded media, the guest handbooks and the cleaning checklist are unreachable by a deploy, even after a mistaken commit.
4. Smoke-test the live site by requesting key pages and a redirect, so a failure surfaces in the deploy log rather than in someone’s browser a week later.
5. Report a green tick, or a named failure with the step that caused it.

Before the switch, a full backup of files, database and server configuration was restored in rehearsal rather than trusted on faith. The routing file the entire site depends on now lives in version control, not only on the server.

Testing

A migration is judged by what survives it. Every address the previous site published was requested against the new one and accounted for, including media files and Icelandic property pages such as /sameign-i-husafelli/ and /haldid-og-sleppt/. That meant 37 legacy addresses reconciled with none broken, 24 redirects configured (including the one found only inside WordPress), 102 retired machine-translation prefixes sent somewhere useful, and 53 post-launch checks, all passing.

WordPress stays installed and running quietly, because the cleaning-checklist form still posts to it. It no longer serves a single public page.