Discovery and scope
Audience, the pages required, languages and the addresses to preserve from the existing site.
We treat a corporate website not as a visual storefront alone, but as a technical product with requirements for speed, mobile use, accessibility, search visibility and security. We take on both new builds and rebuilds of existing sites.
A corporate site is often the first contact anyone has with a business. It is where a visitor works out what the service is, which problem it solves and who they would be working with.
What shapes that judgement is not design alone: how quickly the page opens on a phone, how many steps it takes to find what they came for, and whether the site appears in search results at all count just as much.
When design and technical foundations are planned as two separate jobs, performance, page structure and search visibility tend to be left until last. Fixing them afterwards costs more in both time and budget.
So we run the project as one piece of work: page structure, content hierarchy, image weight, metadata and the publishing setup are decided alongside the design.
The design is built to be consistent with your existing brand assets and to keep the content readable.
A significant share of visits to corporate sites comes from phones, and mobile support is more than the layout narrowing.
Page speed is a measurable requirement and it affects both the visitor's experience and search visibility. Google assesses page experience using loading, interaction and visual stability metrics.
What determines performance is usually not the design but what gets loaded onto the page: unsized images, unnecessary scripts, a long list of external sources and fonts that arrive late. We settle those at the start of the project.
We report measurement results as they actually are. We do not guarantee a particular score, because the outcome depends on the visitor's device and connection.
Page structure, metadata, canonical addresses, sitemap, performance and internal linking are set up before the site goes live.
For a page to appear in search results it first has to be crawlable and then indexable. What blocks that is often invisible: a wrong robots rule, a noindex tag left in place at launch, several addresses leading to the same content, or no internal link pointing to the page at all.
Loading the main content only after scripts have run in the browser is a risky choice too. We serve important text directly in the HTML.
Nobody can guarantee a particular position in search results. What we do is make the site technically crawlable and understandable, and shape the content so it answers the questions people are actually asking.
Describing every service in a few paragraphs on one page gives the visitor too little and stops each service appearing in its own searches.
We give each service its own page: what it is, which business problem it solves, what it covers, how the process runs and what happens next. We do not produce near-identical pages to raise the page count.
If you also address audiences abroad, language support is planned from the start; a half-finished language version added later harms both visitors and search visibility.
The real goal of a corporate site is not visit numbers but the number of qualified people who get in touch. Where the form sits, how many fields it asks for and whether its error messages make sense feed directly into that.
On the technical side, submissions are validated server-side, protected against unwanted traffic, and the user sees the outcome clearly. A form whose result is left ambiguous does not count as submitted.
On measurement, which actions are tracked is decided at the start. Analytics runs only on cookie consent; nothing is measured without it.
Even a presentation site has security requirements, and how updatable the content is is a separate decision.
The biggest risk in rebuilding a live site is losing the search visibility it already has. Where a page's address changes and no redirect is defined, the value that page had built up is lost.
So the first task is to list the existing addresses and indexed pages. Strong pages keep their addresses where possible; where they cannot, they are redirected in a single step to the closest new page on the same subject. Existing blog content keeps its dates and addresses as it moves.
Ownership on the publishing side should be clear: whose account holds the domain, where the site is published, whether backups are taken and who tracks certificate renewal.
Building and publishing the site statically gives a smaller attack surface and more predictable performance than a dynamic installation. We decide which approach fits together, based on how often the content changes.
Audience, the pages required, languages and the addresses to preserve from the existing site.
Page structure, menu layout and which question each page answers.
Page templates true to your corporate identity, with mobile layouts worked out alongside.
Pages built, with metadata, canonical, sitemap, structured data and performance set up.
Mobile, speed, form and link checks, then launch together with the redirects.
The budget follows from the page count, whether the design is original or a template adapted, the number of languages, who writes the content, how many addresses move across from the existing site and the scope of post-launch maintenance.
Our guide on what to consider when building a corporate website sets out the questions worth asking when you request a quotation.
If the goal is to present the company and its services and to publish information, a website is the right choice. If you need a system where people sign in, create records, approve work or run the daily operation, our web application development page is the better fit.
Crawling and indexing new pages takes time and the duration cannot be guaranteed. Submitting the sitemap, making pages reachable through internal links and publishing original content all help. We do not commit to a position or a date.
We preserve strong, indexed addresses wherever possible. Where an address has to change, we define a permanent single-step redirect from the old address to the new one.
Which areas are editable after launch is agreed at the start of the project, and a manageable structure is set up for the sections that change often.
We can, if it is agreed in the scope. For the technical accuracy of service pages we prefer to work the content out together with your team.
Talk us through which pages you need, which languages you will publish in and which addresses from your existing site have to be preserved.