The most common confusion in WordPress support conversations is the line between hosting and support. Hosting is the server: the machine that stores the site’s files and database and answers when a visitor’s browser asks for a page. A hosting company’s job typically ends at keeping that machine running.

Support is everything the machine cannot do for itself. WordPress ships updates on its own schedule, and so do the plugins and theme layered on top of it. Those updates sometimes conflict with each other. Forms stop sending. A plugin’s developer abandons it and a security hole opens. Content needs changing, a staff photo needs swapping, a page needs to exist by Thursday. None of that is the hosting company’s problem, and businesses often discover this at the worst possible moment: the site is technically online, the host’s status page shows green, and the checkout still does not work.

A site can have excellent hosting and no support at all. That combination describes many aging small-business sites: the server hums along while the software on it drifts further out of date each month.

Managed WordPress support plans tend to converge on a core set of tasks, because these are the tasks that prevent the most common failures.

Software updates come first. WordPress core, plugins, and themes each release fixes on their own schedules, and applying them promptly closes known security holes. A careful provider tests updates before or immediately after applying them, because an update that breaks a page layout is only marginally better than the vulnerability it patched.

Backups are the safety net under everything else. A working plan states how often backups run, where they are stored (a backup living only on the same server as the site disappears with the server), and how long they are retained. The overlooked half of this line item is restoration: a backup that has never been test-restored is a hope, not a plan.

Monitoring means the provider learns about a problem before the client does. Uptime monitoring catches the site going dark. Deeper monitoring can watch for file changes that signal a compromise, expiring domains and certificates, and forms that silently stop delivering.

Security response covers what happens when prevention fails: malware cleanup, spam-injection removal, and recovery to a clean backup. Plans differ on whether this work is included or billed separately, which is worth confirming in writing before it matters.

Many plans in this market also include a monthly allowance of content and small-change work: text edits, image swaps, new pages built from existing layouts. This is often the part of the plan a business actually feels month to month, and it is where allowances and rollover rules deserve a close read.

Scope disputes rarely start with the included list. They start with the assumed list: the things a client believed were covered because the plan was called “support.”

New development is the most common gap. A support plan generally maintains the site that exists. Designing a new section, building a custom feature, or integrating a new system is project work, quoted separately. The line can feel arbitrary from the outside (“it is all just changes to the website”), so a written scope that gives examples of each category prevents the argument.

Third-party services are another frequent gap. The email platform, the payment processor, the booking tool, the CRM connected to the site’s forms: support providers typically assist with the connection point on the WordPress side but do not administer the outside service. When a newsletter fails, the fix may sit with the email vendor, and a good provider says so plainly rather than billing hours against someone else’s outage.

Other common exclusions worth confirming: content writing (as opposed to content entry), performance rebuilds on sites with deep structural problems, licensing fees for premium plugins, and cleanup of problems that predate the agreement. None of these exclusions is unreasonable. What causes damage is discovering them during an emergency instead of reading them in the scope document.

Response expectations are where support plans differ most, and the differences hide in specific words. A plan may promise a response time (someone acknowledges the problem within a stated window) without promising a resolution time (the problem is fixed within a stated window). Both matter, and they are not the same commitment.

The useful questions are concrete. Who receives the report: a ticket queue, a shared inbox, a person with a name? What are the coverage hours, and what qualifies as an emergency outside them? A broken checkout on an e-commerce site and a typo on an About page should not sit in the same queue at the same priority, and a written plan typically defines severity levels for exactly this reason.

For a business owner or administrator, the honest test is to picture the specific failure that would hurt most, at the worst plausible time, and ask the provider to walk through what happens next, step by step. The quality of that answer, its specificity, tends to predict the quality of the eventual response.

Some support arrangements are real, and some are a recurring charge with a plan attached. A few observable signals separate them.

Silence is the first. A provider doing monthly updates, backups, and monitoring has something to report every month, even when the report is short. Months of billing with no report, no update log, and no record of work performed suggest the work may not be happening. Reports do not need to be long; they need to exist.

The second signal is version drift. WordPress displays its core, plugin, and theme versions in its own dashboard, so anyone with a login can check whether “we keep your site updated” matches reality. A site under active support should not show a long list of pending updates dated months back.

The third is the unverified backup. Asking a provider when the last backup ran, where it lives, and when a restore was last tested takes one email. Vague answers to those three questions are informative.

None of these checks requires technical skill, which is the point. A custodian who inherited the site can run all three in an afternoon and know substantially more about what the monthly fee is buying.

WordPress support in the Boston market is typically sold as a flat monthly fee, sometimes as a retainer of hours, occasionally as pay-per-incident. Flat fees suit sites that need steady, predictable care. Hourly retainers suit sites with irregular bursts of work. Per-incident billing tends to cost the least until the month it costs the most, because it removes the incentive for the preventive work that avoids incidents.

The number itself moves with a handful of factors. Site complexity is the largest: an e-commerce site with orders flowing through it carries more risk and more urgency than a brochure site, and is priced accordingly. Plugin count and quality matter, because every plugin is another update stream and another potential conflict. Response commitments cost money; a plan with defined emergency coverage prices differently from one with best-effort replies. Included content work, premium plugin licenses, and reporting depth each move the figure as well.

A higher fee is not automatically a better plan, and a lower one is not automatically a worse one. The comparison that matters is fee against written scope: what is included, what is excluded, who responds, and how fast.

That comparison is also available to anyone already paying for support. The current arrangement, whatever it is, can be set next to a written support scope line by line: updates, backups, monitoring, security response, response times, exclusions. Where the current plan has no written answer, that blank is the finding. See what a support plan from Boston Web Group actually covers for exactly this kind of comparison, and it costs nothing to look.