# Werner WordPress Remediation Backlog

Date: 2026-05-29  
Scope: `berchman.com`, `bertmahoney.com`, `bert.forsale`  
Mode: **recommendations/tickets only**. No live WordPress site changes were made or attempted while preparing this backlog.

Source artifacts reviewed:

- `/Users/bertmahoney/workspace/_agents/werner-wordpress-public-audit.md`
- `/Users/bertmahoney/workspace/_agents/werner-wordpress-admin-audit.md`
- `/Users/bertmahoney/workspace/_agents/werner-wp-admin-inventory-werner-confirmed.json`

Important scheduling note: Bert may post tomorrow on `berchman.com` and `bertmahoney.com`. Treat pre-posting work as **read-only verification only** unless Bert explicitly approves a specific write/change after confirming a fresh backup.

---

## Executive Priority Summary

| Priority | Ticket | Site(s) | Severity | Safe before posting tomorrow? | Why now |
|---:|---|---|---|---|---|
| 1 | BF-01 Fix disabled background updates | `bert.forsale` | High / Critical Site Health | N/A for berchman/bertmahoney posting; safe only after backup/staging check | Site Health reports automatic background updates are disabled on the ecommerce-capable site. |
| 2 | XS-01 Investigate invalid Authorization header warning | All 3 | Medium | Read-only diagnosis is safe; server config changes should wait unless urgent | Site Health warning appears on all sites and can affect REST/API auth flows, app passwords, integrations, and future automation. |
| 3 | BM-01 Prune excessive inactive themes | `bertmahoney.com` | Medium | Defer deletion until after tomorrow's post; inventory/export now is safe | 15 inactive themes create unnecessary update/security surface. |
| 4 | BC-01 Fix malformed `bert.forsale` link | `berchman.com` | Medium | Low-risk, but defer until after posting unless explicitly approved | Public homepage contains `http://https//bert.forsale`, which harms trust, navigation, and SEO. |
| 5 | XS-02 Add baseline security headers | All 3 | Medium | Defer production header changes until after posting/test window | Public audit found missing or not-visible core security headers across all sites. |

---

## Current Inventory Snapshot

| Site | Plugins | Active / inactive plugins | Themes | Active / inactive themes | Admin users | Notable Site Health findings |
|---|---:|---:|---:|---:|---:|---|
| `berchman.com` | 16 | 13 / 3 | 5 | 1 / 4 | 3 | Authorization header warning; background updates OK |
| `bertmahoney.com` | 17 | 13 / 4 | 16 | 1 / 15 | 3 | Authorization header warning; background updates OK |
| `bert.forsale` | 23 | 17 / 6 | 2 | 1 / 1 | 3 | **Background updates critical**; Authorization header warning |

Notes:

- The refreshed JSON records `ok: true` for health API calls; that means the REST request succeeded. The admin audit report captures the Site Health result labels, including `authorization-header` = recommended / "The authorization header is invalid" on all three, and `background-updates` = critical on `bert.forsale`.
- `AI Provider for Google` is active in the refreshed inventory on all three sites. The admin audit delta specifically called out new additions on `berchman.com` and `bert.forsale`.

---

# Cross-Site Tickets

## XS-01 — Investigate Site Health warning: Authorization header is invalid

- **Sites:** `berchman.com`, `bertmahoney.com`, `bert.forsale`
- **Severity:** Medium
- **Risk / benefit:**
  - Risk if ignored: REST/API authentication, WordPress Application Passwords, WooCommerce integrations, Site Kit, AI/provider integrations, and future Werner publishing automation may behave inconsistently depending on server/proxy/header handling.
  - Benefit: Cleaner Site Health, more reliable admin/API automation, fewer hidden integration failures.
- **Exact proposed action:**
  1. In each dashboard, open **Tools → Site Health → Status** and expand the Authorization header warning to capture the exact diagnostic detail.
  2. Confirm Hostinger/LiteSpeed passes the `Authorization` header to PHP/WordPress.
  3. If `.htaccess` is used, test the standard pass-through rule in staging or during a maintenance window, for example:
     ```apache
     SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1
     ```
     or the Hostinger/LiteSpeed-recommended equivalent.
  4. Re-test application-password REST auth from a terminal after any change.
