Product Category URLs Return 404 After Enabling the Slug RemoverPRO

You enabled SEObolt’s “Remove /product-category/ from URLs” toggle, saw the success message, and now every category URL on your store returns a 404 instead of redirecting cleanly. Pre-SEObolt 2.4.128, the rewrite-rules flush only fired on subsequent saves — the first time you enabled the toggle, the option saved but WordPress’s rewrite rules stayed stale, so the old URLs 301-redirected to the new clean shape which then 404’d because the new rules weren’t registered yet. There’s a one-click workaround AND the proper fix in 2.4.128+.

One-click workaround — Settings → Permalinks → Save

If you can’t update SEObolt right now and you need to fix this in 30 seconds: go to WP Admin → Settings → Permalinks and click Save Changes (without changing anything). WordPress re-flushes the entire rewrite-rule table from disk, which picks up SEObolt’s slug-remover rules. Your category URLs should resolve cleanly within seconds. This is the universal “rewrite rules are stale” fix in WordPress.

Symptoms

The telltale signs

You visit SEObolt → Settings → WooCommerce and ticked the “Remove /product-category/ from URLs” option. The page showed Settings saved.
Old URLs like https://yourstore.com/product-category/shoes/ now 301-redirect to https://yourstore.com/shoes/
The cleaned URL (/shoes/) returns HTTP 404 instead of showing the category page
Direct product URLs (//) still work normally
Disabling the slug remover toggle doesn’t immediately fix it — same stale-rewrite-rules issue in reverse

Why it’s the redirect-then-404 sequence

SEObolt registered a 301 redirect for the OLD /product-category/... path (so existing inbound links keep working) AND a new rewrite rule for the CLEAN path. Pre-2.4.128 the registration ran but the rule-table flush didn’t — so the 301 still fires (those don’t need rewrite rules), but the new clean-path rewrite isn’t in the table yet. Net effect: customers land on a clean URL that WordPress doesn’t know how to route.

The Fix

Option A: Update to SEObolt Pro 2.4.128+ (proper fix)

2.4.128 hooks BOTH add_option_ AND update_option_ for the slug-remover flush trigger, so the rewrite-rules table is flushed on the very first save — not just on subsequent saves to an already-existing option row.

Update SEObolt Pro

In wp-admin go to Plugins → Installed Plugins, find SEObolt Pro, click Update. If no update is offered, go to Dashboard → Updates → Check Again.

Re-save the slug-remover toggle

Go to SEObolt → Settings → WooCommerce. Untick the “Remove /product-category/ from URLs” toggle, Save. Then tick it again, Save again. Each save now correctly flushes rewrite rules.

Test a category URL

Visit https://yourstore.com// directly in a private browser window (to bypass any cached 404 responses). The category page should load cleanly.

Option B: One-click manual rewrite flush (works on any SEObolt version)

If you can’t update yet, OR you want a 10-second unstick before updating, this works every time:

Go to WP Admin → Settings → Permalinks

Click Save Changes (without changing anything)

The Save Changes button on the Permalinks page is hard-wired to call flush_rewrite_rules() on every click, regardless of whether any settings actually changed. That force-flush picks up SEObolt’s slug-remover registration.

Test a category URL in a private browser window

Use a private window or an incognito tab so you’re not hitting a cached 404 from earlier attempts. Page should load cleanly.

Permalinks → Save Changes is the universal “rewrite rules are stale” fix in WordPress

If you ever land on a 404 for what should be a valid URL after enabling any plugin that adds rewrite rules (custom post types, taxonomy slug changes, slug removers, custom permalink structures), the FIRST thing to try is Settings → Permalinks → Save Changes. It costs nothing, works in 99% of cases, and tells you in 5 seconds whether the issue is rewrite-rules-related or something deeper.

Why Does This Happen?

WordPress emits two different action hooks when an option is saved:

add_option_ fires when an option row is INSERTED into wp_options for the first time (i.e. a brand-new toggle that wasn’t saved before)
update_option_ fires when an existing option row is UPDATED (the toggle was saved before, even if the value didn’t change)

These two actions are mutually exclusive on any given save — WordPress fires one or the other, never both. A plugin that hooks only update_option_* will silently miss the FIRST save of a fresh option, but work correctly on every subsequent save.

SEObolt Pro’s slug remover registered the rewrite-rule flush callback on update_option_seobolt_woocommerce only. So:

First time a customer enabled the toggle → add_option_* fired (option row didn’t exist yet) → flush callback didn’t run → rules stale → 404
Subsequent edits to the same setting → update_option_* fired → flush callback ran → rules current → works correctly

2.4.128 hooks BOTH actions. The flush callback runs on every save regardless of whether the option row is being inserted or updated. Same fix pattern landed on multiple other Royal Plugin add_option / update_option callsites the same release.

Still 404’ing After Both Fixes? Email Priority Support

If you’ve updated to 2.4.128+ AND re-saved the toggle AND visited Settings → Permalinks → Save Changes — and category URLs still 404 — the cause is downstream of SEObolt’s rewrite-rule registration. Email support@royalplugins.com. Priority email support is included with your SEObolt Pro license — typical response within 24 hours.

Information we’ll need

SEObolt Pro version (Plugins → Installed Plugins)
WordPress version + WooCommerce version
Active permalink structure (Settings → Permalinks → the URL pattern shown for Posts)
Sample category URL that’s 404’ing (we’ll curl it from outside to compare what you’re seeing)
Other active SEO plugins — Yoast / Rank Math / AIOSEO running alongside SEObolt? Two SEO plugins both writing rewrite rules can fight over the slug-remover surface.
Server stack (Apache vs nginx vs LiteSpeed) — nginx ignores .htaccess so the rewrite rules need to live in WordPress’s rule table differently