Hvordan AI-genererte .htaccess-regler kan ødelegge WordPress

AI-verktøy kan generere WordPress-kode raskt, også .htaccess-regler. Farten er nyttig, men .htaccess er et av de mest risikable stedene å lime inn AI-generert kode uten gjennomgang. En enkelt rewrite-regel endrer hvordan forespørsler når WordPress, og den kan berøre forsiden, innloggingssiden, admin-AJAX, REST API, WooCommerce-kassen, skjemaer, omdirigeringer og statiske filer.

Den virkelige faren er at nettstedet fortsatt ser ut til å virke. Forsiden laster og menyen åpner seg, mens kassen, søket, et skjema eller en betaling svikter i det stille, fordi forespørselen fanges opp før WordPress i det hele tatt ser den.

Denne artikkelen forklarer hvorfor AI-genererte .htaccess-regler ødelegger WordPress, hvilke feil du bør unngå, og hvordan du går gjennom en regel før den går live. Vil du ha det store bildet, se innlegget vårt om vanlige feil med AI-generert kode i WordPress.

Hva er .htaccess i WordPress?

.htaccess er konfigurasjonsfilen Apache leser per mappe. Reglene gjelder mappen filen ligger i og alle mapper under, og Apache leser den på nytt ved hver forespørsel. LiteSpeed, som noen webhoteller bruker i stedet for Apache, er laget for å forstå Apache-konfigurasjon og følger den samme rewrite-syntaksen. Nginx har ingen .htaccess i det hele tatt. WordPress bruker filen til pene permalenker, med denne blokken:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Forespørsler etter filer og mapper som finnes, serveres som de er (sjekkene !-f og !-d). Alt annet går til index.php, og WordPress bestemmer hva som skal vises. Bindestreken i linjen for index.php betyr «ingen erstatning»: forespørsler etter den filen slipper rett gjennom og hopper over filsjekkene.

To ting følger av dette. Når WordPress skriver reglene sine, og det gjør det når du lagrer Innstillinger > Permalenker, erstatter det alt mellom # BEGIN WordPress og # END WordPress og lar resten av filen være. Egne regler skal derfor ligge over eller under blokken, aldri inni den. Og alt som ligger over blokken, kjører først, før WordPress får si noe. Det er der problemene starter.

Hvorfor AI-generert .htaccess-kode er risikabelt

AI kan lage en regel som ser teknisk gyldig ut:

RewriteRule ^$ /home.html [L]

Den leses som «send forsideforespørsler til home.html». Men WordPress håndterer også dynamiske forespørsler på forsideadressen med en query-streng. Den klassiske WooCommerce-kassen oppdaterer for eksempel ordretotalene med:

/?wc-ajax=update_order_review

En regel ment for forsiden fanger opp den forespørselen også, og WooCommerce får en statisk HTML-side i stedet for JSON-en den ventet på. Kunden ser en kasse som laster i det uendelige, et ordresammendrag som aldri oppdateres, betalingsmetoder som mangler, eller en bestillingsknapp som ikke gjør noe.

Dette er ikke hypotetisk. I en WooCommerce-sak vi sporet var det nettopp dette mønsteret som fikk kassen til å laste i det uendelige, mens resten av nettstedet så helt friskt ut. Regelen ser liten ut. Konsekvensen kan være stor.

Feil 1: Å bruke statiske HTML-rewrites i et dynamisk WordPress-nettsted

Et typisk AI-forslag til en raskere forside er en statisk fil og en regel som denne:

RewriteCond %{REQUEST_URI} ^/$
RewriteRule ^$ /home.html [L]

Betingelsen tilfører ingenting: REQUEST_URI er stien uten query-strengen, så /?wc-ajax=update_order_review slipper gjennom som et hvilket som helst forsidebesøk. Resultatet er en blandet arkitektur, der forsiden serveres som statisk HTML og alt annet av WordPress, mens plugins, skjemaer og WooCommerce forventer vanlig ruting. Den blandingen er skjør.

La WordPress servere forsiden: en side valgt under Innstillinger > Lesing eller en front-page.php-mal, med sidecache for fart. Guiden vår om å konvertere statisk HTML til et WordPress-tema viser hvordan du beholder et AI-generert design uten rewriten.

Feil 2: Å glemme at query-strenger betyr noe

