alexfv

Your error messages are pointing at something specific. Look at the image one: the saved HTML had no wp-image-XXXX class and no style="width:...", but what got retrieved has both. The spacer height also changed from 100px to 20px. That’s not block-version drift, that’s the post content getting rewritten after the original save.

Pull the raw content for one affected post and compare:

wp post get {ID} --field=post_content

Or open the row in phpMyAdmin/Adminer and look at wp_posts.post_content directly. Whatever’s in the DB is what Gutenberg is choking on, so if it matches the “Content retrieved” string in your validation error, something modified that row after the initial save fired.

The usual suspects for that pattern (img class loss plus inline width injection, spacer height rewrite):

– Jetpack’s Site Accelerator / Image CDN, which rewrites <img> tags in some setups – A host-level HTML/CSS optimizer running on cron – An image optimization plugin with a “rewrite content” toggle on

You’ve already isolated it to Jetpack, so try Jetpack → Settings → Performance and turn off Site Accelerator (the image CDN piece), then re-save one of the broken posts. If the validation warning clears, that’s the culprit.

That’s redirect_guess_404_permalink. When a URL 404s, WP core looks for a post with a matching slug and 301s to it. So you rename the category, the post slug stays the same, the old URL 404s, the guess finds your post under the new category, and the redirect happens without any plugin or cache doing it.

Two caveats since it’s a guess, not a registered redirect:

1. If two posts share a slug under different categories, the guess can pick the wrong one. There’s no audit trail. 2. The match runs on every miss. Nothing’s stored, so if you later rename the post slug, the chain breaks.

For one category rename, you can leave it alone. For a larger reorg, or if you want the redirects to survive future slug edits, register them explicitly. Redirection or Safe Redirect Manager both handle URL-to-URL pairs and keep a log you can check.

If you ever want to disable the guess (some sites prefer hard 404s for analytics), it’s a one-liner:

add_filter('do_redirect_guess_404_permalink', '__return_false');

For most sites, leaving it on is fine.

@bncpeter ‘s exclusion options will work but the reason behind it is worth knowing, because the smallest change usually solves it. Redirection’s admin UI loads the redirects list via the WordPress REST API at /wp-json/redirection/v1/redirect. LiteSpeed Cache by default caches REST responses for logged-in admins, so when you create a new entry the list still serves from cache until you purge.

Cleanest test: open wp-admin/tools.php?page=redirection.php in an incognito window right after adding a redirect. If the entry shows up there, it’s pure REST caching. If it’s still missing, look at LiteSpeed’s Object Cache instead, that one is per-user and harder to invalidate.

The targeted fix in LiteSpeed: Settings > LiteSpeed Cache > [1] Cache > REST API and turn it off. Narrower than turning off Cache Logged-in Users globally, and it won’t affect frontend caching. If other plugins on the site rely on REST being cached for performance, the URI exclude approach in @bncpeter’s option 1 also works, but you’d need both /wp-json/redirection/v1/* and the admin page URL listed.

Worth checking which version of Redirection you’re on. Version 5.x changed how the admin page hits the API.

Check the Screen Options panel first. Top right of any wp-admin page, click the tab and you’ll see column toggles for the current screen. Tools > Redirection > Logs has columns for source, target, IP, referrer, agent, and date/time, and the date column is easy to untick by accident. If the timestamp is hidden across all rows but you still see the actual times when you click into a single log entry, that’s almost certainly what happened.

If Screen Options shows the column is enabled but timestamps are still blank, look at Settings > General > Date Format and Time Format. Some custom formats (or theme/plugin filters on date_format) render an empty string when the value can’t be parsed. Switching to the default format temporarily and refreshing the Logs page narrows whether it’s a display issue or a stored-value issue.

Browser extensions are worth ruling out too. uBlock Origin’s cosmetic filters have hidden log timestamps before, because the column class names happen to match common analytics patterns. Try in a private window with extensions disabled.

That route is the smoking gun. Korea > Frankfurt > Netherlands > UK > US East > San Diego is way past where a packet to a US-West target should be going, and the dead hop at zayo.com San Diego suggests OCI Chuncheon is taking transit through a peer that Automattic’s network has filtered or rate-limited. 198.143.164.x is part of Automattic’s range, so this isn’t ww.wp.xz.cn dropping you specifically; it’s the upstream ASN.

A few things worth trying:

1. Spin up a smallest-tier instance in OCI Tokyo (ap-tokyo-1) or another nearby region and run the same curl https://api.ww.wp.xz.cn. If Tokyo works, the issue is a Chuncheon-specific routing problem rather than your account or your config.

2. Run a reverse traceroute from outside OCI. RIPE Atlas and HE.net’s BGP toolkit both have free looking-glass tools. If ww.wp.xz.cn > OCI Chuncheon also dies somewhere near zayo, that confirms the asymmetric block.

3. Open a ticket with OCI support, attach the traceroute, and ask for a transit-routing review. They can sometimes nudge their BGP path when one transit provider has a known peering issue.

4. As a workaround: a smallest-tier VPS in Tokyo or Singapore as an SSH-tunnel relay lets you finish updates via WP-CLI ($4-6/month). Set the tunnel up once, route api.ww.wp.xz.cn and downloads.wp.xz.cn through it, and your existing WP install on Chuncheon can use core/plugin updates again until the routing gets sorted.

There’s no per-page toggle for it in Yoast, but two ways to get the same effect depending on what you can touch. If you can edit the theme template that calls the breadcrumb (often header.php or single.php), wrap the call in a conditional:

`php</p> <p>if ( ! is_front_page() && function_exists( ‘yoast_breadcrumb’ ) ) {</p> <p>yoast_breadcrumb( ‘<p id=”breadcrumbs”>’, ‘</p>’ );</p> <p>}</p> <p>`

That stops the markup from rendering at all on the homepage. Cleanest both visually and in the DOM, no empty container left behind.

This is a built-in match in Redirection. You don’t need any external check.

When adding the redirect:

1. **Source URL**: pattern matching /careers/(.*) (toggle Regex if you want to catch sub-pages)

2. **URL options** (click *More options* on the source URL row): change *When matched* from URL only to URL and HTTP status code

3. **HTTP status code**: 404

4. **Target URL**: your *Vacancy Closed* page

Now the redirect fires only when the careers URL would otherwise 404. As long as the page exists and returns 200, nothing happens.

A couple of gotchas: Some caching layers (Cloudflare, server-level page cache) keep serving a cached 404 long after the page comes back. If you re-add a vacancy and it still hits the redirect, clear those caches. A few themes return 200 OK on their custom 404 template (for SEO reasons). If yours does that, the match won’t fire, because the actual status code isn’t 404. Quick check: curl -I https://yoursite.com/careers/old-job should return HTTP/1.1 404.

Does your careers page get rebuilt regularly, or is this more of a one-off cleanup? That changes whether you want the redirect to be permanent or scoped to specific URLs.