Context: This is a staging build, not a live site. Some findings below — like the placeholder title, missing meta description, and "block all crawlers" robots.txt — are expected for an under-construction site and just need to flip on at launch. They're flagged so they don't get forgotten.
B
An upgrade over the current site — still a lot of room for improvement
This is a meaningfully better foundation than the existing Wix site on most axes that matter. Page weight drops from 564 KB to 81 KB, the homepage has a real keyword-rich H1, the schema is more specific (AutoRepair instead of generic LocalBusiness), and 12 geo-targeted service-area pages have been built versus 3 on the current site. That said, WordPress itself has become a technically dated platform by modern standards. It's still the most-used CMS in the world, but "most used" is no longer the same as "best in class." And separately, even within WordPress, the rebuild hasn't yet addressed the most important issue raised by the Google Ads audit — campaign- and ad-group-specific landing pages built for the highest tier of Quality Score. The new site is a real step up, but there's significant ground left to cover.
PerformanceB+
Lighter than Wix, capped by WordPress itself
A real upgrade over the current site, but PHP-rendering plus a CMS architecture limits how far this can be pushed.
Homepage HTML is 81 KB — 7× lighter than the Wix site's 564 KB. Compresses to ~15 KB over gzip.
Only 2.5 KB of inline JavaScript in 4 small blocks (vs Wix's 332 KB across 65 blocks).
Real-world Core Web Vitals not yet measurable — site needs to be live before LCP/CLS/INP can be evaluated against Google's thresholds.
Performance ceiling is the platform. WordPress renders each page through PHP and a database query. A site built on a modern stack (React/Vite, Next.js, or Astro) typically ships 20–40 KB initial payloads with sub-1s LCP — measurably faster than what WordPress hits at its best. The headroom for "leading-edge fast" isn't reachable on this platform.
SEOB
Strong content foundation, metadata still placeholder
The on-page structure is excellent. Most of the gaps are placeholder text that just needs filling in before launch.
H1 is real and keyword-rich: "Your Diesel. Fixed Right The First Time." A massive upgrade from the existing site's "Welcome."
5 H2s + 21 H3s giving a proper content hierarchy on the homepage.
AutoRepair + GeoCoordinates + OpeningHoursSpecification + PostalAddress schema — more specific than the existing site's generic LocalBusiness schema. Better for local-pack ranking.
12 geo-targeted service-area pages already built: Van Alstyne, Sherman, Anna, Bonham, Celina, Denison, Durant OK, Gainesville, Melissa, Prosper, Whitesboro, Whitewright. The existing site has 3.
HSTS with includeSubDomains + preload — the strongest possible config. Stronger than the existing Wix site's HSTS.
Currently hosted on WordPress.com — Automattic patches the core/plugins automatically. Big positive while it lives here.
No WordPress version disclosure in the HTML (the generator meta tag is suppressed).
No X-Content-Type-Options, X-Frame-Options, CSP, or Referrer-Policy headers — modern XSS / clickjacking / referrer defenses missing.
WordPress is the single most-attacked platform on the web. Roughly 40% of all websites run it, which makes it the largest target by far. A WordPress site that isn't actively patched (core, themes, plugins) becomes a serious liability quickly. Most WordPress breaches in the wild come from out-of-date plugins, not WordPress itself.
wp-json REST API and xmlrpc.php are both reachable — typical WordPress attack surface. Brute-force amplification, user enumeration, and DDoS reflection are the most common vectors. Worth locking down or disabling.
If this ever migrates off WordPress.com to self-hosted without a monthly maintenance budget for updates and security monitoring, security drops a full letter grade. That's the platform's nature, not this build.
Quick numbersAt a glance
HTML weight
81 KB · 15 KB gzipped
Inline JS
2.5 KB · 4 blocks
TTFB
~75 ms
Service-area pages
12
Schema types
4
HSTS
Preload
H1
Real · keyword-rich
Status
Staging
Head-to-headNew site vs. current site
The same metrics from the existing-site audit, side by side with the new build. Almost every line moves in the right direction.
Metric
Current (Wix)
New (WordPress.com)
Verdict
Homepage HTML weight
564 KB
81 KB
7× lighter
Inline JavaScript
332 KB / 65 blocks
2.5 KB / 4 blocks
130× less
Homepage H1
"Welcome"
"Your Diesel. Fixed Right The First Time."
Much better
Schema type
LocalBusiness
AutoRepair (+ GeoCoordinates, Hours)
More specific
Geo / service-area pages
3
12
4× coverage
Service category pages
~5
5 (clean URLs)
Comparable
HSTS
1 year
1 year + preload + subdomains
Stronger
X-Content-Type-Options
Set
Not set
Wix wins here
Title tag
Custom, keyword-rich
Placeholder (staging URL)
Must fix before launch
Meta description
Custom, well-written
Missing
Must add before launch
Crawlable by Google
Yes
No (robots.txt blocks all)
Expected for staging
About the platform choiceWordPress is mature, not modern
Worth saying out loud, since the platform decision sits upstream of nearly everything in this audit. WordPress powers somewhere around 40% of the web — it's mature, well-documented, and supported by an enormous community. That popularity is exactly why it's also the single most-targeted platform for hackers. And while it's still very capable, the leading edge of the web has moved on.
What modern stacks look like. Most new business websites today are being built with component-based, build-time-rendered architectures — React, Node.js, and Vite as the underlying tools, and meta-frameworks like Astro, Next.js, or Remix on top of them. These produce static HTML at build time (sometimes called "JAMstack" sites), deployed to edge networks like Vercel, Netlify, or Cloudflare Pages. There's no PHP runtime, no database, no admin login, no plugins to patch.
What that means in practice. Faster pages (typical LCP under one second vs. WordPress's 2–4 seconds). Dramatically smaller attack surface (there's nothing to "hack" on a static site — just files behind a CDN). Easier to iterate on (changes happen in code with version control, not in a CMS admin that can be edited from any browser anywhere). And meaningfully better positioned for the next wave of traffic — AI agents like ChatGPT browsing, Perplexity, Google AI Overviews, and the increasing share of search that flows through them. AI crawlers reward fast, clean, statically-rendered content and de-prioritize slow JavaScript-heavy pages.
None of this is a "you have to replatform" message. The WordPress rebuild solves real problems and is a clear step up from Wix. But the ceiling on how fast, how secure, and how AI-ready this site can become is set by the platform itself. Several of the highest-leverage improvements available on the modern web — sub-1-second load times, near-zero security maintenance, true campaign-grade landing pages spun up in hours rather than days — aren't fully reachable inside WordPress. Worth knowing while there's still flexibility on which direction to invest in next.
Before you flip the switchPre-launch checklist
The items below are the "would-be-embarrassing-on-day-one" things from the audit. Each is a 5–15 minute fix in the WordPress admin.
Replace the title tag. Currently the staging URL. Should be something like "Texas Diesel Company · Diesel Repair in Van Alstyne, TX" or your preferred SEO formulation. Set in WordPress under Settings → General → Site Title/Tagline and via the SEO plugin if installed.
Write the homepage meta description. 150–160 characters, keyword-rich, written for humans. Currently missing entirely.
Fix the OG metadata. OG title and OG description are still WordPress defaults ("Visit the post for more."). Replace with the real social-share text, and upload a custom og:image — currently it's a WordPress-generated placeholder.
Switch robots.txt from "Disallow: /" to permissive. On WordPress.com: Settings → Reading → Search engine visibility. The current blanket block is correct for staging — but flipping it is the literal launch step.
Regenerate the sitemap. Jetpack's sitemap currently lists 11 URLs but the site has ~35 indexable pages. Service-area subpages and /services/* subpages are missing. Confirm they get indexed before launch announcement.
Add at least 3 missing geo pages. McKinney and Allen are the two highest-volume target markets per the Ads audit's bidding-signal data; Prosper is a high-affluence diesel-truck market. The template clearly works — just spin them up.
Decide on FAQ and Review schema. AutoRepair schema is already strong. Adding FAQ schema (one or two common questions per service page) and Review/AggregateRating schema (pulling from Google Business Profile reviews) unlocks rich-result eligibility.
Disable xmlrpc.php or rate-limit it. Not catastrophic on WordPress.com (Automattic mitigates platform-side) but cleanest to disable. The wp-json REST API should similarly be reviewed for whether anonymous user enumeration is possible.
Set up 301 redirects from the old Wix URLs. The existing site has links the new site doesn't — and the Google Ads audit shows several display paths still pointing at /txdc/service, /texas_diesel/home, etc. Map every public-facing URL on the old site to its new equivalent so nothing 404s on launch day.
Confirm Google Ads landing pages get updated. The Ads audit Section 00 lists which campaigns currently point at /, /services, and /diesel-repair-and-performance on the old domain. On launch day those need to be re-pointed to the equivalent URLs on the new site, or Quality Score resets badly.
In plain EnglishWhat this audit means for the rebuild
This is the right direction. The new site is dramatically lighter than the current Wix one, has real on-page content where it counts (H1, headings, schema), and has already done the strategic work of building 12 service-area pages. That's meaningful progress.
But it's not a finished story. The grade reflects "an upgrade, with a lot of room left to grow." The placeholder metadata can be cleaned up in an afternoon — those are easy wins. The harder, more strategic gap is that WordPress as a platform is mature but technically dated: slower under the hood than modern frameworks, more maintenance overhead, and a substantially larger attack surface. Those constraints don't go away by polishing the launch checklist; they're baked into the platform choice.
Connecting back to the Google Ads audit: the new site does make a step in the right direction for paid-ads landing pages. /services/diesel-repair-and-performance/, /service-area/sherman/, /service-area/van-alstyne/ are real improvements over the current site's single /services page. Re-pointing Ads Final URLs to these on launch day will help Quality Scores modestly.
However, the new site still isn't the answer to Section 00 of the Ads audit. The highest tier of Quality Score requires dedicated, campaign- and ad-group-specific landing pages — pages like /transmission-repair, /check-engine-light-diagnostics, /diesel-tuning, and dedicated geo pages for McKinney and Allen. None of those have been built into this rebuild. So while the new site is genuinely better than the old, it isn't yet a Quality-Score weapon for paid ads. To get there, dedicated campaign landing pages are the next investment — and those are significantly faster to spin up, more performant, more SEO-friendly, and more AI-crawler-friendly on a modern framework than they are inside WordPress.