Mønsteret i en RewriteRule sammenlignes bare med stien, aldri med query-strengen, og i .htaccess fjernes den innledende skråstreken først. For ^$ er derfor alle disse roten av nettstedet:

/?wc-ajax=update_order_review
/?rest_route=/wp/v2/posts
/?s=sokeord
/?add-to-cart=123

Det er kasseforespørslene til WooCommerce, REST API på nettsteder uten pene permalenker, søkeskjemaet i WordPress og «legg i handlekurv»-lenkene til WooCommerce. Apache sender til og med den opprinnelige query-strengen videre til det nye målet som standard, og en statisk fil overser den bare.

Må du absolutt beholde en statisk forside, begrens regelen til vanlige sidevisninger: GET- eller HEAD-forespørsler uten query-streng, fra besøkende som ikke er innlogget og ikke har noe i handlekurven.

RewriteCond %{REQUEST_METHOD} ^(GET|HEAD)$
RewriteCond %{QUERY_STRING} ^$
RewriteCond %{HTTP_COOKIE} !(wordpress_logged_in_|woocommerce_items_in_cart) [NC]
RewriteRule ^$ /home.html [L]

Betingelsene kombineres med OG, så regelen slår bare til når alle tre stemmer. Likevel er det beste svaret som regel ingen rewrite i det hele tatt: en temamal lar WordPress styre rutingen, og en sidecache satt opp slik WooCommerce sin cacheguide beskriver, tar seg av unntakene for deg.

Feil 3: Å plassere egne regler før WordPress uten å kjenne konsekvensene

Regler øverst i filen ser forespørselen før WordPress gjør det:

RewriteEngine On
RewriteRule ^$ /home.html [L]

# BEGIN WordPress
...
# END WordPress

[L] forklares ofte som «siste regel», og det er bare halvt sant i .htaccess. Flagget avslutter den gjeldende runden, men Apache kjører deretter den omskrevne forespørselen gjennom filen på nytt. En regel der resultatet matcher sitt eget mønster, kan derfor gå i løkke til Apache gir opp etter ti interne omdirigeringer (LimitInternalRecursion). [END] stopper omskrivingen helt. På LiteSpeed oppfører [L] seg allerede som [END] hos Apache, og det er én grunn til at samme regel kan oppføre seg ulikt hos to webhoteller.

Vaner fra hovedkonfigurasjonen svikter også i det stille. Apache sin dokumentasjon sier at et mønster som starter med ^/, aldri matcher i en mappekontekst, så RewriteRule ^/gammel-side$ /ny-side/ [R=301,L] gjør ingenting i .htaccess. Før du legger noe over WordPress-blokken, spør om det kan påvirke AJAX, REST API, kassen, innloggings- og kontosider, query-strenger, flerspråklige adresser eller caching.

Feil 4: Å omdirigere handlekurv-, kasse- eller kontosider

AI-genererte regler som rydder i adresser, tvinger frem skråstrek på slutten eller omdirigerer gamle sider, kan kollidere med sidene, endepunktene og query-forespørslene WooCommerce er avhengig av:

/cart/
/checkout/
/checkout/order-received/
/my-account/
/my-account/lost-password/
/?wc-ajax=...
/?wc-api=...

Det er standardnavnene på engelsk. En butikk som ble satt opp på norsk, har som regel /handlekurv/, /kassen/ og /min-konto/ i stedet. Regler som disse er risikable:

RewriteRule ^kassen$ /kassen/ [R=301,L]
RewriteRule ^min-konto$ /logg-inn/ [R=301,L]

• Omdirigeringsløkker. WordPress sender allerede besøkende til sin kanoniske adresse, for eksempel med eller uten www. En serverregel som peker motsatt vei, sender nettleseren fram og tilbake til den gir opp.
• Tapte skjemadata. Ved 301 eller 302 kan nettleseren gjøre en POST om til en GET, så en omdirigering foran et skjema, kassen eller et tilbakekall kan miste det som ble sendt. WordPress selv omdirigerer aldri POST-forespørsler til kanoniske adresser.
• Tapte query-strenger. En erstatning som slutter på ?, eller flagget [QSD], kaster query-strengen. Det ødelegger wc-ajax-forespørsler og tilbakekall fra betalingsløsninger, for eksempel PayPal Standard, som WooCommerce sin dokumentasjon viser som forsideadressen pluss ?wc-api=.
• Endepunkter som havner i ingenting. Apache sin Redirect tar med resten av stien, så Redirect 301 /min-konto /logg-inn sender også alt under /min-konto/, som glemt passord og ordrer, videre til adresser under /logg-inn/ som ikke finnes.

