Näin rakensimme verkkosivumme AI:lla — case HD SofT: 13 kieltä, WordPress, automaatio ja analytiikka

Tämä artikkeli kertoo, miten me HD SofT:lla rakensimme oman verkkosivumme tekoälyä hyödyntäen — Squarespace-pohjasta WordPress + Bricks Builderin päälle, 13 kielelle, omalle palvelimelle, automatisoidulla julkaisuputkella ja analytiikalla. Ja mitä matkasta opimme.

Miksi vaihdoimme Squarespacesta

Vanha sivumme oli Squarespacen päällä. Se palveli pitkään, mutta kolme asiaa vei sen tielle:

• Monikielisyys oli liian kallista ja kömpelöä. Olemme suomalainen ohjelmistotalo, mutta projekteja tehdään ympäri maailmaa. Halusimme sisältömme luettavaksi 13 kielellä — Squarespacen monikielitoiminnot eivät tähän taipuneet ilman erillistä lisäosaa ja kuukausittain kasvavaa hintaa.
• Olimme lukittuja yhden palveluntarjoajan ekosysteemiin. Halusimme omistaa pinon: tietokannan, palvelimen, deploy-prosessin ja koko sisällön. Vain niin pystymme kokeilemaan uusia AI- ja integraatioratkaisuja kavennamatta itseämme.
• SEO ja AI-haut vaativat kontrollia. Strukturoitu data (JSON-LD), llms.txt ja yksittäisten sivujen Open Graph -tagit eivät onnistu vakiopalvelujen varassa siten kuin halusimme.

Päätimme rakentaa uudelleen — ja samalla testata käytännössä, miten pitkälle nykyajan AI-työkalut yltävät, kun ohjelmistotalo tekee oman tuotantotason verkkosivunsa niillä.

Stackin valinta: WordPress, Bricks ja oma VPS

Valitsimme alustaksi WordPressin, sivurakentajaksi Bricks Builderin ja palvelimeksi oman VPS:n Docker- ja Kubernetes-pohjaisella ympäristöllä.

• WordPress, koska se on standardi: REST API, Yoast SEO ja kymmenen vuoden tukikirjasto kaikkeen, mitä tarvitsemme. Käytössä Yoast SEO, Redirection (URL-uudelleenohjaukset), Converter for Media (automaattinen WebP-muunnos) ja AI Engine.
• Bricks Builder hoitaa visuaalisen tason. Tärkeä päätös: jätimme kaiken tyylin (typografia, värit, etäisyydet, gridit) Bricksin Theme Stylen alle — emme kovakoodaa pikseleitä yksittäisille sivuille. Näin kone (lue: AI) voi rakentaa uutta sisältöä ja se istuu valmiiseen ulkoasuun ilman erillistä viilausta.
• Oma VPS antaa täyden kontrollin: kustannukset ovat ennakoitavia, palvelin on Suomessa, ja voimme rakentaa oheen n8n-automaatioita ja muita projekteja samaan ympäristöön.

Mitä jätimme pois? Monikielisyysplugineja. Niiden sijaan rakensimme oman ratkaisun, jossa jokaiselle kielelle on oma sivunsa polun alla (esimerkiksi /en/services/, /de/dienstleistungen/). URL-rakenne on yksinkertainen, ja hakukoneet käsittelevät sivut omina yksilöinään, ei käännösmagiana.

Sisällön tuotanto AI:lla — toistettava prosessi

Kaiken sisällön perustana on FI-master: suomenkielinen alkuperäinen versio, jonka me kirjoitamme ja editoimme käsin. Vasta kun se on lukittu, AI kääntää sen muille 12 kielelle.

Käytännössä prosessi etenee näin:

1. FI-master kirjoitetaan ja oikoluetaan käsin. Suomi tarvitsee ihmistarkastajan — yhdyssanat, pilkutus ja vivahteet jäävät usein AI:lta vajaaksi.
2. Kun teksti on hyväksytty, ajamme käännösskriptin, joka tuottaa version kaikille tarvittaville kielille (en, de, es, fr, pt, pl, ro, tr, hi, ko, ar, fa).
3. Jokainen käännös saa _hdsoft_translation_key-metakentän, joka osoittaa FI-master-postauksen ID:hen. Näin järjestelmä tietää, mitkä versiot kuuluvat yhteen.
4. Featured-kuva ja julkaisupäivä kopioituvat masterilta automaattisesti, joten käännösversiot ovat visuaalisesti yhtenäisiä.

