Website Development
Website development at OMAV produces server-side rendered sites with a real content model, structured so that search engines and AI crawlers can read every word. Structure is enforced by the template rather than by editorial discipline, because the second kind decays.
A site that is readable by people and machines alike
A marketing site is an asset with two audiences that are usually treated as one. People need it to make the case quickly. Machines — search crawlers, AI crawlers, the systems that build answers — need to be able to reach it, parse it, and extract a complete statement from it.
Most rebuilds satisfy the first and neglect the second, not deliberately but because rendering and structure are decided by whichever framework was chosen rather than by what the site has to do. The result looks correct and is partially invisible.
We decide rendering per route, build heading and answer-block patterns into the templates, and generate structured data from the content model so that markup and page cannot silently diverge. Enquiry tracking is wired before launch, not after.
What a website engagement covers
Six workstreams. The content model is the one that determines the rest.
Content model
The fields and relationships each page type needs, so that structure is data rather than formatting an editor applies by hand and forgets to apply consistently.
Template patterns
Heading hierarchy, self-contained answer sections and schema built into each template, so a correctly structured page is the default output.
Rendering per route
Server-side rendering or static generation chosen per route against crawlability and freshness requirements, with the reasoning recorded.
Performance budget
Core Web Vitals measured per template with a budget enforced at build, because front-end performance regresses through ordinary content and feature work.
Editor experience
A CMS configured so that publishing cannot break the structure, with documentation that explains what to do rather than describing what we built.
Analytics and enquiry tracking
Tracking configured and verified before launch, including enquiry quality where the sales process can supply it, so the site can be judged on enquiries rather than sessions.
How a website engagement runs
Model the content
Page types, fields and relationships defined against the topic map, so the structure the strategy needs is expressible as data.
Build templates
Templates and components produced with heading patterns, answer blocks and schema built in, tested against real content rather than placeholder text.
Migrate and map URLs
Existing content migrated with a URL map and redirect plan, and a dated pre-launch performance baseline recorded.
Budget and verify
Performance budget wired into the build, tracking configured and verified, and crawlability confirmed from the HTML response.
Launch and hand over
Controlled launch with redirects monitored, then editor documentation and a walkthrough.
Platform approaches compared
Choosing on who edits and what must integrate.
| Dimension | WordPress | Headless CMS | Next.js + content backend |
|---|---|---|---|
| Editing experience | Familiar | Structured | Structured |
| Structural discipline | Depends on setup | Enforced by the model | Enforced by the model |
| Integration capability | Plugin-dependent | Good | Best |
| Operational burden | Updates and security | Two systems | Two systems |
| Right when | Small team, few integrations | Multiple channels | Performance and integration matter |
| Wrong when | Structure must be guaranteed | The team is one editor | Nobody can maintain a build |
What a new site will not fix
A rebuild does not improve a weak proposition. Where the constraint is what the business offers, or that the offer is not stated in terms a buyer recognises, a faster and better-structured site converts the same problem more measurably. That measurement is useful and it is not a solution, and we will say which one we think you have before quoting.
It also does not create demand. Where the questions your buyers ask have very low search volume, a technically excellent site will be found by the few people looking. That is a channel finding rather than a build finding, and it is cheaper to establish before the project than after it.
- Decide rendering per route; a framework default is not a decision.
- Structure belongs in the template, not in editorial discipline.
- Wire enquiry tracking before launch and judge the site on enquiries.
- A URL map and a dated baseline prevent most relaunch traffic losses.
Questions buyers ask about this
WordPress or a headless stack?
Decided on who edits, how often, and what has to integrate. WordPress is a perfectly good answer for a small editing team with few integrations, provided the structure is enforced by the theme rather than left to editors. Headless earns its extra operational burden when content feeds several channels or integration requirements are real.
Can you rebuild without losing our search positions?
Yes, with a URL map, a redirect plan and a dated pre-launch baseline. Most traffic losses at relaunch come from unmapped URLs and content quietly dropped during migration, and both are preventable. We record the baseline first so that any change after launch can actually be attributed.
Will the structure survive our editors?
That is what the content model and template patterns are for. Structure that depends on editors remembering a convention decays within months. Structure enforced by the template and checked at build does not, and the documentation we leave explains what to do rather than what we built.
How do you make the site readable by AI crawlers?
By ensuring content exists in the HTML response rather than only after JavaScript executes, by building self-contained answer sections into the templates, and by generating structured data from the content model so it matches the visible text. We verify the result from server logs and the raw response, not from a tool that infers it.
Do you maintain the site afterwards?
Yes, as managed support covering updates, monitoring, backups and a defined change allowance, with a written boundary between support and change. Or we hand over entirely if you have a team to run it — the documentation is written to make that viable either way.
Marked up as FAQPage structured data, matching the visible text exactly.
Still not sure this is the right service?
Answer four questions and we will tell you which one fits — or that none of them do.
Tell us what you are trying to fix.
A short conversation about the objective, the constraints and the timing. If we are not the right fit, we will say so.