- **Safe before posting tomorrow?**
  - **Read-only diagnosis:** Yes.
  - **Server/config changes:** Prefer **No** for `berchman.com` and `bertmahoney.com` until after tomorrow's posts unless Bert explicitly approves a short maintenance/test window.
- **Rollback plan:**
  - Save a copy of the pre-change `.htaccess` / server rule.
  - Revert the added header pass-through directive if Site Health, REST calls, login, or permalinks regress.
- **Verification plan:**
  - Site Health no longer reports "The authorization header is invalid".
  - Confirm `GET /wp-json/wp/v2/users/me` works with application-password auth for each Werner account.
  - Confirm normal public pages still return 200 and logins still work.
- **Open-source/free tooling suggestions:**
  - `curl -I` and authenticated `curl` calls.
  - WP-CLI where shell access exists: `wp eval`, `wp option get`, `wp rewrite flush --dry-run` style checks.
  - WordPress Site Health built-in tests.

## XS-02 — Add baseline security headers

- **Sites:** All three
- **Severity:** Medium
- **Risk / benefit:**
  - Risk if ignored: Clickjacking, MIME sniffing, referrer leakage, and weaker HTTPS posture.
  - Benefit: Better baseline browser hardening with low operational overhead.
- **Exact proposed action:**
  Add/verify compatible headers at Hostinger/LiteSpeed/server layer if possible:
  ```txt
  Strict-Transport-Security: max-age=31536000; includeSubDomains
  X-Content-Type-Options: nosniff
  X-Frame-Options: SAMEORIGIN
  Referrer-Policy: strict-origin-when-cross-origin
  Permissions-Policy: geolocation=(), microphone=(), camera=()
  ```
  Start conservatively. Do **not** add a strict Content Security Policy yet; WordPress plugins/themes often require a discovery/report-only phase first.
- **Safe before posting tomorrow?**
  - Prefer **No** for production header rollout before `berchman.com` / `bertmahoney.com` posting.
  - Safe now: run read-only header checks and prepare exact Hostinger/LiteSpeed implementation notes.
- **Rollback plan:** Remove the newly added header directives or disable the header plugin/module; purge LiteSpeed/cache if used.
- **Verification plan:**
  - `curl -I https://site` shows headers.
  - Browser smoke-test homepage, admin login, post editor, media upload, embeds, YouTube/RSS blocks, WooCommerce checkout on `bert.forsale` if public.
- **Open-source/free tooling suggestions:**
  - `curl -I`, Mozilla Observatory, SecurityHeaders.com, OWASP ZAP passive scan.
  - Prefer server config over an extra plugin; if a plugin is required, use a minimal free header plugin and avoid overlapping security plugins.

## XS-03 — Confirm backup/restore posture before any remediation

- **Sites:** All three
- **Severity:** Medium
- **Risk / benefit:**
  - Risk if ignored: Cleanup/update work can become difficult to recover from if plugin/theme deletion or server config changes cause issues.
  - Benefit: Faster rollback and safer maintenance windows.
- **Exact proposed action:**
  1. Confirm Hostinger backups are enabled and recent.
  2. Confirm WordPress-level backup plugin status:
     - `berchman.com`: `BackUpWordPress` active.
     - `bertmahoney.com`: `BackUpWordPress` active.
     - `bert.forsale`: `BackWPup` active.
  3. Confirm at least one restore path has been tested or documented.
- **Safe before posting tomorrow?** Yes for read-only confirmation/export. Do not trigger major backup jobs during publishing if they could affect performance.
- **Rollback plan:** Restore from Hostinger snapshot or plugin backup if any remediation causes a regression.
- **Verification plan:** Confirm backup timestamp, backup contents, and restore instructions. For ecommerce, confirm WooCommerce orders/media are included.
- **Open-source/free tooling suggestions:** BackWPup free, Duplicator Lite, WP-CLI database export, Hostinger native backups, offsite object storage if already available.