La handlekurv, kasse og kontosider være i fred med mindre du har en konkret grunn, og test hele ordreflyten, betalingen med, etterpå.

Feil 5: Å returnere HTML der AJAX forventer JSON

En AJAX-forespørsel i WooCommerce forventer JSON, som {"result":"success","fragments":{}}. En dårlig regel returnerer <!DOCTYPE html> og en hel side i stedet. Nettleseren kan fortsatt vise 200 OK, men JavaScript-koden i kassen kan ikke bruke svaret. Åpne Network-fanen, filtrer på Fetch/XHR, og se på adressen, statusen, headerne, innholdstypen og innholdet i forespørselen som feiler: wc-ajax=update_order_review i den klassiske kassen, forespørsler under /wp-json/wc/store/ i kasseblokken. WooCommerce sin feilsøkingsguide lister opp hva som gjør JSON om til HTML: et cache-, vedlikeholds- eller sikkerhetslag, en omdirigering, en proxy eller en PHP-advarsel. Innlegget vårt om WooCommerce checkout som henger i innlasting går gjennom hver årsak.

Feil 6: Å bruke .htaccess til problemer WordPress burde håndtere

Mange AI-genererte regler løser på servernivå det WordPress håndterer tryggere, og Apache sin egen dokumentasjon kaller mod_rewrite en siste utvei når enklere verktøy finnes.

• Forsiden: i stedet for RewriteRule ^$ /home.html [L], velg en statisk forside under Innstillinger > Lesing eller lag front-page.php.
• Omdirigeringer: i stedet for RewriteRule ^gammel-side$ /ny-side [R=301,L], bruk en omdirigeringsplugin for alt redaktørene vedlikeholder. For noen få faste omdirigeringer anbefaler Apache de enklere direktivene Redirect og RedirectMatch framfor RewriteRule.
• Ressurser: i stedet for RewriteRule ^assets/(.*)$ /custom-folder/$1 [L], last inn filene med wp_enqueue_style() og wp_enqueue_script().
• Endringer i kassen: i stedet for RewriteRule ^kassen/(.*)$ /egen-kasse.php [L], bruk WooCommerce sine hooks og maloverstyringer.

Feil 7: Å lime inn cache- og header-blokker som treffer hver side

Ber du et AI-verktøy om å gjøre WordPress raskere, kan du få noe sånt som dette:

<IfModule mod_headers.c>
  Header set Cache-Control "public, max-age=31536000"
</IfModule>

Uten avgrensning havner den headeren på hvert vellykkede svar Apache sender, også sidene WordPress bygger gjennom index.php: handlekurv, kasse og Min konto. Nettopp på de sidene sender WooCommerce headere som sier at de ikke skal caches. Header set erstatter en header med samme navn, og der PHP kjører på PHP-FPM gjennom mod_proxy_fcgi, advarer Apache sin dokumentasjon om at svaret kan få begge verdiene i stedet. Uansett har kassen nå en cacheheader på ett år. Avgrens regelen til statiske filer:

<FilesMatch "\.(css|js|png|jpe?g|gif|webp|avif|svg|woff2?)$">
  Header set Cache-Control "public, max-age=31536000"
</FilesMatch>

Lang levetid er bare trygt når filadressen endres hver gang filen endres, og nettopp det er jobben til versjonsnummeret WordPress legger på filer som lastes inn med enqueue. Legg også merke til <IfModule>-rammen. Apache leser bare det som står inni når modulen er lastet, og dokumentasjonen sier at vanlige konfigurasjoner ikke trenger den. Mangler mod_headers, gjør regelen i rammen ingenting uten å si fra, mens den samme regelen uten rammen gir en 500-feil. Sjekk i nettleseren at headeren faktisk er der.

Feil 8: Å ikke teste innloggede og utloggede besøkende

Regler kan teste informasjonskapsler, forespørselsmetoden og query-strengen, og WooCommerce ber cacher hoppe over besøkende som har informasjonskapslene for handlekurv og økt. En innlogget admin kan se riktige sider, mens kundene får bufrede eller omdirigerte. Etter en endring tester du innlogget og utlogget, i et privat vindu, på mobil og gjennom hele flyten fra produkt til kasse, og i tillegg et skjema, søk, innlogging, kontosiden og REST API- eller AJAX-endepunkter du er avhengig av.

