Technical SEO should end with a verified repair.
A crawler can say "improve page speed" or "fix crawl errors." I trace the symptom to the rule, request, template, or edge configuration causing it. Then I ship the approved fix and verify it in production. You work directly with me from the first diagnosis through repair.
The symptom is visible. The cause is not.
- Your audit says "reduce render-blocking resources" and nobody can tell you which resource, or who owns it
- The site got faster in Lighthouse and nothing moved in Search Console
- Some visitors see a broken page and others see a fine one, and no one can reproduce it
- Your redirects "work" through four hops before reaching the final URL
- You're paying for a CDN and nobody has opened the cache rules since it was switched on
- Your developer says it's an SEO problem, your SEO says it's a developer problem, and you're paying both
What the work covers
Edge & CDN configuration
Cloudflare Workers, Snippets, Transform Rules, Cache Rules, and WAF sit between your server and your visitor. Cache behavior matches how your site actually deploys. Purge automation keeps a release from serving stale assets, while header and redirect logic stays at the edge instead of being bolted into the application.
Core Web Vitals, diagnosed properly
Lab scores are a starting point, not the goal. The work traces LCP to the specific element and request that causes it, finds what's actually blocking the main thread, and eliminates layout shift at the source rather than chasing a number. Framed against field data where field data exists.
Crawl, indexation & redirect architecture
What Google can reach, what it chooses to index, and what it wastes budget on. Redirect chains collapsed to single hops, canonical and hreflang logic that holds up at scale, robots and sitemap directives that agree with each other, and legacy URL patterns retired without dropping the equity they carry.
Structured data & AI-search readiness
Schema built as a connected entity graph rather than disconnected blocks — augmented by @id, never redefined per page. Plus the things AI search actually reads: clean server-rendered HTML, an accurate llms.txt, and crawler access verified by request logs rather than assumed.
Three things that actually happened
Not case-study gloss. These are documented problems with documented fixes, including the parts that don't flatter me.
A CDN edge serving a stale file under a brand-new URL
A site update shipped and some visitors saw an unstyled page while others saw a perfect one. The stylesheet was cache-busted with a version string, so by every normal rule this was impossible — a new URL cannot be a stale cache hit.
It was. At least one Cloudflare PoP had cached an old stylesheet body under the new versioned URL, a race between the HTML and the asset going live during deploy. A 30-day max-age then pinned that bad copy for a month for every visitor routed through that edge. Post-deploy verification passed because it happened to hit a different, clean PoP — which is why it survived a check that should have caught it.
Diagnosis was a two-line comparison: fetch the versioned URL and a randomised one, compare cf-cache-status and payload. Versioned URL a HIT with stale bytes, random URL a MISS with correct bytes — the edge is poisoned, not the build. The fix was a never-reused timestamped version string, the asset TTL capped at one day with stale-while-revalidate, and a purge-on-deploy action so the edge can't outlive a release.
Why this one is here: it's a failure mode that looks like a code bug, survives ordinary verification, and is invisible to every SEO tool on the market. Diagnosing it requires knowing what a CDN does — not what a crawler reports.
A motion system that adds nothing to CLS
Animation is usually where layout stability goes to die. This site's motion system was built so nothing animates into reserved space: count-up figures pre-measure their final width, the audit panel ships its finished state in the HTML, and reveals are restricted to opacity and transform. The whole redesign added roughly 1.5 KB of JavaScript.
Read these honestly: mobile Lighthouse medians across three page types, multiple passes with the worst-LCP outlier dropped. They are lab measurements of a current state — not a before/after, and not field data. Lab numbers are a proxy; CrUX field data is what Page Experience actually uses. I'd rather show you a measured number with its limits attached than a percentage improvement I can't substantiate.
188 legacy URLs retired without losing the equity
A Drupal 9 site on Pantheon carrying years of accumulated URL patterns, competing language variants, and database-level URL regressions that reappeared after each fix. The work retired the legacy patterns, shipped hreflang that survived the CMS regenerating its own aliases, and resolved the regressions at the layer that caused them instead of patching the output.
How it works
Start with the health check
$500 flat. A written diagnosis establishes whether the problem is technical and what is worth fixing.
Diagnosis, with evidence
Each finding is tied to specific evidence, not a severity score from a crawler.
Scope the fix
I group fixes by effort so you can approve the work in a sensible order.
Implementation
I ship the approved fix and verify it in production. You get a written record of what changed. Book a build or rescue within 60 days and the full $500 comes off that work.
When I'm not the right fit
If your site is technically sound and your problem is that nobody links to you or your content is thinner than the competition's, technical SEO will not fix that. I'll tell you after the Health Check rather than sell you infrastructure work you do not need. A clean bill of technical health is a legitimate outcome, and you keep the report either way.
If you need enterprise-scale log-file analysis across millions of URLs, or a full-time in-house technical SEO, I'm the wrong shape of help. This works best for sites in the range where one person can hold the whole system in their head and act on it quickly.
If you need content strategy or link building, this is not the right service. I do not manage paid media here either. I stay on the technical layer.
Working in Kentucky specifically? The Kentucky SEO services page covers the same work with local market context. If you want the diagnostic first, start with the $500 Health Check. Agencies that need delivery under their own brand can use the white-label Technical SEO page.
Frequently asked questions
What counts as technical SEO?
Technical SEO decides whether search engines can render and understand a site after they reach it. It also affects how quickly real visitors can use the page. It covers crawl and indexation rules, redirects and canonicals, site architecture, Core Web Vitals, CDN and cache behavior, structured data, and the analytics that show what changed. When that layer is broken, better content cannot do its job.
Do you work on Cloudflare directly, or just make recommendations?
Directly, when implementation is in scope. Workers, Snippets, Transform Rules, Cache Rules, WAF, and purge automation can be part of the work. I make the approved change and verify it in production. I have also built production Workers with signed webhooks and KV state, not only cache rules.
How is this different from an SEO audit?
The $500 Health Check is the diagnosis. A technical SEO engagement carries approved fixes into production. If the Health Check finds infrastructure work worth doing, book a build or rescue within 60 days and the full $500 comes off that work. You can book the Health Check here.
My site scores well in PageSpeed Insights. Do I still need this?
Maybe not. A lab score of 95 is a good sign, but lab tests use one simulated device and connection. Google's Page Experience signals use CrUX field data from real visitors. If lab and field data disagree, that gap is the work.
Can you guarantee rankings?
No. Fixing the infrastructure removes reasons a page cannot rank. It cannot create demand or authority. Thin content still loses to stronger content. The diagnosis is evidence-backed, and I implement the approved fix. You also get a written record of what changed.
Find out if the problem is underneath the content.
$500 tells you what's actually wrong at the technical layer, in plain English, with the fixes tiered by effort so you can decide what's worth doing. The report is yours whether we work together after that or not.
Tell me what the site is doing.
Send the URL and tell me what's happening. I'll confirm fit and timing within one business day. If the problem is not technical, I'll say so before you spend anything.