## XS-04 — Review `AI Provider for Google` additions and AI/connector posture

- **Sites:** All three; newly called out additions on `berchman.com` and `bert.forsale`
- **Severity:** Medium
- **Risk / benefit:**
  - Risk if ignored: New AI/provider plugins can introduce data-flow, permission, API key, privacy, content-generation, and dependency concerns.
  - Benefit: Intentional AI tooling with known owners, documented data exposure, and a future-compatible path for WordPress 7 APIs.
- **Exact proposed action:**
  1. Document why `AI Provider for Google` is installed on each site and which features are enabled.
  2. Check whether it stores API keys/secrets, sends post/user/media data externally, or adds REST endpoints/capabilities.
  3. Confirm plugin source, update channel, changelog, and WordPress/PHP compatibility.
  4. Ensure AI output is not auto-publishing without human review.
  5. For `bert.forsale`, review coexistence with Hostinger AI, WooCommerce, Google for WooCommerce, Site Kit, and Jetpack.
- **Safe before posting tomorrow?** Read-only review is safe. Disable/delete/config changes should wait unless a clear risk is found and Bert approves.
- **Rollback plan:** Export/document current plugin settings, then deactivate only during a maintenance window if required. Reactivate and restore settings if editor/admin features break.
- **Verification plan:**
  - Confirm plugin remains updated.
  - Confirm no unexpected public AI endpoints or generated content.
  - Confirm post editor, Site Kit, and publishing workflows still work.
- **Open-source/free tooling suggestions:** WordPress plugin directory/changelog review, WP-CLI plugin inventory, `curl` REST route inspection, ActivityPub/audit-log style plugins if change logging is desired.

## XS-05 — WordPress 7 API/opportunity scan and compatibility watchlist

- **Sites:** All three
- **Severity:** Low / Strategic
- **Risk / benefit:**
  - Risk if ignored: Plugins/themes may lag behind future WordPress 7 APIs and compatibility expectations.
  - Benefit: Better upgrade planning; possible future use of script modules, REST/editor improvements, connector/AI-adjacent APIs, and admin UX improvements.
- **Exact proposed action:**
  1. Track WordPress 7 release notes/API reference for changes affecting script modules, REST/editor endpoints, connector/AI APIs, caching behavior, and admin view transitions.
  2. Build a plugin/theme compatibility matrix before any WordPress 7 upgrade.
  3. Test on staging first, especially for WooCommerce (`bert.forsale`), custom theme `Lei` (`bertmahoney.com`), YouTube/RSS plugins (`berchman.com`), and AI Provider for Google.
- **Safe before posting tomorrow?** Yes, research/planning only. No upgrades before posting.
- **Rollback plan:** Use staging for WP 7 testing. For production upgrades, require full backup plus documented downgrade/restore path.
- **Verification plan:** Staging passes editor, REST API, Site Health, publishing, media, forms, checkout/payment if applicable, and key public-page smoke tests.
- **Open-source/free tooling suggestions:** LocalWP, wp-env, WP-CLI, PHPUnit/plugin checker where available, Lighthouse CLI, Playwright smoke tests.

---

# `berchman.com` Tickets

## BC-01 — Fix malformed public link to `bert.forsale`

- **Severity:** Medium
- **Finding:** Public audit found malformed/insecure homepage link: `http://https//bert.forsale`.
- **Risk / benefit:**
  - Risk if ignored: Broken navigation, user distrust, SEO quality issue, and a visibly unpolished outbound link.
  - Benefit: Quick trust/quality improvement.
- **Exact proposed action:**
  - Locate the homepage/menu/block/template/source containing `http://https//bert.forsale`.
  - Replace it with `https://bert.forsale/`.
  - If the link appears in reusable blocks, navigation menus, theme templates, redirects, or custom fields, fix the canonical source rather than only rendered output.
