WORKFLOW
How the work gets done.
From the first plan to the next improvement, the same checks apply. This document shows how a page is delivered, how an edit becomes a reviewed release, how the site is looked after, and what you receive if you ever move on.
Read the thinking behind these choicesDelivery workflow
Carry the same standard through every stage.
The homepage is one entry point. A service page, article, or location page may be the first thing someone finds. Every public page intended for search needs a defined purpose and the same technical attention.
We establish common page standards in the templates, then review the content and configuration of each page. A shared template provides a foundation; it does not replace page-specific judgment.
Business questions lead to a page plan, content and design, development, release checks, publication, and a review that informs the next update.
- Plan and design
- Identify the visitor's question, connect the page to related information, organize approved content under descriptive headings, and define a useful next step.
- Build and review
- Deliver readable HTML, configure page metadata and search controls, check mobile and keyboard use, and validate the published result.
- Maintain
- Apply the same standards to new pages. Investigate issues after changes and use available search and usage evidence to decide what needs attention.
Each new page joins a maintained system.
Content updates
Publish changes through a reviewed release.
Static delivery still supports regular publishing. Approved edits can come through source files or a separately scoped headless CMS integration. The published site serves the generated result.
An update passes through a build and review before release. A failed build should leave the current release available; recovery uses a known version and a check of any connected services.
An approved source or CMS edit produces a build and preview. Checks either return the change for correction or allow a release. A post-release issue can trigger restoration of a known version.
- Editorial input
- The client supplies or approves the domain content. A CMS, when included in scope, gives editors an interface for frequent updates while templates maintain the page structure.
- Preview checks
- Review content, links, metadata, applicable schema, mobile layout, and interactions. Changed URLs need redirect and canonical checks.
- Recovery boundaries
- A website rollback restores the website release. It does not reverse a payment, CMS edit, or other external service operation; those have separate recovery procedures.
An edit becomes a checked release, with a defined way back.
Ongoing care
Turn observations into deliberate improvements.
Maintenance covers page availability, broken links, stale information, search access, and changes to the experience. The available tools and permissions determine what can be observed directly.
We distinguish a fault that needs correction from a new feature or a research hypothesis. Improvements pass through the same review and release process as the original work.
Checks and available reports reveal an issue. Diagnosis leads to a scoped correction or proposal, a reviewed release, and a verification that feeds the next round of checks.
- Detect and diagnose
- Check the page and affected service, identify the actual cause, and record what needs to change. Search Console and available usage reports can inform the investigation.
- Make the appropriate change
- Maintain existing functionality within the agreed care scope. Assess larger changes separately so the owner, cost, and business purpose stay clear.
- Verify and learn
- Recheck the published page and connected workflow. Watch available evidence for the effect of the change, and retain findings that improve future decisions.
A maintained website has a continuing cycle of checking, deciding, and verifying.
Handover & costs
Make the website understandable to its next owner.
Source code is one part of a handover. An experienced developer also needs build and deployment instructions, the content model, service dependencies, and a clear account and access plan.
Static files can move to a suitable host. A migration still needs domain, redirect, canonical, form, and service checks. External platforms have their own terms and portability limits.
Source code, build instructions, content and assets, service and account information, and URL rules form a handover. A successor deploys to a suitable environment and checks the public pages and integrations.
- Technical handover
- Provide source, dependency and build information, deployment instructions, the content structure, and the configuration needed to operate the website.
- Accounts and dependencies
- Identify domain, hosting, CMS, and service ownership. Arrange appropriate access transfer; keep secrets out of public documentation and source bundles.
- Separate the costs
- Domain renewal, hosting usage, external services, and SiteMonk's subscription are different costs. Static delivery can reduce runtime maintenance; actual fees depend on selected services and usage.
Portability needs code, operational information, and a checked transition.