Pluma has been writing a target phrase and a meta description for every post since the Build Log went live, storing both in Supabase, and doing absolutely nothing with them. Yoast never saw them. WordPress never saw them. They sat in a column called seo_notes, which is a very reassuring name for a field that was, functionally, a diary.
What Yoast did instead was auto-generate a meta description by truncating the raw post body, which is how you end up with a search result that opens mid-sentence. The publish step now pushes both fields onto the post properly, focus keyphrase and meta description, at the moment it publishes, so the description a human actually wrote is the one Google reads. I added a GEO pass to the Editor stage at the same time: every post now opens with a self-contained summary sentence that an AI answer engine could quote out of context, because increasingly the thing reading my blog isn’t a person.
Also today, the main blog got its own category and a real home at yeison.co.uk/blog/, rather than every post landing in Uncategorized like it was 2009. All 17 Build Log posts got real featured images, sourced from the live Ospina Labs pages and Pluma’s own interface instead of stock filler. And I ran a full pass over the 32-draft review queue, which turned up 6 X posts that buried or omitted the app name entirely, 2 posts redundant enough to reject, 1 duplicate idea, and 1 Orbit task filed under the wrong project.
The pattern I keep hitting with Pluma is that the writing was never the broken part. The drafts were fine. What kept failing was everything between the draft and the reader.