RTL-kielet (arabia, persia) saavat erityishuomion: HTML:n dir="rtl"-attribuutti, oikeansuuntainen layout ja oikolukijaksi natiivipuhuja.

AI ei lisää uusia tietoja, ei keksi numeroita eikä muuta sävyä. Sen tehtävä on yksinkertainen: kääntää, ei kirjoittaa uudelleen.

Tekninen automaatio: REST API, mu-pluginit ja GitHub Actions

Tämä on osa, jossa AI todella säästää aikaa.

Sivut rakennetaan REST API:n yli. Bricksissä yksittäisen sivun rakenne tallentuu _bricks_page_content_2-metakenttään JSON-muodossa. Kun haluamme luoda uuden palvelusivun, AI muodostaa Bricks-yhteensopivan JSON-rakenteen (Section → Container → Block → Heading + Text), POSTtaa sen REST API:lla, ja sivu on valmis. Oikolukea voi suoraan editorissa, mutta perustyö tulee yhdestä komennosta.

Mu-pluginit hoitavat erikoistehtävät. Vakiopalikoiden lisäksi käytössä on muutamia omia mu-plugineja:

• hdsoft-jsonld.php — generoi laajennetut SEO-skeemat (Service, SoftwareApplication, CreativeWork, ContactPage, FAQPage) Yoastin perustason päälle.
• hdsoft-tracking.php — Google Analyticsin, Lead Feederin ja Bing Webmasterin tagit.
• hdsoft-domain.php — pakottaa kaikki sivuilla näkyvät URL:t lopulliselle hdsoft.fi-domainille (vältti URL-jäänteet cutoverin yhteydessä).
• hdsoft-llms.php — servaa /llms.txt-tiedoston AI-hakukoneille oikealla UTF-8-charsetilla.

Kaikki mu-pluginit deployataan automaattisesti GitHub Actionsin kautta: kun pushaa main-haaraan, runner ajaa muutoksen K8s-clusteriin. Manuaalista kubectl cp-komentoa ei tarvita.

Yksi globaali JS hoitaa monikielisen navigaation. Bricks Code -elementti header-templatessa lukee URL:n kielikoodin, kääntää valikon, footerin ja edellinen/seuraava-linkit. Tämä tarkoittaa, että emme luo per-kieli-headeria vaan päivitämme yhden tiedoston, kun lisäämme uuden palvelun.

SEO ja GEO heti rakenteeseen

Tekoälyhaut (ChatGPT, Perplexity, Claude, Bing Copilot) ovat eri laji kuin Google. Ne eivät indeksoi ja sijoittele linkkejä — ne lukevat sivua yhteenvetona ja vastaavat suoraan kysymykseen. Tämä vaatii kahta asiaa:

1. Strukturoitua dataa JSON-LD-muodossa. Yoast hoitaa peruskaiken (WebPage, Article, BlogPosting, BreadcrumbList, Organization). Oma hdsoft-jsonld.php lisää tärkeät erityistyypit: Service palvelusivuille, SoftwareApplication tuotteille, FAQPage automaattisesti, kun sisällössä on kysymys/vastaus-kuvioita.
2. llms.txt sivuston juuressa. Se on lyhyt yhteenveto siitä, mikä yritys on, mitä se tekee ja mistä saa lisätietoa. Pidämme sen ajan tasalla joka kerta, kun lisäämme uuden palvelun, tuotteen tai projektin.

Yhdistelmä toimii: tekoälyhaut osaavat vastata “mitä HD SofT tekee” -tyyppisiin kysymyksiin oikein, ilman että ne arvaavat tai sekoittavat meidät toiseen yritykseen.

Lisäksi jokaisella sivulla on:

• inLanguage-kenttä JSON-LD:ssä, generoituu URL-prefixistä
• og:locale-tagi käännösversioille (fi_FI, en_US, de_DE …)
• hreflang-linkit, kun kaikki käännökset ovat valmiita
• vastauskeskeiset kappaleet — lyhyet, kysymys ja vastaus -muotoon, jolloin AI saa siitä yhden lauseen vastauksen

Analytiikka kiinni samaan kertaan

Verkkosivua ei voi parantaa ilman dataa. Kytkimme heti käyttöön:

