Straight answers about WordPress maintenance

Our plans start at ₹3,999 per month for Care (monitoring, tested backups, updates and a monthly security report), ₹7,999 for Performance (adds database and autoload optimization, object cache and edge cache tuning, bot and firewall policy, and email deliverability) and ₹17,999 for Managed (adds Cloudflare and CDN management, staging, unlimited small edits, a response SLA and a quarterly deep audit). Prices are per site, per month, and exclude 18% GST.

No. Every plan is month to month with no lock-in and no notice period. If you cancel at the end of a month we hand over every credential and rollback key. The quarterly report is what should make you stay, not a termination clause.

Yes. A disk bloat audit, a catalogue SEO pass or a malware clean-up can each be bought once, as a single measured pass with a before column and an after column. Most people start with the free health audit, then decide whether they want the one-off fix or the retainer.

Portfolios are quoted on the estate rather than per site, because a lot of the work is shared at account level — one hosting account, one Cloudflare zone, one set of monitoring rules. On the last disk audit we ran, the client's site was one of 26 domains on a single hosting account, and the biggest single win was an error log that sat above every site rather than inside one.

New feature builds, redesigns, custom plugin development and paid media management are quoted separately. Small edits are included on Managed; on Care and Performance they are billed hourly against an agreed estimate. Your Shopify or WordPress hosting, domain and any premium plugin licences stay in your name and are paid by you directly.

Six reads: database and autoload (option count, payload size, expired transients, orphaned rows), disk at account level (site size against account size, backup folders, error logs above public_html, cache residue), cache layers (object cache drop-in and its real backend, OPcache headroom, page cache, CDN rule order), cron and sessions, security surface (registration and login paths, bot rules, file integrity), and indexation (meta coverage, breadcrumb schema, h1 count, canonicals). You get the numbers whether or not you hire us.

Two to three working days from the time you send the URL. No call is required — most of what we read is visible from outside the site. Where we need hosting access to go deeper we will ask before we do it.

By what the measurement found, not by a checklist. A site that is slow on every page has a per-request problem, so we read the options table before touching the theme. A site that is fast when cached and slow when not has an object cache problem. Autoloader frames in the slow query log point at OPcache, not SQL. The audit tells us which layer is actually failing, and that decides the order.

No. Every destructive change carries a rollback key that is stored before the change is made, and every change is listed in the monthly record with that key against it. We never bulk-edit product names or homepage copy silently — that is your voice, so the deliverable is the list with the evidence attached, and you decide.

We re-crawl the same sample after the work and report the delta. Nothing is reported as fixed until that second crawl confirms it. On one catalogue pass the before-and-after was: pages with no meta description 85 to 0, meta descriptions over 160 characters 49 to 0, pages with more than one h1 10 to 0, and pages emitting no breadcrumb schema 183 to 2.

With the layer that is failing, not with a plugin. Slow on every page usually means the options table: on one WooCommerce store the autoload group was 276,000 rows read on every single request, cached or not, and we brought it to 1,796. Fast when cached but slow when not is the object cache. Autoloader frames in the slow log are OPcache. We read the evidence before installing anything.

No. Hosting is occasionally the answer but it is rarely the first one, and it is the most expensive thing to change. We look at the database, cache layers, cron, sessions and the CDN rule order first. On one server the actual fault was a MySQL buffer pool configured at five times available RAM, which was OOM-killing the database roughly every 40 minutes — a hosting upgrade would have hidden that, not fixed it.

Yes, using field data from CrUX rather than a lab score. A page-speed score is a symptom; the causes are usually elsewhere. Two we hit repeatedly: an image or carousel with both lazy loading and display:none never loads at all, which is why slides spin forever; and a free CDN plan that serves India out of Asia made one India-hosted site about 4.5 times slower than going direct.

Autoload is the group of WordPress options loaded on every single request, whether or not the page is cached. It is invisible in every plugin dashboard, which is exactly why it grows for years. It fills with expired transients, licence blobs and settings left behind by plugins that were removed long ago. On one store it had reached 276,000 rows; after the clean-up it was 1,796, a 99.3% reduction, and every uncached page load stopped hauling that dead payload.

Yes, and we will name the route in. Cleaning the payload is the easy half; if the entry path is still open the site is reinfected within a week. So every clean-up diffs core, theme and plugin files against known-good, scans the database for injected options and users, then closes and re-tests the hole. On one store the spam accounts were only half the job — the open registration path that produced them was closed in the same pass.

Carefully, because the usual bot rules break carts. A firewall rule that matches wc-ajax will block WooCommerce's cart fragment refresh and kill every add-to-cart on the site, so rules are tested against a real cart before they go live. We also avoid bad-bot plugins whose honeypot link is an uncacheable full-bootstrap URL — that amplifies the load it was installed to reduce.

Usually far more than owners expect. On one WooCommerce store the sessions table had grown to 329 MB, and 99.99% of it was crawlers hitting add-to-cart rather than customers. That is worth knowing before you pay for a bigger server to carry traffic that will never buy anything.