Feil 9: Å ikke ta backup, og ikke lese 500-feilen

Én ødelagt linje i .htaccess kan ta ned hele nettstedet med en 500 Internal Server Error. Typiske årsaker:

• En skrivefeil. Feilloggen til Apache sier hva som er galt, for eksempel RewriteCond: bad flag delimiters.
• Et direktiv webhotellet ikke tillater. AllowOverride i serverkonfigurasjonen bestemmer hva .htaccess kan inneholde, og alt annet gir serverfeil. En linje som Options -Indexes krever AllowOverride Options.
• En modul som ikke er lastet. Et ukjent direktiv er også en feil. Apache sin egen test på om .htaccess blir lest i det hele tatt, er å skrive et tullord i filen og se etter 500-feilen.
• PHP-innstillinger på feil sted. Linjer med php_value og php_flag, for eksempel for å øke minnegrensen eller grensen for opplasting, hører til PHP som kjører som Apache-modul, og er ukjente direktiver uten den. Der PHP kjører som FastCGI eller PHP-FPM, bruker du en .user.ini-fil.

Før du endrer filen, last ned en kopi eller lagre en utenfor den offentlige webroten. Gjør én endring av gangen, og last siden på nytt etter hver. Ryker nettstedet, legger du tilbake kopien med en gang.

Feil 10: Å overse cache- og CDN-lag

Selv etter at du har rettet .htaccess, kan den gamle oppførselen se ut til å fortsette fordi en cache-plugin, en servercache, CDN-et eller nettleseren fortsatt har gamle svar. Tøm de relevante cachene og test på nytt. Omdirigeringer krever ekstra omtanke: en 301 kan caches som standard, så en feil permanent omdirigering kan fortsette å slå til fra besøkendes nettlesere etter at du har fjernet regelen. Test nye omdirigeringer som 302, som også er det [R]-flagget til Apache sender når du ikke oppgir kode, og bytt til 301 når de er riktige.

I WooCommerce holder du handlekurv, kasse og Min konto utenfor side- og CDN-cache, og sørger for at cachen, CDN-et og brannmuren slipper WooCommerce sine AJAX-forespørsler gjennom. Med norske sidenavn:

/handlekurv/
/kassen/
/min-konto/
/?wc-ajax=

Slik går du gjennom en AI-generert .htaccess-regel trygt

1. Hvilken forespørsel nøyaktig skal den påvirke? «Forsiden» er et svakt svar. Bedre: bare en GET-forespørsel til / uten query-streng, fra en besøkende som ikke er innlogget, aldri AJAX, REST API eller WooCommerce.
2. Håndterer eller ignorerer den query-strenger? Mønsteret ser dem aldri.
3. Kan den berøre de dynamiske rutene i WordPress? Sjekk /wp-admin/, /wp-login.php, /wp-json/, /?wc-ajax=, /?wc-api=, handlekurv, kasse og Min konto.
4. Finnes det en løsning i WordPress? Hvis ja, velg den.
5. Kan du teste den på staging, på samme type server som det live nettstedet?
6. Finnes det en plan for å rulle tilbake? Ha backupen innen rekkevidde.

Rask feilsøkingssjekkliste: Ødela .htaccess WordPress?

• Laster nettstedet og /wp-admin/? Virker permalenkene og /wp-json/?
• Serveres forsiden av WordPress eller av en statisk fil?
• Returnerer kassens AJAX-forespørsel JSON? Blir bestillingen fullført?
• Finnes det omdirigeringsløkker? Laster CSS og JS? Virker søk og kontaktskjema?
• Tømte du cachene, og løser det problemet å legge tilbake den forrige .htaccess?

Å legge tilbake forrige versjon og teste på nytt er ofte den raskeste måten å bekrefte at .htaccess er årsaken.

Når du bør be om hjelp

Hent inn en spesialist når kassen laster i det uendelige, WooCommerce-AJAX returnerer HTML, omdirigeringer oppfører seg ulikt fra gang til gang, admin virker mens forsiden feiler, nettstedet røk rett etter en AI-generert endring, eller ingen kan si hva en regel gjør. Årsaken kan være én linje, men for å finne den må noen følge forespørselen hele veien.

