WordPress REST API-fejl i Site Health

Kort svar: Åbn Webstedssundhed og udvid REST API-fejlen, så du får endpoint og fejlkode. Test først det offentlige REST-indeks, men husk at et 200-svar dér ikke beviser, at en autentificeret editorrequest virker. Undersøg derefter den konkrete route, redirect-kæde, cookie/nonce, firewall og serverlog. Slå ikke REST API fra; WordPress-administration og mange plugins er afhængige af den.

Fagligt gennemgået: 28. august 2026

Kontrolgrundlag: WordPress 7.1, PHP 8.4.23 og Chrome 151 på isoleret staging. Kontrollerede REST- og noncefejl er efterprøvet med Hostious Article Lab 1.4.1; route, status og response body på det berørte site er altid afgørende.

Site Health kan rapportere både REST API- og loopbackproblemer. De ligner hinanden, fordi WordPress kalder sit eget domæne, men de er ikke samme test. Gem den præcise fejltekst og route, før du ændrer noget.

Før du ændrer noget: Tag backup. Kopiér Site Health-detaljen og et anonymiseret Site Health Info-udtræk. Fjern ikke security-regler eller Basic Auth bredt for at få en grøn test.

1. Læs detaljen – ikke kun den røde overskrift

Gå til Værktøjer → Webstedssundhed → Status, udvid testen og notér:

• endpoint/URL;
• HTTP-status eller WP_Error-kode;
• response body, hvis vist;
• om teksten siger REST API eller loopback;
• tidspunktet for testen.

Læs body og Content-Type sammen med status

Statuskoden alene kan snyde. En proxy kan returnere 200 med en HTML-login- eller challengeside, selv om editoren forventer JSON. Omvendt kan en korrekt REST-fejl være JSON med 401 eller 403 og en præcis WordPress-kode. Gem derfor fire felter fra samme request: metode, status, Content-Type og de første ufølsomme felter i body.

Se også på redirecthistorikken. En POST, der bliver sendt fra http til https, fra www til non-www eller via en loginredirect, er ikke den samme request længere. Ret den URL, WordPress og integrationen genererer, frem for at acceptere en ekstra redirect som permanent REST-design.

2. Test REST-indekset og den konkrete route

Åbn https://dit-domæne.dk/wp-json/ i et privat vindue. Et korrekt indeks er JSON og viser namespaces. Test derefter den route, Site Health nævner.

Det offentlige indeks kan være åbent, mens POST/PUT eller autentificerede routes blokeres. Brug browserens Network-panel under den handling, der fejler, og gem metode, status, Content-Type og response body.

Hvis editoren viser “not a valid JSON response”, fortsæt med editorens JSON-guide, som fokuserer på den konkrete gem-request.

3. Kontrollér permalink og serverrouting

En 404 på pæne REST-URL'er kan skyldes rewrite. Tag kopi af .htaccess eller Nginx-serverblokken, og gem permalinkstrukturen uden at ændre den. Kontrollér WordPress' besked om, hvorvidt reglerne kunne skrives.

På Nginx skal query arguments og routing sendes korrekt videre til WordPress. Det er en serverændring og bør håndteres af hosting, hvis du ikke ejer konfigurationen.

Skift ikke offentlige permalinks eller genudgiv indhold som løsning på en REST-404.

4. Kontroller authentication, cookie og nonce

WordPress' indloggede REST-kald bruger cookieauthentication og nonce. Ved 401/403:

1. log ud og ind i en frisk fane;
2. kontrollér om WordPress- og websteds-URL har samme forventede origin;
3. se om requesten sender X-WP-Nonce uden at kopiere værdien;
4. læs WordPress-fejlkoden i body;
5. kontrollér brugerens capability til routen.

På serveropsætninger kan Authorization-headeren blive fjernet, hvilket især rammer Application Passwords eller integrationer. Bevis det med den konkrete authmetode og serverlog; tilføj ikke en global headerregel uden afgrænsning.

5. Find firewall/WAF-reglen

Match endpoint, metode og tidspunkt i sikkerhedsloggen. REST bruger flere HTTP-metoder end almindelig sidevisning; en regel kan tillade GET, men blokere POST/PUT/DELETE.

Lav kun en undtagelse til det nødvendige endpoint og metode. Gentag både den legitime request og en negativ kontrol. At allowliste hele /wp-json/ er unødigt bredt.

6. Skel loopback fra browserkald

Ved loopback kalder WordPress sit eget domæne fra serveren. Din browser kan derfor åbne siden, mens serveren ikke kan resolve DNS, validere certifikatet eller passere en firewall/Basic Auth.

Hosting skal teste fra samme container/runtime som WordPress:

• DNS-resultat;
• TLS/certifikatkæde;
• timeout;
• HTTP-status og redirect;
• om origin blokerer sin egen udgående IP.

Hardcod ikke domænet til en IP i applikationen som permanent løsning. Det kan omgå DNS, certifikat og load balancer på en farlig måde.

7. Isolér plugin/tema uden at påvirke besøgende

Brug staging eller Health Check Troubleshooting Mode. Moden påvirker kun din session, mens besøgende fortsat ser normal opsætning. Test først med standardtema og nødvendige plugins; reaktivér grupper binært, mens den samme REST-route testes.

