Brain's Test Site

Blog

  • What happens to an old permalink after a slug change

    When a WordPress post changes its slug, the old address does not simply die. WordPress records the previous slug in post meta and answers requests for it with a redirect to the new location. That behaviour keeps inbound links working, but it also means a URL and the post behind it can drift apart. This article walks through what the redirect does, where it breaks, and how an external tool should treat it.

    Where the old slug is kept

    The moment a published post is saved with a new post name, WordPress writes the previous value into the old slug meta key. The template loader consults that key when a request matches no post, and if it finds one it issues a permanent redirect to the post’s current permalink. Nothing is stored about when the change happened or who made it, so the meta is a hint, not a history.

    What the redirect hides

    A browser following the redirect sees the right page, so from the outside nothing looks wrong. The trouble starts when a program resolves the address by slug instead of by following the response. A lookup for the old slug returns nothing, because the slug is now on nobody. A tool that then falls back to creating content would produce a second copy of a page that already exists under a different address.

    Signals worth checking

    Three checks separate a moved post from a missing one. First, fetch the old address without following redirects and read the Location header. Second, look the post up by its numeric id rather than its slug wherever an id is known. Third, compare the canonical link in the page head with the address that was requested. If any of those disagree, the page has moved and the safe action is to stop rather than to guess.

    What editors can do

    Editors rarely rename a slug for fun. A rename usually follows a title change, a merge of two articles, or a cleanup of dates that used to sit in the path. Keeping a short note of the old and the new address in the revision comment costs nothing and answers the question weeks later when a report shows traffic arriving at an address nobody remembers.

    Summary

    The redirect is a courtesy to visitors, not a promise to software. Treat a slug that no longer resolves as a warning that the post has moved, look it up by id when possible, and never create a new post in response to a lookup that came back empty.

  • Att publicera till WordPress över REST-API:et

    Hur publicerar man ett inlägg via REST-API:et?

    Ett nytt inlägg skapas genom att skicka en POST-förfrågan till /wp-json/wp/v2/posts. Förfrågans kropp skickas som JSON och innehåller minst tre fält: title (inläggets rubrik), content (brödtexten, som kan innehålla block-HTML) och status (“publish” för att publicera direkt, “draft” för att spara som utkast).

    Autentiseringen sker med Basic Auth. Kombinera användarnamnet och applikationslösenordet med ett kolon, Base64-koda strängen och skicka den i headern Authorization: Basic {kodad sträng}. Content-Type sätts till application/json.

    Om förfrågan lyckas svarar WordPress med statuskod 201 Created och returnerar det skapade inläggets fullständiga JSON-objekt, inklusive det tilldelade id:t, länken till inlägget och den sparade statusen. Ett svar med 401 betyder att autentiseringen misslyckades, medan 403 innebär att användaren saknar rätt behörighet.

    Hur sätter man kategorier, taggar och utvald bild i samma förfrågan?

    Lägg till fältet categories som en lista med kategori-ID:n och tags som en lista med tagg-ID:n i samma JSON-kropp. För att sätta en utvald bild, ange featured_media med mediaobjektets ID. Slug, excerpt och author kan också skickas i samma POST-förfrågan.

    Hur en svarsmotor läser en sida

    Hur uppdaterar eller raderar man ett befintligt inlägg?

    Skicka en PUT- eller PATCH-förfrågan till /wp-json/wp/v2/posts/{id} med de fält du vill ändra. PUT ersätter hela resursen, medan PATCH uppdaterar bara de angivna fälten. För att radera ett inlägg skickar du en DELETE-förfrågan till samma adress. Som standard läggs inlägget i papperskorgen; lägg till parametern force=true för att ta bort det permanent.

    Vad når REST-API:et och vad når det inte?

    REST-API:et når alla inlägg, sidor och registrerade anpassade innehållstyper, men det når inte skyddade metafält eller layout som ägs av en sidbyggare. WordPress har levererat detta API i kärnan sedan version 4.7, som släpptes den 6 december 2016. Varje resurs kan läsas och skrivas över HTTP under /wp-json/wp/v2/, utan att något tillägg är inblandat.

    Ett applikationslösenord är en inloggningsuppgift per applikation, skild från kontots vanliga lösenord, och kan återkallas för sig utan att personen låses ute. WordPress 5.6 införde dem den 8 december 2020, och de fungerar bara över HTTPS. Lösenordet skapas under Användare, din profil, sektionen “Applikationslösenord” i wp-admin. Värdet visas bara en gång, så det måste kopieras direkt.

    Tre förutsättningar måste vara uppfyllda för att REST-API:et ska ta emot en publiceringsförfrågan:

    • Snygga permalänkar, annars svarar /wp-json/ med 404 och bara ?rest_route= fungerar.

    • HTTPS, som applikationslösenord kräver.

    • En användare med edit_posts, eftersom API:et mappar behörigheter per innehållstyp.

    Varför syns inte sidbyggarens layout via API:et?

    Ett metafält vars nyckel börjar med ett understreck behandlas som skyddat. WordPress exponerar det inte via REST-API:et om inte ett tillägg registrerar det med show_in_rest. En sidbyggare som lagrar sin layout under en nyckel som _elementor_edit_mode är därför osynlig för en API-klient, trots att webbplatsen renderas från den.

    Om innehållet saknas eller är tomt äger en sidbyggare layouten. I så fall finns tre alternativ:

    • Registrera det skyddade metafältet med show_in_rest i ett eget tillägg så att API:et exponerar det.

    • Publicera genom sidbyggarens egen lagring i stället för via post_content.

    • Acceptera att post_content inte kommer att runda hela vägen, och behandla det renderade HTML:et som den auktoritativa källan.

    Elementor, Divi och WPBakery är vanliga byggare som lagrar layout under skyddade nycklar.

    Vill du se hur dina sidor ser ut via API:et?

    Vi går igenom dina tjugo viktigaste sidor och visar vad REST-API:et faktiskt returnerar, vad som saknas och vad en svarsmotor kan plocka upp. Inget konto behövs.


    Boka en genomgång

  • What the classic editor left behind

    What did the classic editor leave behind when WordPress moved to blocks?

    The classic editor offered no native way for an external tool to read or write content over the web. WordPress filled that gap by shipping a content REST API in core with version 4.7 on 6 December 2016. Any post, page or registered custom type can now be read and written over HTTP at /wp-json/wp/v2/, with no plugin involved. That single addition is what makes remote editing possible on a site you do not host.

    Authenticating an external tool was another problem the classic editor never solved. WordPress 5.6 introduced application passwords on 8 December 2020: per-application credentials, separate from the account password, that can be revoked individually without locking the person out. They require HTTPS. Before that release, editing a self-hosted site over the API meant installing an authentication plugin or writing one.

    The classic editor stored every post as a single flat HTML blob, which meant structured layouts, reusable content pieces and column arrangements had no standard format that could travel between tools. WordPress 5.0 replaced it with the block editor on 6 December 2018, wrapping each content block in HTML comment markers so external readers can parse layout, not just text. WordPress 5.5 then added a built-in XML sitemap at /wp-sitemap.xml on 11 August 2020, removing yet another task the classic editor left to plugins.

    Page-builder layouts stored under protected meta keys are invisible to the REST API, a blind spot inherited from the classic editor era. Any meta field whose key begins with an underscore is treated as protected, and WordPress will not expose it unless a plugin registers it with show_in_rest. A builder that keeps its layout under a key like _elementor_edit_mode is therefore hidden from an API client, even though the live site renders from it.

    The practical consequence is that reading post_content is not the same as reading the page.

    Three server-side prerequisites must be in place before any external tool can use the REST API reliably:

    • Pretty permalinks, or /wp-json/ answers 404 and only ?rest_route= works.
    • HTTPS, which application passwords require.
    • A user with edit_posts, since the API maps capabilities per post type.

  • Publishing to WordPress over the REST API

    What the REST API can and cannot reach

    The REST API reaches every core post type and any custom type registered with show_in_rest, giving external tools full read-write access to titles, content, excerpts, categories, tags, and public meta fields. It does not reach meta fields whose keys start with an underscore (protected meta), page-builder layouts stored under those keys, or options tables. Everything below explains why those boundaries exist and what they mean in practice.

    WordPress has shipped a content REST API in core since version 4.7, released on 6 December 2016. Any post, page or registered custom type can be read and written over HTTP under /wp-json/wp/v2/, with no plugin involved. That single fact is what makes an external tool able to edit a site it does not host.

    An application password is a per-application credential, separate from the account password, which can be revoked on its own without locking the person out. WordPress 5.6 added them on 8 December 2020, and they only work over HTTPS. Before that release, editing a self-hosted site over the API meant installing an authentication plugin or writing one.

    Two more releases matter to anything that reads a site from the outside. WordPress 5.0 replaced the classic editor with the block editor on 6 December 2018, which is why post content now arrives wrapped in HTML comments that mark where each block starts and ends. WordPress 5.5 added an XML sitemap at /wp-sitemap.xml on 11 August 2020, so most sites now advertise their own URLs without a plugin.

    The sharpest limit is one the documentation states plainly and people still meet by surprise. A meta field whose key begins with an underscore is treated as protected, and WordPress does not expose it through the REST API unless a plugin registers it with show_in_rest. A page builder that stores its layout under a key like _elementor_edit_mode is therefore invisible to an API client, even though the site renders from it.

    The practical consequence is that reading post_content is not the same as reading the page.

    What prerequisites must a site meet before publishing over the API?

    Three conditions must be in place before the REST API will accept a write request.

    • Pretty permalinks must be enabled; otherwise /wp-json/ returns a 404 and only ?rest_route= works.

    • HTTPS must be active, because application passwords require it.

    • The authenticating user must hold the edit_posts capability, since the API maps permissions per post type.

    How an answer engine reads a page
    The read is whole-page, not keyword-by-keyword.
    SignalWeight
    Dated statisticsHigh
    Named comparisonsHigh
    Brand adjectivesLow

    How do you authenticate with an application password?

    Go to Users, then Profile in the WordPress admin, scroll to Application Passwords, and create a new credential. WordPress will display the password once; copy it immediately. When you send an API request, include an Authorization header with the value Basic followed by a Base64-encoded string of username:application_password. Because the credential travels in the header, HTTPS is mandatory.

    How do you publish a post over the REST API?

    Send a POST request to /wp-json/wp/v2/posts on your site. The request body is JSON and must include at least the title field. To publish immediately, set status to “publish”; omitting it creates a draft. Other useful fields include content (the post body as HTML or block markup), slug, excerpt, and categories (an array of term IDs). A minimal request looks like this:

    POST https://example.com/wp-json/wp/v2/posts
    Content-Type: application/json
    Authorization: Basic base64(username:app_password)

    {“title”: “My first API post”, “content”: “Hello from the REST API.”, “status”: “publish”, “slug”: “first-api-post”, “categories”: [3]}

    How do you confirm the post was created?

    A successful publish returns HTTP 201 Created with a JSON body that contains the new post’s id, link (the public URL), and the status you requested. If you receive a 401, the application password or username is wrong. A 403 means the user lacks the required capability. To double-check, send a GET request to /wp-json/wp/v2/posts/{id} and verify that the title, content, and status match what you sent.

    Try publishing on your own site

    Want to see how the REST API handles your specific theme, custom fields, and post types? A short walkthrough covering your top twenty pages can surface issues before they reach production.

    Book a walkthrough

    Rig check 2026-09-15: this paragraph was added to test edit detection.

  • Thrive fixture

    A thrive fixture is a structured content refresh that makes an existing page quotable by AI search engines. It restructures existing claims into dated facts, standalone definitions, and sourced comparisons, while leaving the page’s design, URL, and visual layout untouched. The output is the same page a visitor already recognises, with every paragraph rewritten so an answer engine can attribute and repeat its content. Most teams still write for a reader who arrives from a list of blue links, but that reader is becoming the minority. An answer engine reads the whole page, decides which claims it can stand behind, and reproduces a version of your argument without ever sending the visit. The page still did its job, but nothing in your analytics says so.

    The content that survives AI processing is unglamorous. It is the material a model can attribute and repeat with confidence. The following forms hold up best:

    • Specific numbers with a date attached, so the model knows when the claim was true.

    • Definitions written plainly enough to lift into a single-sentence answer.

    • Comparisons that name the alternatives instead of gesturing at them.

    Short, vivid sentences without a fact, a date, or a named comparison give an AI model nothing to attribute. Pages that mix strong claims with unsupported commentary lose density: the model keeps the sourced lines and skips the rest.

    Refreshing a page for AI search means making the claims you already believe legible, not adding more keywords. The practical steps are:

    1. Pull each key figure out of the surrounding paragraph so it stands on its own.

    2. Give every definition its own sentence, written plainly enough to quote directly.

    3. State when each number was true, so a model knows the claim’s shelf life.

    None of that requires a redesign. All of it requires touching the words rather than the layout.


    Book a walkthrough

    That distinction between words and layout is the whole reason a structured content refresh matters. A refresh that rewrites paragraphs but breaks the page’s visual hierarchy loses reader trust alongside any ranking benefit. The goal is a page that looks the same to your audience and reads better to every model that summarises it. You can verify the result by comparing AI-generated citations before and after the edit and confirming that organic traffic has not dropped.

    Key definitions and benchmarks

    Thrive fixture: a single-page deliverable in which an editor rewrites every paragraph of an existing article so its claims are dated, sourced, and structured for AI extraction. The page’s design, URL, and metadata stay the same. A fixture typically takes one to two working days per page. Success is measured by whether the page’s claims begin appearing in AI-generated answers and whether organic impressions hold steady or grow after the edit.

    AI Overview: a summary answer generated by a search engine at the top of results, displayed before any traditional blue links. These summaries now appear on a significant and expanding portion of English-language queries, though Google has not published an exact percentage as of 2025.

    Zero-click search: a search session in which the user never visits an external website. A 2024 study by SparkToro and Datos found that roughly 60% of Google searches ended without a click to a third-party site, a figure widely cited across the search industry.

    Content refresh: an edit to an existing published page that updates facts, restructures claims for clarity, and adds source dates, without changing the page’s design or URL. A thrive fixture is a specific type of content refresh: it focuses on making every claim individually quotable by AI search engines, not just updating outdated information.

    Be the brand AI recommends

  • Protected: Hello world!

    This content is password-protected. To view it, please enter the password below.