Website maintenance and hosting RFP: the pack for ongoing site care

Scope this as the ongoing care of a website that already exists: hosting, uptime monitoring, backups, security patching, plugin and core software updates, SSL certificate renewal, and response to an outage or security incident. It is not a redesign, a rebuild, or new feature development; those are separate, priced work even if the same vendor does both.

Name the platform your site runs on, since a WordPress maintenance plan and a maintenance plan for a custom built site or a platform like Shopify involve different skills and different update cadences. If your site includes ecommerce, a booking system, or a membership area, say so, since those add points of failure a generic maintenance quote may not have priced in.

State the monthly or annual hours included, if any, for small content changes or fixes outside the core maintenance list, and what happens, and what it costs, once that allotment is used.

Give the vendor administrator access to your CMS and hosting control panel, but keep the hosting account and domain registration under your own login and billing, granting the vendor a delegated or collaborator role rather than full ownership. This lets you change maintenance vendors later without needing the outgoing vendor's cooperation to hand anything back.

Provide access to your DNS settings only if changes are part of the scoped work; day to day maintenance rarely needs DNS access, and limiting it reduces the risk of an accidental change taking your site or email offline.

Hand over a list of every plugin, theme, or third party integration currently active on the site, including anything a past developer installed and forgot about, so the vendor is maintaining the actual site, not a simplified version of it.

The domain, the hosting account, and every file and database that makes up your website are yours, under your own billing profile, from the day this contract starts. There should be nothing to transfer when the contract ends, because nothing should have moved into the vendor's name in the first place.

Ask directly whether backups taken during the contract belong to you and can be exported in a usable format, not locked inside a proprietary backup tool that only the outgoing vendor's account can restore from.

Require a written list of every login, API key, and integration the vendor created during the engagement, so a new vendor, or you, can find and rotate every credential when the relationship ends rather than discovering an old access point months later.

This is an ongoing service rather than a one time project, so the acceptance test is a working monthly rhythm rather than a single delivery date. Confirm within the first thirty days that backups are running on the stated schedule, that a test restore has actually been performed once, and that plugin updates are being applied on a staging copy before going live.

Set a written incident response commitment: a stated time to first acknowledge a reported outage, and a stated time to have the site back up for a routine issue versus a more serious one such as a hack. A vendor unwilling to put a number on either of these has not thought through their own process.

Require a short monthly report confirming what was updated, what was backed up, and any incidents handled, so the maintenance work stays visible instead of invisible until something breaks.

Weight bidders toward process over price: 25 percent for a specific, written incident response time, 25 percent for backup frequency, retention length, and whether test restores are part of the plan, 20 percent for their update process, especially whether staging is used before a live update, 15 percent for price, and 15 percent for references who can speak to an actual incident handled.

A proposal with no stated response time and no mention of a staging step is the more common failure pattern here; it usually means updates go straight to the live site and problems get discovered by your visitors before they get discovered by the vendor.

Ask each reference one direct question: has your site ever gone down under this vendor's care, and how long did it take to come back up.

Send these questions to every bidder and require a written reply before you compare proposals: What is your guaranteed response time for a fully down site? How often do you back up, how long do you retain backups, and have you tested a restore recently? Do you apply updates to a staging copy before the live site, or directly to production? Who owns the domain and hosting account under this arrangement, and can we move to a different vendor without your cooperation if we choose to?

Also ask what security monitoring, if any, runs between scheduled maintenance visits, since a hacked site is often discovered days after the fact on a maintenance plan with no active monitoring in between.