Person using a screwdriver to repair or open a laptop on a table.

Know what ongoing website care actually covers

Ongoing website care should come with a plan that tells you which tasks someone performs, how often, what they monitor, and what happens when a problem appears.

What needs regular attention?

“Maintenance included” is not enough to set expectations. A business needs to know who handles updates, backups, failed forms, content requests, hosting issues, and urgent recovery, and which of those tasks require a separate scope.

List the systems the site depends on: CMS, plugins, themes, hosting, forms, integrations, domain, analytics, and backups. Some need scheduled review. Others need a response when a change or alert occurs. Ask for an inventory of the site’s actual dependencies so the plan covers what is installed rather than a generic package description.

Clarify update work. Does the provider only install available updates, or also test the critical form and checkout after a change? Does the plan include a staging environment and a rollback path? WordPress’s auto-update guidance notes the importance of backups for recovery. The business still needs to define who verifies its specific visitor journeys.

What do backups and monitoring mean in practice?

Ask what is backed up, where copies are stored, how often a restore is tested, and who can start recovery. A backup notification is not evidence that every part of the site can be restored. If the site uses a payment, CRM, or email platform, identify which data those vendors hold separately.

For monitoring, ask which paths are checked and who receives alerts. Uptime alone will not detect a form that stopped sending inquiries. Define response hours and escalation honestly. If the plan does not provide immediate support outside business hours, it should say so in the agreement rather than imply it through vague language.

Are content changes and improvements included?

Separate routine content edits from new design or development work. Replacing an approved image or updating a service description may fit a recurring allowance. Creating a new service template, building an integration, or restructuring the catalog is a different project. Ask how requests are submitted, prioritized, approved, and tracked.

Reporting should answer business questions. A monthly document can show what changed, what failed, what was repaired, and what needs a decision. Traffic numbers without context do not explain whether the site remained useful. Decide who reviews the report and what action follows.

Who owns the accounts and the handoff?

The business should know who owns the domain, hosting, backups, CMS, analytics, and paid vendor accounts. Request an operating map and a route for access recovery. Do not accept a plan that makes the site impossible to maintain if one provider leaves. Clarify what documentation and exports are available at the end of an agreement.

Compare care proposals by responsibilities, not only the monthly line item. A low price can be appropriate for a simple site with a narrow scope. A store or member portal may require deeper testing and a faster response. The correct plan fits the consequence of failure.

Get included tasks and exclusions in writing.

Bring your site’s critical actions, current tools, and support expectations into the conversation. Ask for included tasks, exclusions, response route, and recovery method in writing. See website care plans for the related service path. Talk to a Specialist to define care around what your website actually needs.

Explore the site-operations guides.

Guides beside Know what ongoing website care actually covers.

  1. Define the website before you price the build

    Site operations · 4 min read

  2. Choose a CMS around the work your team does

    Site operations · 3 min read

  3. Use the smallest build that solves the real problem

    Site operations · 3 min read

  4. Map the handoff between tools before you automate it

    Site operations · 3 min read

  5. Check the dependency before it becomes invisible

    Site operations · 3 min read

  6. Plan checkout as a business process, not a button

    Site operations · 3 min read

  7. Give the product catalog a structure that can grow

    Site operations · 3 min read

  8. Decide the order rules before you configure checkout

    Site operations · 3 min read

  9. Make the return path clear before someone needs it

    Site operations · 3 min read

  10. Define access rules before the member dashboard

    Site operations · 3 min read

  11. Design the learning workflow before choosing the LMS

    Site operations · 3 min read

  12. Ask for what the appointment actually needs

    Site operations · 3 min read

  13. Make website leads usable inside the CRM

    Site operations · 3 min read

  14. Stop form spam without punishing real visitors

    Site operations · 3 min read

  15. Every automation needs an owner when it stops

    Site operations · 3 min read

  16. Give the chatbot a smaller, trustworthy job

    Site operations · 3 min read

  17. The handoff is part of the answer

    Site operations · 3 min read

  18. Name the action before you tag the button

    Site operations · 3 min read

  19. Test the conversion, not just the dashboard

    Site operations · 3 min read

  20. Make measurement follow the choice a visitor makes

    Site operations · 3 min read

  21. Spend page weight on things visitors can use

    Site operations · 3 min read

  22. Accessibility continues every time someone publishes

    Site operations · 3 min read

  23. Test the backup before you need it

    Site operations · 3 min read

  24. Update the plugin, then prove the journey still works

    Site operations · 3 min read

  25. An alert needs a person and a next action

    Site operations · 3 min read

  26. Keep the domain and its connected services in view

    Site operations · 3 min read

  27. Decide what to carry before you rebuild

    Site operations · 3 min read

  28. Give each old link a sensible destination

    Site operations · 3 min read

  29. Decide how to reverse a bad launch before launch day

    Site operations · 3 min read

No other guides in this group yet.

Back to top
Share to...