Project · jennyselc.com.au · SEO & Performance

Action Plan & Client Decision Sheet

Based on the Digital Spotlight Action Item Summary tracker · Prepared 8 May 2026

1. Executive summary

The Digital Spotlight tracker covers three rolling audit rounds (Jun-24, Jan-25, Sep-25) across 19 issue categories. Most foundational SEO work is already complete — the remaining backlog is dominated by items waiting for client approval rather than engineering effort, plus a separate page-speed work-stream that has not yet started.

~360
Open line items
145
Blocked on client approval
9
Pages with low PageSpeed
~4 wks
Timeline (fast-approval path)
Headline finding. The site is not stuck on engineering — it’s stuck on decisions. 102 redirect approvals, 17 title tags, 22 meta descriptions, 4 duplicate-content rewrites, 7 server-error pages and 6 orphan pages are all sitting waiting for a yes/no from the client. Assuming the client turns approvals around quickly (target: 48 hours per batch), two-thirds of the backlog can be cleared inside the first fortnight and the whole tracker closed in ~4 weeks.

Where the open work sits

Tab Total Done Open Status of open items
Prioritisation & Tracking (master)352694 Implementation, 3 Rec In Progress, 2 Waiting Info
PageSpeed909All in Implementation — speed work not yet started
Crawl Errors (404s)381275106102 awaiting client approval, 4 awaiting info
Incorrect Internal Links2402112927 waiting info, 2 in implementation
Internal Server Errors (500)707All waiting client info on whether to keep
Title Tags271017All awaiting client approval
Meta Descriptions452322All awaiting client approval
Orphan Pages27216Waiting info
Redirect Issues (chains/loops)523Waiting access
Duplicate / Near-duplicate514Awaiting approval (copy already drafted)
Relevant Content (placeholder pages)404On hold — same pages now throwing 500s
Keywords (Old)16016All in Implementation
Remove Pages from Sitemap112112Status blank — needs verification pass
Keywords / Meta Robots / Non-indexable / H1 / Hidden Text2522520Done

2. Key issues, ranked by impact

High still open

  1. Mobile PageSpeed scores 45–73. No page is at “good” (90+). Worst: /childcare-centre-waurn-ponds/ at 45, /childcare-centre-grovedale/ at 49, /childcare-centre-armstrong-creek/ at 52, Lara and Maiden Gully at 56, homepage at 72, /programs/ at 73. Implementation owner currently shows as Jenny ELC, not Digital Spotlight — ownership needs to be confirmed.
  2. 106 live 404s. Mostly old http:// blog URLs from 2014–2018. 102 are waiting only on a yes/no on the proposed redirect target.
  3. 7 pages returning HTTP 500. All under /blogs/gallery/… (musical-program, head-start, summer-camp, kids-crafts, computer-skills, skill-building-games, contact-us). Each shows Lorem-ipsum placeholder content followed by a WordPress critical-error message. Decision needed: keep + fix + write content, or 301 redirect.
  4. Internal linking still broken in 29 places. Mostly http:// → https://, old blog paths, and uppercase URLs.

Medium still open

  1. Sitemap hygiene. 112 URLs flagged for removal from sitemap_index.xml. The sitemap was regenerated in Nov-2025 (master row 17 marked Fixed) but the line-item list was never zeroed out — needs a verification pass.
  2. 17 title tags + 22 meta descriptions waiting on client approval. Copy already drafted in the sheet.
  3. 4 duplicate / near-duplicate gallery pages (kids ↔ activities, daycare ↔ education). Replacement copy already drafted.
  4. 3 redirect chains/loops on blog tag URLs — multiple 301 hops. Fixable in .htaccess or redirect plugin.
  5. 6 orphan pages — decision needed: link in or redirect out.
  6. 16 “Keywords (Old)” tweaks — pre-written title / H1 / body copy improvements for Lara, Armstrong Creek, Grovedale, Maiden Gully, Waurn Ponds, The Arch Ballarat and the homepage.

Already done — no action

