Technical SEO + implementation for indexing, speed, Cloudflare, migrations, and SEO command-center systems
I fix indexing, crawl, Core Web Vitals, Cloudflare, and migration issues across WordPress, Shopify, Laravel, Next.js, and mixed-stack environments. I also build SEO ops systems that turn audits, analytics, and task queues into a usable issue-to-fix workflow.
Clear scope. Implementation-first. Written verification.
Best fit
Best fit
Best fit: pages not indexing, traffic drops after launches, redirects or canonicals gone wrong, Core Web Vitals regressions, Cloudflare blocking valid traffic, broken crawl paths, or migration recovery work after site changes.
It also fits when SEO work is spread across audits, analytics, and task systems with no usable command-center layer to move issues from discovery into implementation and verification.
Where implementation shows up
These issues usually sit in templates, redirects, canonicals, cache behavior, Cloudflare rules, scripts, rendering paths, sync logic, or rollout mistakes. That is where the work starts.
Backend, app-layer, and SEO ops problems are handled when they are the bottleneck behind search, speed, launches, or issue-routing workflows.
What I usually fix
Service sprint
TTFB, LCP, INP, caching, CDN behavior, rendering bottlenecks, heavy scripts, and implementation-level speed issues.
Service sprint
Robots, sitemaps, canonicals, duplicates, noindex conflicts, crawl waste, internal linking paths, and GSC cleanup.
Service sprint
403 or 1020 errors, WAF rules, bot handling, SSL or DNS issues, cache behavior, origin communication, and crawl conflicts.
Service sprint
Redirect gaps, canonical mistakes, sitemap problems, rollout regressions, broken templates, and recovery after launches.
Service sprint
Multi-site SEO command centers connecting SEMrush, GSC, GA4, ClickUp, dashboards, sync layers, weekly SOPs, and execution-friendly issue routing.
Selected implementation notes
Case note
Built a live multi-site SEO command center across three sites, wiring SEMrush, GA4, GSC, ClickUp, Zapier, and Looker into one workflow with weekly SOP and handoff. The sync layer was later rebuilt on an API-based method so the live audit backlog stayed aligned with the actual crawl state.
Case note
Diagnosed traffic loss on a large content site by separating crawl waste, indexing selection, canonical conflicts, internal-link issues, and URL-level priorities. Only approved low-risk fixes were implemented, with clear notes on what was intentionally left alone.
Case note
Handled a defined WordPress technical SEO brief involving redirect imports, internal 404 cleanup, WP-CLI and database replacements, sitemap and canonical checks, and structured 404 or 5xx investigation with documented validation.
How work starts
Step 1
A short description, site URL, stack or CMS, what changed, and what looks broken.
Step 2
Clear scope, clear deliverable, and a verification path before implementation starts.
Step 3
The sprint is meant to move the actual bottleneck, not just expand the theory around it.
Step 4
What changed, what was verified, and what should happen next if more work is needed.
Platforms and stacks
Most projects still fall into the same lanes: indexing, speed, Cloudflare, migration, and SEO ops issues. The difference is where the fix lives when it is time to change something.
CMS & commerce
WordPress, WooCommerce, Shopify
Theme, plugin, template, redirect, and rollout issues that affect visibility or speed.
Edge & access
Cloudflare, cache, SSL/DNS
WAF rules, cache behavior, bot access, origin communication, and crawl conflicts.
App layer
Laravel, Next.js
Routing, rendering, middleware, deployment, and response-time issues where the app is the bottleneck.
Ops & reporting
SEMrush, GSC, GA4, ClickUp, Looker
Issue visibility, task routing, dashboards, and handoff systems that keep SEO work actionable.
Custom stacks
Implementation-first work across mixed environments
Best fit when search, speed, access, or migration problems cut across more than one layer.
Notes, fixes, and breakdowns
After a migration, this coverage state usually points to structural conflicts in templates, canonicals, internal links, or sitemap quality before it points to content quality.
Cloudflare 1020 is usually a rules problem, not a mysterious SEO penalty. The failure path tends to sit in WAF logic, bot handling, rate limits, or environment mismatches.
When TTFB jumps after a WordPress release, the real bottleneck is often split across PHP work, cache behavior, plugins, and edge configuration rather than one dramatic server failure.
Final CTA
Send the URL, what changed, and what looks wrong. If the issue is bounded enough, the first reply should suggest a clear sprint instead of a vague SEO package.