- **Safe before posting tomorrow?** Technically low-risk, but because it is a content write on a site Bert may post to tomorrow, **defer unless explicitly approved** after backup confirmation.
- **Rollback plan:** Note the original source location and value; revert to previous value if unexpected layout/navigation issues occur.
- **Verification plan:**
  - Public homepage no longer contains `http://https//bert.forsale`.
  - Link opens `https://bert.forsale/` with HTTP 200.
  - Run a broken-link scan of the homepage.
- **Open-source/free tooling suggestions:** Browser inspector, WordPress search, Broken Link Checker already active, `curl`, LinkChecker/free broken-link tools.

## BC-02 — Prune inactive plugins after confirming they are unused

- **Severity:** Medium
- **Finding:** Inactive plugins: `Folders`, `Jetpack`, `WordPress to Substack publishing`.
- **Risk / benefit:**
  - Risk if ignored: Unused plugin code remains an update/security burden even when inactive.
  - Benefit: Smaller attack surface and simpler maintenance.
- **Exact proposed action:**
  1. Confirm each inactive plugin is not needed for tomorrow's posting workflow, historical content display, media organization, analytics, or Substack workflow.
  2. Export settings/data where applicable.
  3. Delete unused inactive plugins one at a time during a maintenance window.
- **Safe before posting tomorrow?** **No deletion before posting** unless Bert confirms none are needed. Read-only review is safe.
- **Rollback plan:** Keep a list of plugin slugs/versions; reinstall the same plugin from WordPress.org or backup if needed; restore settings if separately exported.
- **Verification plan:** Admin loads, homepage loads, RSS/YouTube embeds still render, post editor works, no PHP errors.
- **Open-source/free tooling suggestions:** WP-CLI `wp plugin list`, WordPress.org plugin pages/changelogs, Query Monitor for regression checks.

## BC-03 — Review active content/feed plugin stack for performance and necessity

- **Severity:** Medium
- **Finding:** Public audit saw larger plugin surface, including `automatic-youtube-gallery` and `wp-rss-aggregator`; mobile Performance 67 and Total Blocking Time 940ms.
- **Risk / benefit:**
  - Risk if ignored: Slow rendering, heavier frontend, more external dependencies.
  - Benefit: Faster mobile experience and lower maintenance load.
- **Exact proposed action:**
  - Confirm current need for Automatic YouTube Gallery, WP RSS Aggregator, Advanced Post Block, Ko-fi Button, Quick Page/Post Redirect, and Broken Link Checker.
  - Identify which plugins enqueue frontend assets on the homepage.
  - Disable frontend loads where not needed or replace heavy embeds with static/lazy-loaded alternatives.
- **Safe before posting tomorrow?** Read-only profiling is safe; plugin deactivation/settings changes should wait until after posting.
- **Rollback plan:** Export plugin settings, change one plugin at a time, revert setting/reactivate plugin if layout/content breaks.
- **Verification plan:** Compare Lighthouse mobile before/after; verify YouTube gallery, RSS feeds, redirects, Ko-fi button, and post editor.
- **Open-source/free tooling suggestions:** Lighthouse CLI, WebPageTest free tier, Query Monitor, Chrome DevTools Coverage/Performance, WP-CLI.

## BC-04 — Review active `AI Provider for Google` on berchman.com

- **Severity:** Medium
- **Finding:** Refreshed inventory shows `ai-provider-for-google/plugin` active version 1.1.0; admin delta flagged it as newly added.
- **Risk / benefit:** Same as XS-04, with special attention to mental-health/public-blog content sensitivity.
- **Exact proposed action:** Document enabled features, data sent externally, editor integrations, permissions, and whether it can generate/publish content.
- **Safe before posting tomorrow?** Read-only only.
- **Rollback plan:** Export settings, deactivate only with approval, reactivate if editor workflows break.
- **Verification plan:** Confirm editor/publishing workflow and public pages are unchanged after any future config changes.
- **Open-source/free tooling suggestions:** Plugin changelog, REST route inspection, WP-CLI plugin status.