Robots.txt, root sitemap regeneration, JS-rendering issue, uppercase → lowercase redirects, meta-robots tags, non-indexable pages, H1 issues, hidden text, keyword targeting on the original four target pages.

3. Why the site is slow — root-cause reading

The PageSpeed tab only links to the per-URL web.dev reports without listing causes. Combined with the rest of the audit history, this is what 45–73 mobile on a WordPress childcare site almost always points to:

Likely causeEvidence in the tracker
Render-blocking JS / heavy client-side renderingMaster row 15 (now Fixed): “site not fully accessible without Javascript.” Even after SSR/prerender was added, residual heavy JS bundles are typical on this kind of site.
Unoptimised hero images, no modern formats (WebP/AVIF)Centre pages (Waurn Ponds 45, Grovedale 49) are image-heavy gallery pages — classic LCP killer.
No CDN / page-cache layer in front of WordPressNot mentioned anywhere in the tracker; default WP hosting tends to give a high mobile TTFB.
Excessive redirect chains adding latency3 open chain/loop cases plus historical /blog/ → /blogs/ rewrites.
Third-party scripts (analytics, chat, embeds)Standard WP marketing-site pattern. Not enumerated in the file — needs a fresh Lighthouse run to confirm.
Many 404s = wasted requests + broken assets106 still-live 404s; some likely referenced from internal links or theme assets.
Theme / plugin instabilityWP critical-error 500s on 7 pages strongly suggest a misbehaving plugin or theme template (see callout below).
New finding — the 7 gallery 500s are a partial-render fatal, not a hard outage. On reinspection, the seven /blogs/gallery/… pages return HTTP 500 but the body content still renders. This is the classic signature of a PHP fatal thrown in a late hook (footer, sidebar widget, or shutdown) after WordPress has already flushed the main content to the browser. The server logs the fatal and stamps a 500 status, but the visitor sees a page that “looks fine.” Implication: this is a single underlying conflict — almost certainly one plugin or one template part — affecting all 7 pages, not 7 separate bugs. Fixing it is a 2–4 hour diagnostic job, not a content rewrite. See Q2 below for the diagnostic plan.
Important caveat. The audit file does not contain Lighthouse traces — only links to pagespeed.web.dev. To give a confirmed root-cause list we should run a fresh Lighthouse pass on the 9 slow URLs before committing to a Wave 3 scope.

4. Proposed plan & timeline

Four waves so quick wins ship while the bigger pieces are scoped properly. Timeline below assumes the client returns approvals within ~48 hours of each batch — with that cadence, total elapsed time is around 4 weeks rather than the conservative 6.

Wave 1 — Approvals sprint

Days 1–3 · ~6 client hours · unlocks ~145 items

Deliverable: every “Waiting For Approval / Data” row gets a written decision logged.

Wave 2 — Implementation sprint

Week 1–2 · ~25–35 dev hours

Wave 3 — Performance sprint

Weeks 2–3 · ~40–60 dev hours · runs in parallel with Wave 2

This is where mobile PageSpeed should move from 45–73 to 85+. Recommended order, biggest wins first:

  1. Image pipeline. Convert centre/gallery imagery to WebP, enforce width/height, lazy-load below-the-fold, generate responsive srcset. Biggest single LCP win.
  2. Caching + CDN. Install full-page cache (WP Rocket or LiteSpeed Cache) and front with Cloudflare. Cuts mobile TTFB dramatically.
  3. Render-blocking. Defer non-critical JS, inline critical CSS, remove unused CSS, audit theme for legacy jQuery/sliders.
  4. Font loading. font-display: swap, self-host or preconnect to Google Fonts, subset.
  5. Plugin audit. Disable unused plugins; the 500s on /blogs/gallery/… strongly suggest a misbehaving plugin.
  6. Third-party scripts. Defer or conditionally load analytics, chat widgets, social embeds.
  7. Re-run PageSpeed on each of the 9 URLs and lock in scores.

Wave 4 — Verify & close

Week 4 · ~5 hours

Total honest timeline

