The web readiness digest: bot rules, lean assets and MCP tools
Crawler access, asset loading and MCP design are converging on a practical rule: make useful content reachable without exposing more than necessary.
A fair ecommerce cost comparison counts the build, hosting, extensions, maintenance and payment fees—not just the launch quote.
Comparing custom PHP with WooCommerce on the initial quote alone misses the main cost question: what will it take to operate and change the store over three years? A flat-fee build can avoid recurring platform charges. It does not eliminate hosting, maintenance or future development. WooCommerce’s core software has no license charge, but a store may also rely on paid extensions and ongoing WordPress upkeep.
There is no responsible universal price comparison without a store specification and actual quotes. Product count, checkout requirements, integrations, content migration and support expectations all change the numbers. A useful comparison starts with the same requirements on both sides.
Put the costs into four buckets: initial implementation, recurring services, maintenance and change requests. Add payment processing separately, because transaction charges depend on the payment provider and sales volume rather than the choice between PHP and WooCommerce.
For recurring charges, use the actual billing period and renewal terms. A monthly service, an annual plugin subscription and a one-time purchase should not be treated as equivalent. Also note which costs are required to keep checkout running and which are optional conveniences.
WooCommerce is built on WordPress, and its core software does not require a license payment. The store’s total cost may still include hosting, backups, security work, paid extensions, and developer time for setup or troubleshooting. Some stores need few additions; others depend on several extensions for functions such as shipping rules, subscriptions or accounting connections. Those needs should be documented rather than assumed.
Recurring extension fees matter most when the store needs several of them or when subscriptions renew at different intervals. But the opposite can also be true: a small store may run with low recurring software costs. A buyer should ask which features require paid tools, what happens if a subscription lapses, and whether the store can be maintained by the team they already have.
Maintenance is not automatically expensive, but it is not automatically free. Updates, backups, compatibility checks and resolving errors take time, whether that work is done internally or by a contractor. A low hosting bill does not account for the labor needed to keep a commerce site dependable.
BuiltToWinWeb lists hand-coded custom websites, including ecommerce storefronts, for a flat fee and says the source code is handed over. That model can make the initial development charge easier to identify and avoid a monthly platform fee. It does not make the store cost-free after launch. Hosting, domain renewal, maintenance, payment processing and any new development still belong in the three-year budget.
Custom PHP may suit a business with specific requirements, a clear scope and access to a developer who can maintain the code. It can also suit an owner who values source-code ownership and wants to avoid a stack of platform subscriptions. Before signing, ask what is included in the build, what documentation and handover cover, who handles defects, and how later changes are estimated.
The tradeoff is that custom behavior has to be built and maintained for that site. A feature that comes from an existing WooCommerce extension may require bespoke development in a custom build. Conversely, custom code can avoid paying for an extension whose functions are unnecessary. Neither route guarantees lower total cost; the deciding factor is how closely the chosen setup matches the store’s actual needs.
Write down the required catalog, checkout, shipping, tax, integrations and reporting before requesting estimates. Ask each provider to separate launch work from ongoing work. For WooCommerce, list every paid extension or service and its renewal terms. For custom PHP, ask for a maintenance plan and an estimate for likely changes. Keep payment processing charges in a separate line so they do not distort the platform comparison.
Then calculate the same three-year horizon for both options. Include a realistic allowance for changes, such as adding a sales channel or revising fulfillment rules, but label estimates as estimates. If the requirements are uncertain, compare a basic case and a more demanding case rather than pretending one forecast is certain.
The central lesson in assessing ownership alongside a flat-fee build applies here: one-time development changes the shape of spending, not the need to budget for operations. WooCommerce can be economical when its existing tools fit and recurring costs stay modest. Custom PHP can be a better fit when the scope is well defined and platform charges or constraints are a poor match. The three-year total—not the label on the proposal—should decide.
Crawler access, asset loading and MCP design are converging on a practical rule: make useful content reachable without exposing more than necessary.
A self-hosted badge needs no JavaScript, but its meaning and dimensions should be explicit before it goes into a shared template.
Static discovery files suit stable information; live MCP endpoints make more sense when agents need current data or actions, at the cost of operational work.