## BC-05 — Review inactive themes and retain only active theme plus one default fallback

- **Severity:** Low / Medium
- **Finding:** 4 inactive themes: `modern`, `third-try`, `twentytwenty`, `twentytwentytwo`; active theme `twentytwentyfive`.
- **Risk / benefit:**
  - Risk if ignored: Extra theme code requires updates and can carry vulnerabilities.
  - Benefit: Cleaner theme inventory.
- **Exact proposed action:** Keep active `twentytwentyfive` plus one current default fallback if desired; archive/delete old inactive themes after backup.
- **Safe before posting tomorrow?** Defer deletion; read-only review is safe.
- **Rollback plan:** Reinstall theme from WordPress.org or restore custom `third-try` from backup if needed.
- **Verification plan:** Theme screen clean; homepage/editor unaffected; Site Health has no inactive-theme warning.
- **Open-source/free tooling suggestions:** WP-CLI `wp theme list`, Hostinger backups, version-controlled theme export for custom theme.

---

# `bertmahoney.com` Tickets

## BM-01 — Prune excessive inactive themes

- **Severity:** Medium
- **Finding:** 16 themes total, 15 inactive. Active theme: `lei`. Inactive themes: `abhavana`, `abisko`, `emoza-woocommerce`, `eryndo`, `kenta-flow`, `kenta`, `michelle`, `nanospace`, `paramatma`, `plover`, `pulse-folio`, `spiekermann`, `storefront`, `twentytwentyfive`, `twentytwentytwo`.
- **Risk / benefit:**
  - Risk if ignored: Large inactive theme footprint expands patching/security surface and admin clutter.
  - Benefit: Cleaner, safer, easier theme maintenance.
- **Exact proposed action:**
  1. Confirm `lei` is the active production theme and not dependent on any inactive parent theme.
  2. Retain `lei` plus one maintained default fallback theme if desired.
  3. Export/archive any custom theme files before deletion.
  4. Delete unused inactive themes after tomorrow's post and after backup confirmation.
- **Safe before posting tomorrow?** **No deletion before posting**. Inventory/export only is safe.
- **Rollback plan:** Restore deleted theme from backup or reinstall from WordPress.org. For any custom/non-directory theme, keep a ZIP archive before deletion.
- **Verification plan:**
  - Site still uses `lei`.
  - Homepage, post pages, editor styles, navigation, and media pages render normally.
  - Site Health no longer flags inactive theme sprawl if applicable.
- **Open-source/free tooling suggestions:** WP-CLI `wp theme list`, theme ZIP export, git archive for custom theme if available, LocalWP staging test.

## BM-02 — Review inactive plugins and performance-lab overlap

- **Severity:** Medium
- **Finding:** Inactive plugins: `Contact Form 7`, `Optimization Detective`, `Performance Lab`, `Smart Custom 404 Error Page`.
- **Risk / benefit:**
  - Risk if ignored: Unused plugin code and beta/performance tooling remain installed without a clear owner.
  - Benefit: Smaller plugin inventory and clearer performance stack.
- **Exact proposed action:**
  - Determine whether Contact Form 7 forms or custom 404 page are used anywhere.
  - Decide whether Performance Lab / Optimization Detective should be activated intentionally for testing or deleted until needed.
  - Remove unused inactive plugins after backup and after tomorrow's post.
- **Safe before posting tomorrow?** Read-only review only; defer deletion.
- **Rollback plan:** Reinstall by slug/version; restore settings/exported forms if needed.
- **Verification plan:** Search content for forms/shortcodes; test 404 page; run frontend smoke test after future deletion.
- **Open-source/free tooling suggestions:** WP-CLI, WordPress shortcode search, Broken Link Checker, Query Monitor.

## BM-03 — Review active performance/security/media plugins for overlap

- **Severity:** Medium
- **Finding:** Active stack includes LiteSpeed Cache, Modern Image Formats, Broken Link Checker, Media Library Assistant, WPS Hide Login, WP SVG Images, Duplicate Page, Email Encoder, Site Kit, BackupWordPress.
- **Risk / benefit:**
  - Risk if ignored: Feature overlap, heavier admin/frontend footprint, SVG upload risks, and hidden publishing friction.
  - Benefit: More predictable publishing, safer media handling, and better performance.
