I run a small e-commerce site doing about $400k/year and I'm starting to get acquisition interest. One buyer mentioned they'd run "technical due diligence" on the site. I have no idea what that involves for page speed and code quality. Do they just use Google PageSpeed Insights, or is there more to it? And what does checking code quality even mean for an online store? I'm not a developer, so I want to understand what they'll be looking at before I get blindsided.
How do online store buyers check my website page speed and code quality?
They'll run Lighthouse or PageSpeed Insights, but also look at Core Web Vitals from real user data, not just lab scores. For an online store, LCP and INP on product and checkout pages matter most. If your mobile LCP is over 4 seconds on product pages, that'll come up.
Code quality is a bigger can of worms. They might pull your theme or custom app code and look for hardcoded API keys, abandoned libraries, unminified assets, that kind of thing. If you've got a bunch of random apps installed, each one adds scripts and risk.
Depends on the buyer. Strategic buyers usually have an in-house def or agency do a review. Financial buyers might just run automated scans and move on. Either way, automated tools like GTmetrix and WebPageTest will be part of it.
Do they actually read the code though? I've always wondered if this is just a checkbox exercise for most buyers.
Not usually line by line, but but they'll look for obvious red flags. Duplicate app scripts, render-blocking JS in the header, huge unoptimized images. If your site scores 30 on mobi le PageSpeed, that's a negotiating point, not necessarily a dealbreaker. But if the codebase is a mess with no documentation, that scares off buyers who plan to scale.
They'll also check server response time and whether you're on shared hosting. TTFB over 600ms on a product page raises questions about infrastructure costs post-acquisition.
One thing people forget: third-party scripts. If you've got 15 tracking pixels and chat widgets loading on every page, that tanks speed and buyers notice. They'll count how many external requests fire before the page is interactive.
Also check if your images are served in WebP and properly sized. That's low-hanging fruit a buyer's dev will flag immediately. Same with whether you have a CDN in front of the site.
So basically I should spend the next montth cleaning all this up before talking to anyone?
Not necessarily. Buyers expect some technical debt in a small store. What kills deals is undisclosed problems, like a custom checkout that breaks on certain browsers or an app that's no longer maintained. Fix the obvious stUff and document what you have.
Honestly, a lot of this depends on your platform. Shopify vs WooCommerce vs custom build changes what they look at. On Shopify they can't see your backend code, so it's more about theme performance and app bloat. On Woo they can dig into the PHP and database queries. What are you running?
They might also use tools like BuiltWith to see your stack and then run a security scan.Code quality is partly about vulnerabilities, not just speed. Outdated plugins are a common finding.
Thanks, this is helpful context. I'm on WooCommerce with a custom theme someone built for me years ago, and I have no documentation for it. That might be a problem. I'll start with PageSpeed and see where I stand.
Custom theme with no docs and WooCommerce is exactly where they'll dig. Get a dev to at least write a basic readme and list dependencies before you hand over anything. Also run a backup before you start tweaking.