Dokumentér også plugin-afhængigheder. Et addon uden sin base kan skabe en ny REST-fejl, der ikke fandtes i produktion.

Kontrolleret testforløb uden at ændre indhold

Brug en læsbar route til transporttesten og den oprindelige adminhandling til auth-testen. Du behøver ikke oprette eller overskrive et indlæg blot for at bevise, at REST virker.

1. Gem Site Health-fejlens fulde detalje og tidspunkt.
2. Åbn /wp-json/ anonymt, og notér status, Content-Type og om body er et REST-indeks.
3. Gentag den konkrete route anonymt, hvis den er offentlig. En 401 på en privat route kan være forventet.
4. Log ind som den rolle, der oplever fejlen, og gentag den oprindelige UI-handling med Network åbent.
5. Find requesten på metode og route; kopier kun anonymiseret fejlkode og request-ID.
6. Ændr ét lag på staging – for eksempel permalinkflush, den præcise WAF-regel eller én plugin-gruppe – og gentag samme request.
7. Gendan ændringen og kontroller, at fejlen kan fremkaldes igen. Genanvend derefter den valgte rettelse og kør sluttesten.

Den negative kontrol er vigtig: en anonym bruger må ikke pludselig kunne læse eller ændre data, blot fordi Site Health bliver grøn. Test derfor en route, der kræver login, både uden cookie og med en bruger uden den nødvendige capability. Det forventede 401/403-resultat skal bevares.

Når cache eller CDN er mistænkt

REST-responses bør ikke fejlsøges ved at slå al cache og sikkerhed fra på live. Sammenlign i stedet responseheaders og body fra normal URL med en stagingrequest, hvor kun den relevante cache-/proxyregel er bypasset. Hvis den fejlende HTML-response har cachealder eller proxyheader, mens origin returnerer korrekt JSON, er rettelsen en smal eksklusion af den dokumenterede route og metode. Hvis origin giver samme fejl, ligger årsagen ikke i edgecachen.

Et CORS-problem er kun relevant, når browseren kalder fra en anden origin. En same-origin WordPress-editor, der får 403 eller invalid JSON, bliver ikke repareret ved at sætte en bred Access-Control-Allow-Origin: *-header. Det kan tværtimod åbne en ny sikkerhedsrisiko.

Før/efter-protokol

Hvis kun Site Healths overskrift ændrer sig, men den oprindelige editor-, plugin- eller integrationshandling stadig fejler, er sagen ikke løst. Omvendt kan en privat route korrekt afvise anonym adgang, selv om et simpelt monitorværktøj kalder det en fejl.

Verifikation

• Site Health-testen køres igen og viser ikke den samme fejl.
• Offentligt REST-indeks returnerer JSON.
• Den konkrete route giver forventet status/body.
• En autentificeret adminhandling virker med korrekt brugerrolle.
• Ingen ny firewall- eller PHP-event opstår.
• Loopback testes særskilt, hvis den var en del af fejlen.

Rollback

Gendan permalink/serverregel, firewallkonfiguration, authregel og plugin-/temaopsætning fra de noterede kopier. Fjern midlertidige allowlists og test, at sikkerhedsbarrieren igen fungerer.

Hvornår skal hosting eller udvikler hjælpe?

Hosting skal hjælpe ved DNS/TLS/loopback, mod_security/WAF, Authorization-header, serverrouting og timeout. Udvikleren skal have route, metode, status, WordPress-fejlkode og komponentmatrix. Hostious WordPress-support kan hjælpe med afgrænsningen.

Sådan dokumenterer du REST-fejlen

Dokumentér både Site Health-symptomet og den konkrete route, der fejler:

1. Site Health REST-fejl med detaljepanelet åbent.
2. /wp-json/-indeks på testsite med namespaces, ingen kundedata.
3. Network-request med route/status/Content-Type og anonymiseret body.
4. Site Health efter rettelse + samme request som maskinelt bevis.

Notér route, metode, status, response type og event eller log ved samme timestamp. Nonce, cookies og authheaders fjernes.

Ofte stillede spørgsmål om REST API-fejl

Er en REST API-fejl i Site Health kritisk?

Den skal tages seriøst: editoren, Site Health og mange plugins bruger REST. Sitet kan se fint ud udefra, mens redigering og baggrundsjobs fejler – så ret den, før den skaber følgefejl.

Hvad blokerer typisk REST API’et?

Firewallregler der rammer /wp-json/, sikkerhedsplugins der kræver login, redirects der ændrer URL’en, eller ødelagte permalinks. Fejlkoden i Site Health viser hvilken retning, du skal lede i.

Hvorfor virker REST for besøgende, men ikke for editoren?

Fordi editorens kald er autentificerede og kan rammes af cookie-, nonce- eller loopback-problemer, som offentlige kald ikke møder. Test derfor altid både et offentligt endpoint og en rigtig gemning.

Læs også

• Hub: WordPress fejl og fejlfinding
• Not a valid JSON response
• 403 Forbidden i WordPress
• Kritisk fejl i WordPress
• Plugin- eller temakonflikt