- **Exact proposed action:**
  1. Confirm each active plugin has a current use case.
  2. For `wp-svg-images`, confirm SVG upload sanitization and trusted-user restrictions.
  3. For LiteSpeed Cache + Modern Image Formats, confirm image optimization/caching settings do not conflict with publishing tomorrow.
  4. For WPS Hide Login, document the login URL securely outside this report/backlog if needed; do not print secrets or sensitive URLs here.
- **Safe before posting tomorrow?** Read-only settings review is safe; avoid cache/media/login setting changes before posting.
- **Rollback plan:** Export plugin settings where available; revert one setting at a time; purge cache after changes.
- **Verification plan:** Test admin login, post editor, media upload, image rendering, contact links/email obfuscation, and Lighthouse mobile.
- **Open-source/free tooling suggestions:** Query Monitor, Lighthouse CLI, SVG sanitizer checks, WP-CLI, browser DevTools.

## BM-04 — Add/finalize homepage meta description

- **Severity:** Low / Medium
- **Finding:** Public audit did not detect a homepage meta description; SEO score was 92.
- **Risk / benefit:**
  - Risk if ignored: Less control over search/social snippets.
  - Benefit: Clearer public positioning and improved SEO polish.
- **Exact proposed action:** Draft and add a concise homepage meta description through the active SEO/meta mechanism, if one exists.
- **Safe before posting tomorrow?** Content/SEO write should wait unless Bert approves; draft text preparation is safe.
- **Rollback plan:** Restore prior meta value or blank state.
- **Verification plan:** View source/public page shows intended meta description; Rank Math/Site Kit/SEO checks pass if used.
- **Open-source/free tooling suggestions:** Browser view-source, Screaming Frog free mode, `curl`, Lighthouse SEO audit.

## BM-05 — Review active `AI Provider for Google` on bertmahoney.com

- **Severity:** Medium
- **Finding:** Refreshed inventory shows `ai-provider-for-google/plugin` active version 1.1.0.
- **Risk / benefit:** AI plugin can be useful for future workflow but should be documented for permissions/data flow.
- **Exact proposed action:** Same as XS-04, with special attention to whether it interacts with personal/professional portfolio content and media library assets.
- **Safe before posting tomorrow?** Read-only only.
- **Rollback plan:** Export settings; deactivate only with explicit approval and maintenance window.
- **Verification plan:** Confirm post editor, media workflows, and public pages remain unchanged after any future adjustment.
- **Open-source/free tooling suggestions:** Plugin changelog, WP-CLI plugin status, REST route inspection.

---

# `bert.forsale` Tickets

## BF-01 — Fix critical Site Health issue: background updates disabled

- **Severity:** High / Critical Site Health
- **Finding:** Admin audit reports `background-updates` status `critical`: "Background updates are not working as expected" / automatic updates disabled.
- **Risk / benefit:**
  - Risk if ignored: WordPress core/security maintenance may not apply automatically, increasing exposure on a plugin-heavy ecommerce-capable site.
  - Benefit: Restores expected security update posture and reduces manual patch burden.
- **Exact proposed action:**
  1. In dashboard, expand Site Health background update details and capture exact cause.
  2. Check `wp-config.php` constants such as `AUTOMATIC_UPDATER_DISABLED`, `WP_AUTO_UPDATE_CORE`, filesystem method/permissions, and Hostinger update controls.
  3. Confirm whether a security plugin, Hostinger setting, or version-control/deployment workflow intentionally disables updates.
  4. Re-enable at least minor/security core updates unless there is a documented alternative patch process.
