How we built our website with AI — case HD SofT: 13 languages, WordPress, automation and analytics

This article describes how we at HD SofT built our own website with the help of AI — moving from a Squarespace base to WordPress + Bricks Builder, across 13 languages, on our own server, with an automated publishing pipeline and analytics. And what we learned along the way.

Why we left Squarespace

Our previous site ran on Squarespace. It served us well for years, but three things eventually pushed it out:

• Multilingual support was too expensive and clunky. We are a Finnish software company, but our projects span the globe. We wanted our content readable in 13 languages — and Squarespace’s multilingual features did not bend to that without a separate plugin and a monthly bill that kept growing.
• We were locked into a single vendor’s ecosystem. We wanted to own the stack: the database, the server, the deploy process and all of the content. Only then can we experiment with new AI and integration solutions without painting ourselves into a corner.
• SEO and AI search require control. Structured data (JSON-LD), llms.txt and per-page Open Graph tags are not workable on off-the-shelf services the way we wanted them.

We decided to rebuild — and at the same time to test in practice how far today’s AI tools reach when a software company builds its own production-grade website with them.

Picking the stack: WordPress, Bricks and our own VPS

We picked WordPress as the platform, Bricks Builder as the page builder and our own VPS as the host, running on Docker and Kubernetes.

• WordPress, because it is the standard: REST API, Yoast SEO and ten years of support libraries for everything we need. In active use: Yoast SEO, Redirection (URL redirects), Converter for Media (automatic WebP conversion) and AI Engine.
• Bricks Builder handles the visual layer. A key decision: we keep all styling (typography, colours, spacing, grids) under the Bricks Theme Style — we do not hardcode pixels into individual pages. This way the machine (read: AI) can build new content and it slots into the existing look without separate polishing.
• Our own VPS gives us full control: costs are predictable, the server is in Finland, and we can build n8n automations and other projects alongside it in the same environment.

What did we leave out? Multilingual plugins. Instead we built our own solution where every language has its own page under a path prefix (for example /en/services/, /de/dienstleistungen/). The URL structure is simple, and search engines treat the pages as individuals rather than as some translation magic.

Content production with AI — a repeatable process

The foundation for all content is the FI master: the Finnish-language original, which we write and edit by hand. Only once it is locked does AI translate it into the other 12 languages.

In practice the process runs like this:

1. The FI master is written and proofread by hand. Finnish needs a human reviewer — compound words, commas and nuance often slip past AI.
2. Once the text is approved, we run the translation script, which produces a version for every required language (en, de, es, fr, pt, pl, ro, tr, hi, ko, ar, fa).
3. Each translation gets a _hdsoft_translation_key meta field that points to the FI master post ID. That tells the system which versions belong together.
4. The featured image and publish date are copied from the master automatically, so the translated versions stay visually consistent.

RTL languages (Arabic, Persian) get special attention: the HTML dir="rtl" attribute, a properly mirrored layout and a native speaker as proofreader.

AI does not add new facts, does not invent numbers and does not shift the tone. Its job is simple: translate, not rewrite.

Technical automation: REST API, mu-plugins and GitHub Actions

This is the part where AI really saves time.

Pages are built over the REST API. In Bricks the structure of a single page is stored in the _bricks_page_content_2 meta field as JSON. When we want to create a new service page, AI generates a Bricks-compatible JSON structure (Section → Container → Block → Heading + Text), POSTs it through the REST API, and the page is ready. You can still proofread directly in the editor, but the bulk of the work comes from a single command.

Mu-plugins handle the special cases. Alongside the standard building blocks we run a few custom mu-plugins:

• hdsoft-jsonld.php — generates extended SEO schemas (Service, SoftwareApplication, CreativeWork, ContactPage, FAQPage) on top of Yoast’s baseline.
• hdsoft-tracking.php — Google Analytics, Lead Feeder and Bing Webmaster tags.
• hdsoft-domain.php — forces every URL rendered on the site onto the final hdsoft.fi domain (this avoided URL leftovers around the cutover).
• hdsoft-llms.php — serves the /llms.txt file to AI search engines with the correct UTF-8 charset.

All mu-plugins are deployed automatically via GitHub Actions: when you push to main, a runner rolls the change into the K8s cluster. No manual kubectl cp is needed.