~4 weeks elapsed on the fast-approval path (target: client returns each batch within 48 hours). If approvals stretch to a week per batch, this becomes ~6 weeks. Approval cadence is the single dominant risk — engineering capacity is not the bottleneck.

WeekWhat shipsClient effortDev effort
Week 1Wave 1 workshop & approvals captured · bulk 404 → 301 redirects live · titles & metas applied · gallery-500 root cause identified~6 hrs~15 hrs
Week 2Gallery-500 fix deployed · 16 keyword tweaks live · redirect chains resolved · internal links updated · sitemap reconciled · Wave 3 image & cache work begins~2 hrs~25 hrs
Week 3CDN + page cache live · render-blocking JS/CSS deferred · font loading fixed · plugin audit closed · PageSpeed re-run on all 9 URLs~1 hr~25 hrs
Week 4Digital Spotlight verification crawl · tracker closed · post-launch monitoring report~1 hr (sign-off)~5 hrs

5. Client decision sheet — questions we need answered

Twelve questions, grouped. Each one unblocks a specific batch of items. Print or fill in directly.

Fail-forward policy — we don’t wait. So the project can start on time even if the client is busy, every question below has an assumed default. If we don’t receive a written answer by EOD Mon 11 May 2026, we will proceed with the default shown under each question and log it in the change record. The client can override any default at any later point — we’ll roll the change in at the next release. The only items that genuinely block us are the access requests in Section 6: those are flagged with a red BLOCKER banner on the relevant question.
Q1 · Unblocks 102 itemsHigh priority
Do you approve the bulk 301-redirect plan for the 102 historical 404 URLs?
These are predominantly old http:// blog/news URLs from 2014–2018 (e.g. /butterfly-room-news-june-2014/, /charlotte-reads-the-weather-23052014/, /about-us/our-team/). Digital Spotlight has proposed a redirect target for each.
DefaultOption A. We will apply the DS-proposed redirect target where one exists; for any 404 without a proposed target we will 301 it to the homepage. Each redirect is reversible — the client can override any individual mapping later.
Decision:
Q2 · Unblocks 7 itemsHigh priority — revised
The 7 gallery pages return HTTP 500 but the content is still rendering. We’ll diagnose and fix the underlying conflict — can you confirm the pages should stay live, and grant us access to the WP dashboard, hosting error logs and the staging environment?
Affected URLs:
  • /blogs/gallery/musical-program/
  • /blogs/gallery/head-start-program/
  • /blogs/gallery/contact-us/
  • /blogs/gallery/summer-camp-program/
  • /blogs/gallery/skill-building-games/
  • /blogs/gallery/computer-skills-program/
  • /blogs/gallery/kids-crafts-program/
Why this changed. The original tracker treated these as broken pages needing replacement content. On reinspection the body HTML is still being delivered — the 500 is being thrown by a PHP fatal in a late hook (footer / sidebar / shutdown). That makes this a plugin-or-template conflict affecting all 7 pages from one root cause, not 7 separate content problems. Fix once, all 7 recover.

Our diagnostic plan (~2–4 hours, before any content work)

  1. Enable WP_DEBUG_LOG + WP_DEBUG_DISPLAY=false on staging; reload one of the 7 URLs and capture the exact fatal from wp-content/debug.log.
  2. Cross-reference with the hosting error_log for stack-trace and PHP version.
  3. Compare a working /blogs/gallery/… sibling (if any) with a failing one to isolate the difference (custom field, template part, embedded shortcode).
  4. Bisect plugins (Health Check “Troubleshooting Mode”) on staging until the 500 stops — identifies the offending plugin.
  5. Switch to a default theme briefly to confirm whether the conflict is plugin-side or theme-side.
  6. Apply targeted fix — usually one of: update/replace the offending plugin, patch the theme template, or remove the legacy widget that fires in the late hook.
  7. Verify all 7 URLs return 200 + content; re-run Screaming Frog to confirm.

Most likely root causes based on the symptom (content renders, then 500):