• Google Analytics 4 — perusliikenne, kanavat, sivut, käyttäytyminen.
• Google Search Console — orgaaninen näkyvyys, top-haut, indeksointiongelmat.
• Lead Feeder — yritystason tunnistus, kun joku katsoo sivuja toistuvasti tunnistettavalta IP-alueelta.
• Bing Webmaster Tools — Bing on yhä erityisesti yritysmarkkinoilla relevantti, ja Microsoftin Copilot lukee Bingiä.

Erityisesti yksi asia: viikoittainen markkinointisnapshot. Kirjoitimme komentorivipohjaisen skriptin, joka hakee GA4-datan ja Search Console -datan, vertaa edelliseen viikkoon ja tulostaa Markdown-yhteenvedon: kanavat, maat, top-sivut, top-haut, deltat. Tämä ei ole hieno dashboard vaan käytännönraportointia, mutta se varmistaa, ettemme jätä trendiä huomaamatta.

AI-avusteinen kehitysputki tarjosi tähän erityisen edun: kun GA4:n tai Search Consolen datapyyntö pitää muotoilla oikeaan rakenteeseen, AI hoitaa sen muutamalla rivillä koodia ja tulkitsee tuloksen takaisin meille luettavaan muotoon.

DNS-cutover ja jälkihoito

Vaihdoimme tuotanto-domainin hdsoft.fi:hen 4.5.2026. Cutoveriin valmistauduimme näin:

• Rakensimme 28 redirectia vanhoista Squarespace-URL:ista uusiin — kaikki relatiivisina, jolloin ne kestävät domainin vaihdon.
• 404-virheet kytkettiin GA4:ään omana eventinä, jotta huomaamme rikkinäiset linkit nopeasti.
• Sivukartta toimitettiin Search Consoleen vasta DNS-vaihdoksen jälkeen, ei aikaisemmin (muuten Google merkitsisi sen virheelliseksi).

Cutoverin jälkeen ajamme markkinointisnapshotin viikoittain ensimmäiset neljä viikkoa, sen jälkeen kerran kuussa. Näin huomaamme nopeasti, jos jokin URL on jäänyt 404:lle tai jokin sivu vetää yllättävän hyvin (silloin lisää sisältöä).

Mitä opimme

Tärkeimmät oivallukset eivät ole tekniikkaa vaan työtapaa.

• Suunnittele tyylit yhteen paikkaan ennen kuin AI alkaa tuottaa sisältöä. Bricks Theme Style ja Global Classes ovat AI:n työkaluja: kun rakenne on valmiina, kone vain täyttää aukot. Jos jätät tyylit auki, AI kovakoodaa pikseleitä joka sivulle ja sotku alkaa.
• Lukitse FI-master ennen käännöksiä. Jos master vielä elää, käännökset ehtivät rappeutua eri sukupolvien mukaan. Yksi totuuden lähde — ja muut seuraavat siitä.
• Visuaalinen tarkistus pakolliseksi. Tekoäly pystyy tuottamaan sivun, joka on JSON-tasolla virheetön mutta käyttäjälle näyttää sotkulta. Aja Playwright-pohjainen ruudunkaappaus jokaisen muutoksen jälkeen — ihminen lukee, ei vain validaattori.
• Suomi tarvitsee ihmisen. Yhdyssanat, pilkutus ja sävy: AI tekee virheitä, joita kone ei huomaa. Pidä natiivipuhuja viimeisenä portaana.
• Kerää konteksti yhteen tiedostoon. Meillä on CLAUDE.md repon juuressa: kaikki säännöt, työkalut, polut, deploy-mekanismit. Kun avaa AI-istunnon, se lukee tiedoston ensin. Ihminen tekee saman ennen kuin alkaa muokata: lue ohjeet, niin et aloita uudestaan.

Lopulta paras AI-työkalu on se, jonka käyttäjä osaa pysäyttää. Generointi on halpaa — laadunvarmistus on se osa, joka ratkaisee.

Haluatko saman avaimet käteen?

HD SofT toteuttaa AI-pohjaisia verkkopalvelu- ja sisältöprojekteja asiakkaille. Sama metodi, sama laatutaso, sama kontrolli: WordPress + Bricks, automaation putki, monikielisyys ja analytiikka — kaikki kytkettyinä kuntoon ennen kuin sivu on edes julkaistu.

Kysy lisää: yhteydenottolomake, Digimarkkinointi tai Ohjelmistokehitys.