A single global JS handles multilingual navigation. A Bricks Code element in the header template reads the language code from the URL and translates the menu, the footer and the previous/next links. That means we do not create a per-language header — we update one file when we add a new service.

SEO and GEO baked into the structure

AI search (ChatGPT, Perplexity, Claude, Bing Copilot) is a different game from Google. These engines do not index and rank links — they read a page as a summary and answer the question directly. That requires two things:

1. Structured data in JSON-LD form. Yoast handles the basics (WebPage, Article, BlogPosting, BreadcrumbList, Organization). Our own hdsoft-jsonld.php adds the important specifics: Service for service pages, SoftwareApplication for products, FAQPage automatically when the content has question/answer patterns.
2. llms.txt at the root of the site. It is a short summary of what the company is, what it does and where to find more. We keep it current every time we add a new service, product or project.

The combination works: AI search engines can answer “what does HD SofT do” type questions correctly, without guessing or confusing us with another company.

Every page also includes:

• an inLanguage field in the JSON-LD, generated from the URL prefix
• an og:locale tag for the translation version (fi_FI, en_US, de_DE …)
• hreflang links once all the translations are ready
• answer-oriented paragraphs — short, in a question-and-answer shape, so AI gets a clean one-sentence response out of it

Analytics wired up from day one

You cannot improve a website without data. We connected the following straight away:

• Google Analytics 4 — baseline traffic, channels, pages, behaviour.
• Google Search Console — organic visibility, top queries, indexing issues.
• Lead Feeder — company-level identification when someone visits the site repeatedly from a recognisable IP range.
• Bing Webmaster Tools — Bing still matters, particularly in the enterprise market, and Microsoft’s Copilot reads Bing.

One thing in particular: a weekly marketing snapshot. We wrote a command-line script that pulls GA4 data and Search Console data, compares the latest week to the previous one and prints a Markdown summary: channels, countries, top pages, top queries, deltas. It is not a fancy dashboard but a practical report — and it makes sure we never miss a trend.

The AI-assisted development pipeline gave us a particular edge here: when a GA4 or Search Console request needs to be shaped correctly, AI handles it in a few lines of code and then interprets the result back into a readable form for us.

DNS cutover and aftercare

We switched the production domain over to hdsoft.fi on May 4, 2026. We prepared for the cutover like this:

• We built 28 redirects from the old Squarespace URLs to the new ones — all relative, so they survive the domain change.
• 404 errors were wired into GA4 as a dedicated event, so we spot broken links quickly.
• The sitemap was submitted to Search Console only after the DNS switch, not before (otherwise Google would have flagged it as faulty).

After the cutover we run the marketing snapshot weekly for the first four weeks, then once a month. This way we quickly catch any URL that ended up on a 404, or any page that is performing unexpectedly well (and then we add more content).

What we learned

The most important insights are not about the technology but about the way of working.

• Design the styles in one place before AI starts producing content. Bricks Theme Style and Global Classes are tools for the AI: when the structure is in place, the machine just fills in the gaps. If you leave the styling open, AI hardcodes pixels into every page and the mess starts.
• Lock the FI master before translating. If the master keeps moving, the translations drift apart across generations. One source of truth — and the others follow it.
• Make visual review mandatory. AI can produce a page that is flawless at the JSON level but looks like a mess to the user. Run a Playwright screenshot after every change — let a human read it, not just a validator.
• Finnish needs a human. Compound words, commas and tone: AI makes mistakes that a machine cannot catch. Keep a native speaker as the final gate.
• Collect the context into one file. We have CLAUDE.md at the root of the repo: every rule, every tool, every path, every deploy mechanism. When you open an AI session, it reads that file first. A human does the same before starting to edit: read the instructions and you do not start from scratch.

In the end the best AI tool is the one whose user knows how to stop it. Generation is cheap — quality assurance is the part that makes the difference.

Want the same, turnkey?

HD SofT delivers AI-powered web and content projects for clients. Same method, same quality bar, same level of control: WordPress + Bricks, automation pipeline, multilingual setup and analytics — all wired up before the site is even launched.

Ask for more: contact form, Digital Marketing or Software Development.