URL näyttää viattomalta. Se on vain merkkijono selaimen osoiterivillä. Mutta WordPressille URL ei ole tekstiä – se on semanttinen arvoitus. Jokainen pyyntö on kysymys:
“Mitä tämä osoite tarkoittaa?”
Kun käyttäjä avaa sivun, WordPress ei hae tiedostoa levyltä kuten staattinen HTML-sivusto. WordPress tulkitsee URL:n, purkaa sen rakenteen, vertaa sitä sääntöihin ja lopulta muuntaa sen tietokantakyselyksi.
URL ei ole polku.
Se on intentio.
Staattinen web vs WordPress
Staattisessa webissä URL ja tiedosto ovat usein sama asia:
/about.html → about.html
WordPressissä tämä yhteys katkeaa täysin. URL:
/2026/02/mielenkiintoinen-artikkeli/
ei viittaa tiedostoon nimeltä “mielenkiintoinen-artikkeli.php”. Se viittaa abstraktiin sisältöobjektiin tietokannassa.
WordPress toimii kuin tulkki, ei tiedostopalvelin.
Ensimmäinen vaihe: HTTP-pyyntö saapuu
Kun selain tekee pyynnön, web-palvelin (Apache, Nginx) vastaanottaa sen. Tässä kohtaa tapahtuu ensimmäinen tärkeä taika – tai oikeammin sääntöpohjainen logiikka.
Rewrite rules.
Web-palvelin ohjaa lähes kaikki pyynnöt tiedostoon:
index.php
Tämä on kriittinen oivallus. WordPress ei saa tietoa URL:sta “normaalina tiedostopolkuna”. Kaikki kulkee bootstrapin läpi.
URL ei ratkaise itseään.
Se ratkaistaan.
Rewrite rules: WordPressin URL-kielioppi
Rewrite rules ovat WordPressin kielioppisäännöt. Ne kertovat:
“Jos URL näyttää tältä → tulkitse se näin.”
WordPress rakentaa nämä säännöt WP_Rewrite-luokan avulla. Ne tallennetaan tietokantaan ja kirjoitetaan usein myös .htaccess-tiedostoon.
Rewrite rule ei ole pelkkä uudelleenohjaus.
Se on pattern matching -järjestelmä.
Esimerkki ajattelumallista
URL:/category/teknologia/
Rewrite rule:
“category + slug → taxonomy query”
WordPress ei näe sanaa “category”. Se näkee rakenteen.
WP_Rewrite: URL-arkkitehtuurin insinööri
WP_Rewrite on yksi WordPressin vähemmän tunnetuista mutta keskeisimmistä komponenteista. Se:
-
määrittelee permalink-rakenteet
-
generoi rewrite-säännöt
-
yhdistää URL:t query-variaabeleihin
Permalink-rakenne on kuin URL-syntaksi:
-
/postname/ -
/year/month/postname/ -
/category/postname/
WP_Rewrite ei ole vain konfiguraatio.
Se on URL-järjestelmän moottori.
parse_request(): missä URL alkaa muuttua dataksi
Kun WordPress runtime käynnistyy, se siirtyy vaiheeseen, jossa URL puretaan.
parse_request()
Tässä kohtaa WordPress:
-
lukee REQUEST_URI:n
-
vertaa sitä rewrite-sääntöihin
-
tunnistaa query-variaabelit
URL ei ole enää merkkijono. Se alkaa hajota semanttisiksi komponenteiksi.
Query vars: URL:n käännösdata
Rewrite rule voi tuottaa:
-
post_type
-
name (slug)
-
category_name
-
author
-
paged
-
custom query vars
Query vars ovat URL:n sisäinen representaatio.
Ne ovat kuin URL:n “merkitys”.
URL ei hae sisältöä – query vars hakevat
Tämä on yksi WordPressin syvimmistä arkkitehtuurisista oivalluksista.
URL ei hae postauksia.
WP_Query tekee sen.
URL → rewrite → query vars → WP_Query
WP_Query ei välitä URL:sta. Se välittää query-variaabeleista.
WordPress erottaa intentiotason (URL) ja datatason (SQL).
WP_Query: URL:n lopullinen tulkki
Kun query vars on rakennettu, WordPress luo pääkyselyn:
WP_Query
WP_Query muuntaa query-variaabelit SQL-kyselyksi:
-
WHERE-ehdot
-
JOIN-operaatiot
-
ORDER BY
-
LIMIT
URL muuttuu tietokantakyselyksi.
Ja SQL on aina rehellinen. Se kertoo, kuinka paljon työtä järjestelmä tekee.
Pretty permalinks vs plain URLs
WordPress tukee kahta perusmallia.
Plain URL
/?p=123
Ei rewrite-sääntöjä. Ei semanttista rakennetta. Suora query-variaabeli.
Teknisesti yksinkertainen. Esteettisesti… vähemmän inspiroiva.
Pretty permalink
/mielenkiintoinen-artikkeli/
Vaatii rewrite-säännöt. Vaatii pattern matchingin. Vaatii URL-tulkinnan.
Pretty permalinks eivät ole vain kosmetiikkaa.
Ne ovat URL-abstraktiokerros.
Taxonomiat ja URL-logiikka
Kun URL sisältää taxonomian:
/tag/php/
WordPress ei hae “php-tag.html”-tiedostoa. Se:
-
tunnistaa taxonomy slug -patternin
-
rakentaa tax_queryn
-
suorittaa relaatiokyselyn
URL on vain hakukriteeri.
Tietokanta on todellinen totuus.
Hierarkkiset URL:t
WordPress tukee hierarkioita:
/parent-page/child-page/
Tämä ei ole tiedostopolku. Se on sisällön relaatiomalli.
WordPress:
-
purkaa polun segmentteihin
-
tarkistaa parent-child-suhteet
-
validoi slugien ketjun
URL toimii kuin relaatiopuu.
Canonical redirects: URL:n siivousmekanismi
WordPress sisältää canonical redirect -logiikan. Se varmistaa, että URL:
-
on oikeassa muodossa
-
ei sisällä duplikaatteja
-
ei sisällä virheellisiä rakenteita
Esimerkiksi:
-
trailing slash -normalisointi
-
väärät slugit
-
pagination-korjaukset
Canonical redirect ei ole UX-ominaisuus.
Se on URL-konsistenssimekanismi.
Miksi URL-konsistenssi on tärkeää?
Koska web ei ole vain käyttäjille.
Se on myös:
-
hakukoneille
-
välimuisteille
-
CDN:ille
-
analytiikalle
Kaksi URL:ää samaan sisältöön = SEO-ongelma + caching-ongelma.
WordPress yrittää pitää universumin siistinä.
Query stringit: URL:n lisäulottuvuus
WordPress ei elä vain pretty permalinkien maailmassa.
Query stringit:
/tuotteet/?sort=price
toimivat rinnalla.
WordPress:
-
säilyttää query-parametrit
-
yhdistää ne query-variaabeleihin
-
antaa lisäosille mahdollisuuden vaikuttaa
URL ei ole vain polku.
Se on parametrit + rakenne + konteksti.
REST API ja URL:t
REST API tuo oman URL-kerroksensa:
/wp-json/wp/v2/posts
Tämä ei kulje normaalin template-hierarkian kautta. Se:
-
käyttää rewrite-sääntöjä
-
ohjautuu REST-routeriin
-
palauttaa JSON:n
WordPress käyttää samaa URL-mekaniikkaa useisiin tarkoituksiin.
Sisältö. API. Ajax. Kaikki kulkee URL-tulkinnan kautta.
Edge caset: missä URL-logiikka muuttuu mielenkiintoiseksi
WordPress-URL:t ovat harvoin ongelma yksinkertaisissa tapauksissa.
Ongelmat syntyvät:
-
custom post type + custom taxonomy
-
nested rewrite rules
-
conflicting slugs
-
multilingual setups
-
pagination edge caset
URL-järjestelmä ei ole lineaarinen.
Se on sääntöverkosto.
Slug-konfliktit: klassinen arkkitehtuurinen kitka
Jos slug:
/about/
on sekä:
-
sivu
-
custom post type
-
taxonomy term
WordPress joutuu priorisoimaan.
Rewrite rules toimivat järjestyksessä.
Ensimmäinen match voittaa.
Tämä ei ole bugi.
Se on pattern matching -fysiikkaa.
Suorituskyky: rewrite rules eivät ole ilmaisia
Rewrite rules voivat kasvaa massiivisiksi:
-
paljon custom post typeja
-
paljon taxonomioita
-
paljon rakenteita
WordPress joutuu vertaamaan URL:ää sääntöihin jokaisella pyynnöllä.
Opcode cache auttaa PHP:ssä.
Mutta rewrite complexity on todellinen kustannus.
URL ei ole vain navigaatio – se on data-API
Modernissa WordPress-ajattelussa URL ei ole pelkkä navigaatiopolku.
Se on:
-
query language
-
state representation
-
application interface
URL kertoo järjestelmälle:
“Mitä maailmaa haluamme nähdä juuri nyt?”
Archive. Single. Search. Filtered view.
Kaikki alkaa URL:sta.
Filosofinen ydin
Staattisessa webissä URL on osoite.
WordPressissä URL on kysymys.
WordPress ei hae tiedostoa. Se tulkitsee intentiota.
Rewrite rules ovat kielioppi.
Query vars ovat merkitys.
WP_Query on logiikka.
Template hierarchy on esitystapa.
URL ei ole tekninen detalji.
Se on koko WordPressin käyttöliittymä infrastruktuurin tasolla.
Lopuksi: URL on WordPressin hermosto
Kun URL muuttuu:
-
query muuttuu
-
näkymä muuttuu
-
logiikka muuttuu
-
SQL muuttuu
WordPress ei ole tiedostojärjestelmä.
Se on URL-ohjattu runtime-järjestelmä.
Ja kun tämän sisäistää, debuggaus, suorituskyky ja arkkitehtuuripäätökset alkavat näyttää huomattavasti vähemmän mystisiltä.