- **Safe before posting tomorrow?** This does not affect the two sites Bert may post to tomorrow. For `bert.forsale`, apply only after backup confirmation; if the shop is not actively public, this is a good near-term maintenance task.
- **Rollback plan:** Record original constants/settings. If re-enabling causes failed update loops or file permission errors, revert the setting and use manual updates until hosting permissions are fixed.
- **Verification plan:**
  - Site Health background updates returns `good`.
  - WordPress can communicate with WordPress.org.
  - Public placeholder/site loads, admin loads, WooCommerce status page has no new critical errors.
- **Open-source/free tooling suggestions:** WordPress Site Health, WP-CLI `wp core check-update`, WP-CLI config inspection if shell access exists, Hostinger backup/restore.

## BF-02 — Rationalize ecommerce/plugin stack before public launch

- **Severity:** High before ecommerce launch; Medium while placeholder/maintenance page remains
- **Finding:** 23 plugins, 17 active. Ecommerce/marketing stack includes WooCommerce, PayPal Payments, WooCommerce.com Update Manager, Google for WooCommerce, Printful, Jetpack, Site Kit, WP Consent API, Hostinger AI, AI Provider for Google, and inactive Klaviyo/Pinterest.
- **Risk / benefit:**
  - Risk if ignored: Large attack surface, duplicated tracking/marketing integrations, checkout/privacy complexity, and maintenance overhead.
  - Benefit: Cleaner store launch, fewer privacy/payment regressions, clearer ownership of integrations.
- **Exact proposed action:**
  1. Define launch scope: products, payment, shipping/Printful, analytics, ads, email marketing, consent.
  2. Keep only integrations required for that launch scope.
  3. Confirm PayPal sandbox/live mode, WooCommerce status, webhooks, taxes/shipping, consent banner, privacy policy, and order emails.
  4. Remove inactive/unused commerce plugins after exporting settings.
- **Safe before posting tomorrow?** Not relevant to `berchman.com` / `bertmahoney.com` posting. For `bert.forsale`, do in staging or maintenance window.
- **Rollback plan:** Export WooCommerce/payment/shipping settings; change one integration at a time; restore from backup if checkout/payment breaks.
- **Verification plan:** WooCommerce status, test product, test checkout in sandbox, webhook logs, order email, public page speed, privacy/consent behavior.
- **Open-source/free tooling suggestions:** WooCommerce built-in status/logs, WP-CLI plugin list, Playwright checkout smoke tests, Uptime Kuma for availability monitoring.

## BF-03 — Prune inactive plugins

- **Severity:** Medium
- **Finding:** Inactive plugins: `Classic Editor`, `Hostinger Tools`, `Klaviyo`, `LiteSpeed Cache`, `Pinterest for WooCommerce`, `Quick Featured Images`.
- **Risk / benefit:**
  - Risk if ignored: Inactive plugin code remains installed and must be maintained; ecommerce add-ons can retain settings/data assumptions.
  - Benefit: Smaller attack surface and clearer launch stack.
- **Exact proposed action:**
  - Decide whether Klaviyo/Pinterest are part of launch marketing; if not, export settings and delete.
  - Confirm Hostinger Tools/LiteSpeed Cache are not required by hosting/cache setup before deletion.
  - Delete unused inactive plugins after backup.
- **Safe before posting tomorrow?** Not tied to tomorrow's posting, but still make changes only after backup/staging confirmation.
- **Rollback plan:** Reinstall plugin by slug/version; restore settings from export/backup.
- **Verification plan:** WooCommerce admin, checkout, analytics/marketing connections, media workflows, and maintenance page still behave as expected.
- **Open-source/free tooling suggestions:** WP-CLI, WooCommerce status logs, Query Monitor, Hostinger panel backup.

## BF-04 — Confirm maintenance/placeholder behavior and launch readiness

- **Severity:** Medium
- **Finding:** Public homepage appears static/placeholder "Back Shortly" while WordPress and WooCommerce stack exist behind it; `Maintenance Redirect` plugin is active.
- **Risk / benefit:**
  - Risk if ignored: Search engines/users may see placeholder unexpectedly, or launch may expose unfinished ecommerce pages.
  - Benefit: Controlled launch and predictable user experience.