Yes, on every plan. Updates are staged first where a staging site exists, with a rollback point taken before each batch, and auto-updates stay enabled for security releases because the window between disclosure and patch is where sites get taken. If an update breaks something we roll back and tell you what happened rather than leaving it broken.

Not without a measured list and your decision on it. Clients read the total disk figure and reach straight for product photos, which is the one irreversible move. On the last audit, safe reclaim beat risky reclaim 79 to 1 — 505 MB at zero risk against 18.8 MB that needed a delete decision. And of 170 images an ID-only scan flagged as orphans, a filename sweep rescued 81 that were still live on the site.

Backups, not media. One site billed as a “15 GB website” turned out to be 6.7 GB of site and 22.9 GB of orphaned backup folders left by plugins that had been removed years earlier. The second biggest find is usually outside the site entirely — on one account a 274.58 MB error log sat above every public_html, unreachable by any site-level scan, and 54% of it was crash traces from a cache drop-in removed weeks before.

Yes, and it is safe because nothing is deleted blind. Option groups are exported with a rollback key before removal, then removed in batches with the site under load so a regression names itself immediately. The targets are expired transients, orphaned rows from uninstalled plugins, bloated session tables and revision build-up — not your content.

Only if you check the feature flag rather than the folder. A cache directory is live if its feature is switched on, and dead residue if it is not. On one site 98 MB sat in a caching plugin's own folder; reading three option keys showed avatar cache, UCSS and CCSS were all disabled, so none of it would ever be read again and it moved straight into the zero-risk tier.

Yes, and WooCommerce fails differently from plain WordPress. Sessions, HPOS order tables, facet and filter crawls, and cart fragments each have their own failure mode, and every one of them reads to the owner as the same symptom: the store is slow. A store checklist is not the same as a WordPress one.

The common causes are not the checkout page. A session table swollen by crawlers hitting add-to-cart, cart fragment requests that a firewall rule is blocking or that run uncached on every page, and filter or facet crawls that starve the PHP workers so real customers queue behind bots. We check how many PHP processes each domain is actually holding before touching the checkout template.

Yes, and we check it properly. A populated wp_wc_orders table proves nothing on its own — we read the newest row date, because a stale HPOS table looks fine in a dashboard while hiding weeks of recent orders from whatever is reading it.

Yes, as a catalogue SEO pass. On a 2,297-product store we found that zero of 261 category and brand pages had a meta description, 48% of products had none of their own, and no page emitted breadcrumb schema — none of which is visible in a plugin dashboard, which is why it had survived years of “we have an SEO plugin”. The tree repair is driven by Search Console clicks per slug: duplicates merge toward the URL that earns, never the one with more products.

Off-disk, with a restore tested on a schedule rather than assumed. A backup living on the same disk as the site is not a backup — if the disk or the account goes, both go together. The test restore is the part most plans skip, and it is the only thing that turns a backup into a recovery.

Only if it has been restored from. Backup plugins are also the single biggest source of disk bloat we find — on one site 22.9 GB of orphaned backup folders were left behind by plugins that had already been uninstalled. And All-in-One WP Migration excludes only its own directory, so its archive swallows every other backup folder on the site; clean the junk first and the archive typically halves.

Uptime and error-log monitoring is on every plan, so in most cases we know before you do. Managed carries a response SLA. On the other plans we work to restore during business hours, and because a rollback point exists before every change we make, the recovery path is usually a rollback rather than a rebuild.

The monthly record lists what was checked, what was changed and the rollback key for anything destructive. The quarterly report adds the numbers and the story: Search Console, Google Ads, Bing and Merchant Center where they apply, with a before column and an after column. It says what we did and what we do next — it is never a task list for you.

CTR against impressions, not clicks on their own. On one store, clicks were flat year on year while impressions were down 29% — which is a 39% CTR gain, and a very different story from “flat”. We also report crawl-error decline, because that proves earlier plumbing work paid off rather than just asserting it.

Yes. The free audit is real work, not a lead magnet, and if the numbers say your site is healthy we will tell you that and you will still have the figures. We would rather lose a sale than manufacture a problem — the whole argument of this business is that the numbers are checkable.

An administrator account on the site, and hosting panel access where the work needs it — disk and log work cannot be done from inside WordPress. We work through scoped credentials, keep a rollback key for every destructive change, and never delete the only copy of anything. You can revoke access at any time.

You do, throughout. Hosting, domain and plugin licences stay in your name and are paid by you directly. If you leave, you keep everything, and we hand over credentials and the rollback keys for every change we made.

Almost always, yes. Most of what we maintain we inherited, which is exactly why the first step is a measured audit rather than assumptions — the interesting problems are the ones the previous developer left behind, like plugin folders from software that is no longer installed, or a cache drop-in that was removed but is still writing crash traces.

Not unless you ask us to. Our case studies use Store A, Store B and Store C with a neutral descriptor, and the client testimonials on this site are Client A to Client J. We publish findings, never clients — no store name, domain or city appears in anything public.

Yes. The work is remote and the tooling is the same wherever the site is hosted. Pricing is quoted in rupees and billing is from Mumbai; for sites hosted outside India we will flag anything region-specific in the audit, such as a CDN plan that routes traffic through the wrong region.