The popular take right now is that the how-to tutorial is dead and personal essays are the only thing worth writing, because the definitional questions already get answered in an IDE chat. Geoff Graham made that case on CSS-Tricks, publishing his own traffic charts to back it up, and I agree with the diagnosis. I just don’t think “write more from the heart” is where WordPress technical writing should land.
Our corner has a different split. Generic explainers are fading, sure, but version-bound notes are not, because that’s where generated answers still fail hardest. OpenAI’s own write-up on why language models hallucinate says training rewards guessing over admitting uncertainty, and a wrong guess at a hook name or a deprecation status reads convincingly right up until it breaks a store. I’ve seen a model suggest woocommerce_get_price_html_from_to() for formatting sale prices, which was deprecated back in WooCommerce 3.0 in favor of wc_get_price_html_from_to(). A version-bound post lives in the gap between that confident answer and the current API.
Where WordPress technical writing still pays off
Before I commit to a post, I run a short audit over my own queue.
Cut anything a chat answers in one shot
What wp_kses_post() does, how to enqueue a stylesheet, what a filter is: a model gets those right nearly every time, so the topic earns almost nothing now. Keep that material in client docs if someone needs it, but it doesn’t belong in the publishing calendar. (I still write these as internal notes; they just don’t go public.)
Bind the topic to a version, a hook, or an exact error string
Good candidates are migration notes after a major WooCommerce release, a renamed function, or the literal PHP notice out of the debug log. Put the version number in the title. Searchers include it, and the post stays findable for years because the question only exists inside one version window.
Write the wrong turns
The fix belongs in the last third of the post. The first two thirds are what I checked first, what it turned out not to be, and how I knew. Nobody can generate that part, and it’s why a reader trusts the fix. A bug traced end to end, like the Gamepad API walkthrough I wrote with CSS cascade layers, is the kind of post that keeps getting read, and writing the process out is good debugging practice anyway.
Date the claim and cite the source
Every statement about behavior gets a link to the changelog or the developer docs, plus a note of the version I tested it on. When the thing changes, I update the post or retire it. Google’s own guidance for generative AI features says you don’t need llms.txt or special markup. Crawlable pages with first-hand information are the minimum, and half-maintained posts don’t meet it.
When to skip the whole audit
None of this applies if the blog is a portfolio and clients come from referrals or the newsletter. One solid migration note per release is plenty, and an hour spent updating a stale post usually beats writing a new one.
Before publishing anything version-bound, run the upgrade on a staging copy and read the debug log yourself. Release notes and upgrade guides are regularly incomplete, and your post inherits whatever they missed. If you want a second pair of eyes on a WooCommerce migration note, or help reproducing a breaking change on staging before you write it up, I do that kind of work and I’m happy to take a look.