- **Exact proposed action:**
  - Document intended public state: placeholder vs active store.
  - Confirm maintenance redirect rules, allowed users, HTTP status code, robots/meta behavior, and sitemap exposure.
  - Before launch, run full store smoke test and SEO/indexing check.
- **Safe before posting tomorrow?** Read-only verification is safe. Do not change redirect/maintenance behavior without explicit launch approval.
- **Rollback plan:** Re-enable maintenance mode/redirect if launch exposes broken pages; restore previous plugin settings.
- **Verification plan:** Incognito/public visit, logged-in visit, sitemap/robots, WooCommerce product/cart/checkout pages, Search Console if connected.
- **Open-source/free tooling suggestions:** `curl -I`, browser incognito, Lighthouse, Screaming Frog free mode, WooCommerce status.

## BF-05 — Review active `AI Provider for Google` and Hostinger AI coexistence

- **Severity:** Medium
- **Finding:** `AI Provider for Google` active version 1.1.0 and `Hostinger AI` active version 3.0.39.
- **Risk / benefit:**
  - Risk if ignored: Overlapping AI assistants/providers may add unnecessary admin endpoints, external data flows, or content-generation ambiguity.
  - Benefit: Clear, intentional AI tooling for product descriptions/content without privacy surprises.
- **Exact proposed action:**
  - Document which AI plugin is actually used.
  - Confirm no product/order/customer data is sent externally without consent/need.
  - Disable one provider later if redundant, after export and approval.
- **Safe before posting tomorrow?** Read-only only.
- **Rollback plan:** Export settings; reactivate/restore if editor/product workflows break.
- **Verification plan:** Product editor, post editor, WooCommerce admin, and public pages remain unaffected.
- **Open-source/free tooling suggestions:** WP-CLI plugin inventory, REST route inspection, plugin changelog/privacy-policy review.

## BF-06 — Review inactive Kiosko theme

- **Severity:** Low
- **Finding:** Active theme `storefront`; inactive theme `kiosko-theme`.
- **Risk / benefit:**
  - Risk if ignored: Small extra theme maintenance burden.
  - Benefit: Cleaner theme inventory.
- **Exact proposed action:** Keep `storefront` and one fallback if desired; delete/archive `kiosko-theme` if unused.
- **Safe before posting tomorrow?** Not related to tomorrow's posting; still defer deletion until backup.
- **Rollback plan:** Restore theme from backup if needed.
- **Verification plan:** Storefront remains active; shop pages render normally.
- **Open-source/free tooling suggestions:** WP-CLI theme list, backup ZIP, LocalWP staging.

---

## Suggested Maintenance Order

1. **Read-only now:** Capture Site Health details for Authorization header and `bert.forsale` background updates; verify backup availability; prepare exact Hostinger instructions.
2. **After tomorrow's posts:** Fix `berchman.com` malformed link; prune `bertmahoney.com` inactive themes; prune obvious inactive plugins one site at a time.
3. **Short maintenance window:** Add security headers, starting with one site, then roll out after verification.
4. **Before `bert.forsale` launch:** Fix background updates, rationalize ecommerce plugins, confirm maintenance/launch behavior, run checkout/privacy tests.
5. **Strategic:** Maintain WordPress 7 compatibility matrix and evaluate AI/connector APIs only on staging.

---

## Top 5 Recommended Actions

1. **Fix `bert.forsale` background updates disabled** after backup confirmation; it is the only critical Site Health item found.
2. **Investigate the Authorization header warning on all three sites** with Hostinger/LiteSpeed, starting with read-only diagnostics.
3. **Prune `bertmahoney.com` inactive themes** after tomorrow's post and backup; reduce 15 inactive themes to active `lei` plus at most one fallback.
4. **Fix the malformed `berchman.com` link** from `http://https//bert.forsale` to `https://bert.forsale/` after approval/backup.
5. **Document and review AI Provider for Google on all sites**, especially the new additions noted for `berchman.com` and `bert.forsale`, before relying on AI/connector workflows or WordPress 7 opportunities.