Gjennomgang og retting av AI-skrevne .htaccess-regler er en del av WordPress-feilrettingen vår: gratis diagnose, fast pris skriftlig før vi starter (fra 1 990 kr eks. mva), og «Ingen fiks, ingen betaling». Har endringen dratt med seg PHP-feil, gjelder de samme vilkårene for fiksing av PHP-feil. Send oss saken, så svarer vi innen 30 minutter i arbeidstiden og følger forespørselen til den egentlige årsaken før vi endrer noe.

Avsluttende tanker

AI kan lage .htaccess-regler raskt, men det gjør dem ikke trygge for WordPress. Risikoen ligger i å legge til regler på servernivå uten å vite hva WordPress, WooCommerce og plugins forventer av hver forespørsel. Før du bruker en, spør: hva annet kan denne regelen påvirke? Det spørsmålet kan spare deg for timer med feilsøking og tapte ordrer.

Kilder

Sist kontrollert 12. november 2026.

• Apache HTTP Server Tutorial: .htaccess files. Gjelder per mappe, leses ved hver forespørsel, AllowOverride, serverfeil for direktiver som ikke er tillatt, tullordtesten og eksemplene fra feilloggen.
• Apache: mod_rewrite. Mønsteret ser aldri query-strengen, ingen innledende skråstrek i .htaccess, ^/ som aldri matcher der, query-strengen som sendes videre, REQUEST_URI, HTTP_COOKIE, REQUEST_METHOD, bindestreken og sjekkene -f og -d.
• Apache: RewriteRule Flags. [L] i mappekontekst, [END], [R] med 302 som standard, og [QSD].
• Apache: When not to use mod_rewrite. En siste utvei, Redirect og RedirectMatch for enkle omdirigeringer, og at Redirect tar med resten av stien.
• Apache: mod_headers og core. Header set, doble headere med mod_proxy_fcgi, IfModule, FilesMatch og LimitInternalRecursion.
• LiteSpeed: rewrite rules og Apache to LiteSpeed Web Server Migration FAQ. Konfigurasjon og rewrite-regler som følger Apache, og [L] som oppfører seg som [END] hos Apache.
• WordPress: Apache HTTPD / .htaccess og Nginx. WordPress-blokken, og at Nginx ikke har .htaccess.
• WordPress: Settings Permalinks screen, insert_with_markers() og WP_Rewrite::mod_rewrite_rules(). At lagring av permalenker skriver filen, at bare blokken mellom markørene erstattes, og IfModule-rammen og index.php-snarveien.
• WordPress REST API Handbook: Routes and Endpoints, get_search_form(), redirect_canonical() og Cookies. ?rest_route=, søk med ?s=, kanoniske omdirigeringer som hopper over POST, og informasjonskapselen wordpress_logged_in_.
• WordPress Theme Handbook: Template Hierarchy og Including Assets. front-page.php, enqueue og versjonen som brukes til cache busting.
• WooCommerce: Endless loading/spinner on the checkout page. Forespørslene i klassisk kasse og kasseblokken, hva som gjør JSON om til HTML, og lagene som må slippe WooCommerce-AJAX gjennom.
• WooCommerce på GitHub: class-wc-ajax.php, class-wc-cache-helper.php og class-wc-install.php. wc-ajax på forsideadressen, headere mot caching på handlekurv, kasse og Min konto, og oversatte sidenavn.
• WordPress.org-oversettelse av WooCommerce (bokmål). Sidenavnene handlekurv, kassen og min-konto.
• WooCommerce developer docs: How to configure caching plugins for WooCommerce og Understanding WooCommerce endpoints. Sider og informasjonskapsler som holdes utenfor cachen, og endepunktene.
• WooCommerce: Creating WooCommerce add-to-cart URLs, WooCommerce Payment Gateway API og Template structure and overriding templates via a theme. ?add-to-cart=, tilbakekallet fra PayPal Standard på ?wc-api=, og maloverstyringer.
• IETF RFC 9110: HTTP Semantics, 301 og 302. Nettleseren kan gjøre POST om til GET, og en 301 kan caches som standard.
• PHP-manualen: How to change configuration settings og .user.ini files. php_value for PHP som Apache-modul, og .user.ini for CGI og FastCGI.