DefaultOption A. Keep the pages, fix the underlying conflict so they return HTTP 200, and leave the existing placeholder copy in place. Replacing the Lorem-ipsum copy is not blocking and can be scheduled separately whenever the client provides program content.
BlockerAccess still required. We can’t start the diagnostic without WP admin login, hosting error-log access (cPanel or SSH), and either an existing staging URL or permission to clone production to staging. See Section 6.
Decision:
Q3 · Unblocks 17 items
Do you approve the 17 drafted Title Tag rewrites?
Digital Spotlight has already written replacement title tags (e.g. for centre pages and the homepage). Approving in bulk lets us push them all in a single content-edit pass.
DefaultOption A. Apply all 17 DS-drafted title tags as-is. Yoast/Rank Math entries are reversible from the WP dashboard, so the client can override any title later with no code change.
Decision:
Q4 · Unblocks 22 items
Do you approve the 22 drafted Meta Description rewrites?
Same as Q3 but for meta descriptions. These directly affect click-through from Google search results.
DefaultOption A. Apply all 22 DS-drafted meta descriptions as-is. Same dashboard reversal path as Q3 — no code change needed if the client wants to amend later.
Decision:
Q5 · Unblocks 4 items
Do you approve the drafted unique-content rewrites for the 4 near-duplicate gallery pages?
Affected pairs: /blogs/gallery-category/kids/ ↔ /…/activities/ and /blogs/gallery-category/daycare/ ↔ /…/education/. Digital Spotlight has already drafted ~200-word unique paragraphs for each.
DefaultOption A. Apply DS’ drafted unique copy on all four gallery-category pages. Page deletion (Option C) is destructive so we won’t pick that one without explicit approval.
Decision:
Q6 · Unblocks 6 items
For the 6 orphan pages (no internal links pointing to them), do you want them linked in or redirected out?
Orphan pages don’t receive internal link equity, so they rarely rank. We need a per-page decision — keep and link, or kill and redirect.
DefaultOption B. Apply the rule for each of the 6 orphans — pages with substantive content get an internal link from a parent nav page; pages that are thin or duplicate get 301’d to the closest live equivalent. We’ll log the decision per URL so the client can flip any of them later.
Decision:
Q7 · Unblocks 16 items
Do you approve the 16 drafted on-page copy tweaks for centre pages (Keywords — Old tab)?
Pre-written title, H1 and body-text edits to weave in target keywords (childcare, long day care, kindergarten, preschool) for Lara, Armstrong Creek, Grovedale, Maiden Gully, Waurn Ponds, The Arch Ballarat and the homepage.
DefaultOption A. Apply all 16 DS-drafted title / H1 / body tweaks for the centre pages and homepage. Easily reverted in WP if the client wants different wording later.
Decision:
Q8 · Unblocks 3 items
Can you grant us hosting / WordPress admin access to fix the 3 redirect chains and loops?
The Redirect Issues tab status is currently “Waiting For Access.” We need cPanel / SFTP / or a WP admin account with redirect-plugin permission.
BlockerNo safe default. If access is not granted by EOD Mon 11 May, we cannot apply redirect-chain fixes ourselves. Our fallback is Option B — we ship a written spec with exact .htaccess rules and the client’s in-house dev applies them. The 3 redirect-chain items stay open in the tracker until the spec is implemented.
Decision:
Q9 · Scope & ownershipHigh priority
Who owns the 9 PageSpeed implementation items — us or Digital Spotlight?
The PageSpeed tab lists the implementation owner as “Jenny’s Early Learning Centre,” not Digital Spotlight. Most other tabs name DS as the owner. We need this resolved before we scope Wave 3.
DefaultOption A + C hybrid. We take ownership and start the speed work; Digital Spotlight verifies the results in their week-4 re-crawl. This matches the implementation owner shown for the existing 9 PageSpeed rows in the tracker. The client can reassign to DS at any time before Sprint W3 begins (Tue 26 May) without losing time.
Decision:
Q10 · Targets
What mobile PageSpeed score should we aim for?
Hitting 90+ on a content-heavy WordPress site is achievable but expensive (~40–60 dev hours). 85+ is the practical sweet spot. Anything below 50 is failing.
DefaultOption A. Target 85+ mobile across all 9 audited URLs. Sprint W3 is scoped to this target. If the client decides to push to 90+ later, that’s an additive scope, not a rework — we’d add an iteration pass on top.
Decision:
Q11 · Sitemap
Can we treat the 112 sitemap-removal rows as already resolved by the Nov-2025 sitemap regeneration?
Master row 17 was marked Fixed in Nov-2025 (sitemap_index.xml regenerated and resubmitted), but the 112-row line list was never zeroed out in the tracker. We’ll do a verification crawl, but we need the green light to retire those rows en masse if the crawl confirms they’re gone.
DefaultOption A. We re-crawl the sitemap, confirm each of the 112 listed URLs is no longer present, and close those rows in bulk. Any URL that does reappear is excluded and flagged for individual review — no destructive action.
Decision:
Q12 · Logistics
Who is the single point of contact for approvals, and what cadence works?
A single decision-maker (or a delegated approver) and a weekly check-in is the difference between this finishing in 6 weeks and dragging into Q4.
DefaultOption B. We default to async email approvals on a 48-hour SLA, with all status updates posted in a shared status doc. If we don’t hear back on a specific approval, the fail-forward defaults in Q1–Q11 still apply, so the project keeps moving.
Approver name & cadence:

