Techtweek Infotech — our own estate

Our own site ran on a long-lived WordPress install — Elementor, Contact Form 7, a tag-manager plugin and years of accumulated history. Search Console reported roughly 334,000 URLs not indexed against a site that is genuinely around 750 pages, and a 3.17 GB uploads backup was sitting in the web root, publicly downloadable over HTTP 200. We published this rather than quietly fixing it, because it is the exact shape of the estate most PHP modernisation clients bring us.

• 01Audited the WordPress database directly rather than trusting the crawl: 430 posts, 177 pages and around 140 custom post types published, with no live spam injection present
• 02Traced the 334,000 not-indexed URLs — 148,909 crawled-not-indexed and 107,446 404s — to historical hack and spam-injection residue that scanners still probe, not to a current compromise
• 03Removed the publicly downloadable 3.17 GB uploads archive from the web root and confirmed it now returns 404
• 04Froze the full WordPress content export — 503 entries — and rebuilt the front end as a Next.js application, so the PHP runtime carries no public traffic
• 05Rebuilt the sitemap from a maintained inventory rather than plugin output, and re-established canonical and robots metadata across the estate
• 06Put a post-deploy assertion in the pipeline that checks the live HTML for robots, canonical and title on every deploy, because the previous rebuild had silently stripped robots metadata with every build stage green

• Publicly exposed 3.17 GB uploads backup closed — the URL now returns 404
• 503 WordPress content entries migrated without loss; the PHP runtime no longer serves public traffic
• Sitemap reduced to 629 real, indexable URLs, down from plugin output that never matched the site
• The 334,000-URL not-indexed tail correctly identified as legacy residue that decays on its own, so remediation effort went to the pages that actually matter
• Metadata regressions now fail the deploy instead of shipping silently