Most "Python + SEO" content on dev.to assumes a clean environment: a VPS, Docker, root access, cron as a first-class citizen. That's not the reality for a huge chunk of small business sites. A lot of them are still WordPress on shared cPanel hosting — the kind of environment where you don't always get a shell, Python isn't installed by default, and "just spin up a container" isn't an option.
I recently came across a free SEO audit tool built on exactly that kind of stack — Python doing the actual crawling and scoring, embedded inside a WordPress site hosted on shared cPanel — and it's a more interesting engineering problem than it looks like on the surface. Here's the breakdown, from a dev's perspective rather than a marketing one.
Why this is harder than it sounds
On a normal VPS, an SEO crawler is trivial: requests/httpx + an HTML parser, maybe Playwright if you need JS rendering, wrap it in FastAPI, done.
Shared cPanel hosting changes the constraints:
- No persistent processes by default. Most shared plans don't want a long-lived server running. You're limited to cPanel's "Setup Python App" (a WSGI app under Passenger) or cron-triggered jobs.
- Outbound request limits and IP reputation. A shared hosting IP gets rate-limited or WAF-flagged by some target sites much faster than a clean cloud IP would.
- WordPress isn't just a data source, it's the host. If results need to render inside a WP page, Python and PHP have to talk without sharing a runtime.
- Memory ceilings. cPanel Python apps typically get a modest memory cap — a crawler doing headless-browser rendering would blow past that fast.
None of this is exotic. It's just the default reality of a large slice of the WordPress web, and almost nobody writes tooling for it — most SEO-automation tutorials quietly assume you've already left that world behind.
What the architecture is likely doing right
Based on how the tool behaves (fast turnaround on a handful of pages, structural checks rather than deep JS-rendered analysis, results surfaced directly inside a WordPress page), a few design choices stand out as sensible for this environment:
1. Isolated WSGI service instead of a WordPress plugin.
Running the crawler as its own Python process via cPanel's Passenger integration — rather than trying to execute Python from inside PHP — keeps the two runtimes cleanly separated. It also means the crawler isn't actually coupled to WordPress; WordPress is just the caller.
2. No headless browser in the critical path.
Most of what shows up in this kind of audit — missing meta descriptions, duplicate titles, missing alt text, broken internal links, robots.txt/sitemap issues, oversized images, missing canonicals — doesn't require rendering JavaScript. Skipping headless rendering avoids the memory ceiling problem entirely and is almost certainly why the audit finishes in under a minute instead of timing out.
3. HTTP as the boundary between WordPress and Python.
The alternative — PHP shelling out to a Python script directly — is fragile on shared hosting: open_basedir restrictions, unpredictable process limits, and silent failures that are miserable to debug. Treating the Python service as an external API that WordPress calls over HTTP is the more boring, more reliable choice, and boring is usually correct on infrastructure you don't fully control.
4. Scored output with visible breakdown.
The tool doesn't just return a single number — it splits results into layers (technical/structural, on-page/content, authority/strategy), which matters for credibility. A bare "74/100" with no explanation reads as marketing fluff even when the underlying analysis is legitimate; showing the components behind the score is what makes it read as an actual audit.
The takeaway for anyone building something similar
If you're building a crawler, auditor, or automation script that has to live on top of a WordPress/cPanel stack instead of beside it, the pattern worth copying is: keep the Python service stateless and HTTP-addressable, skip headless rendering unless you genuinely need rendered DOM, and treat WordPress strictly as a caller — never as the runtime for your Python code.
If you want to see the thing itself in action, [this is the tool I was looking at] — worth a look purely as a case study in shipping Python inside a constrained hosting environment, independent of what your own site's score comes back as.
Curious if anyone else here has shipped Python on shared cPanel hosting — what constraints did you hit that I didn't cover?