Fail-forward summary — what we will do if no response by EOD Mon 11 May 2026

QTopicDefault actionReversible?
Q1102 × 404 redirectsApply DS-proposed targets; un-mapped 404s default to homepageYes
Q27 × gallery 500sDiagnose & fix the conflict; keep pages live with existing placeholder copyYes
Q317 × title tagsApply DS-drafted titles in bulkYes
Q422 × meta descriptionsApply DS-drafted metas in bulkYes
Q54 × duplicate gallery pagesApply DS-drafted unique copy on each (no deletion)Yes
Q66 × orphan pagesPer-page rule: substantive content gets linked from a parent nav page; thin pages 301 to closest live equivalentYes
Q716 × keyword copy tweaksApply DS-drafted edits in bulkYes
Q8Hosting access for 3 redirect chainsNo safe default. Without access we deliver a written .htaccess spec; client’s in-house dev applies. 3 items stay open until done.
Q9PageSpeed ownershipWe own the speed work; DS verifies in their week-4 re-crawlYes
Q10PageSpeed target85+ mobile across all 9 URLsYes
Q11112 sitemap rowsVerify and close in bulk; any URL that re-appears is excludedYes
Q12Approval cadenceAsync email, 48-hr SLA, fail-forward on no-responseYes
Reversibility note. Every default except Q8 (which simply can’t happen without access) is reversible from the WP dashboard or by deploying a single config change — no destructive action and no data loss. The client can override any individual default at any later point; we’ll roll the change in at the next release.

6. Access & inputs we need from the client

ItemWhyStatus
WordPress admin login (Editor + Redirect plugin permission)To apply the title / meta / body / redirect changesNeeded
Hosting / cPanel or SFTP accessTo fix 500 errors, edit .htaccess, audit theme & pluginsBlocking 3 redirect items
Google Search Console accessTo resubmit sitemap, monitor coverage and 404s post-fixNeeded
Google Analytics / GA4 access (read-only)To prioritise fixes by traffic and confirm conversion-rate impactNeeded
Brand / content sign-off contactFor copy approvals (titles, metas, gallery rewrites)Needed (see Q12)
List of plugins currently active in WPTo diagnose the WordPress critical errors on /blogs/gallery/… pagesNeeded

7. Recommended next step

Schedule a 60–90 minute Wave 1 workshop in week 1 to walk the 12 questions above and capture decisions live. Once those are logged, we lock the Wave 2 and Wave 3 scopes and commit dates against them. In parallel, we run a fresh Lighthouse pass on the 9 slow URLs so the Wave 3 scope is grounded in current data, not the 2024–2025 audit baseline.