What to Consider When Building a Corporate Website

Is design enough on its own?

Visual design sets the first impression, but whether a visitor stays and gets in touch comes down to other things: how quickly the page opens on a phone, how many clicks it takes to find what they came for, and whether they found you in search at all.

So a website project is best treated not as two separate jobs but as one, with design and technical foundations planned together. Where a project runs on visuals alone, performance, page structure and search visibility tend to be left until last, and fixing them afterwards costs more.

Mobile use

On corporate sites a significant share of visits comes from phones. Mobile support is not just the layout narrowing: touch targets have to be large enough, the menu usable with one hand, the form fillable with the keyboard open, and tables must not overflow sideways.

A practical test is whether the site lets someone finish a real task on a narrow screen: can a visitor reach your service page from a phone and complete the contact form?

Speed and performance

Page speed is a measurable requirement that 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 itself but what gets loaded onto the page: unsized images, unnecessary scripts, a long list of external sources and fonts that arrive late. Settle these at the start of the project and speed does not become something to fix afterwards.

• Are images served at the right size and in current formats?
• Does the layout shift while fonts are loading?
• How many external sources (analytics, maps, chat, embeds) are added to the page?
• Is the main content visible without waiting for JavaScript?

What an SEO foundation actually means

"SEO-ready site" is often taken to mean filling in a few tags. What a search engine needs in order to find, understand and display a page is more concrete than that.

Page structure, metadata, canonical addresses, sitemap, structured data, performance and internal linking are set up before the site goes live. A sitemap added afterwards, or a heading structure corrected later, does not recover the time lost.

• A title and description unique to each page rather than repeated across the site
• One H1 per page that states the subject, with a sensible heading hierarchy beneath it
• Semantic HTML: content written with the right elements for headings, lists and tables
• Self-referencing canonical addresses
• A current sitemap covering the published pages
• Structured data (organisation details, breadcrumbs, articles where appropriate)
• Internal links built between pages by subject
• Descriptive alt text on images

How Google crawls and indexes pages

For a page to appear in search results it first has to be crawlable and then indexable. The technical details that block those two steps are often invisible: a misconfigured robots rule, a noindex tag left in place at launch, several addresses leading to the same content, or simply 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. Serving important text directly in the HTML is safer for search engines and for the other systems that read your content.

Nobody can guarantee a particular position in search results. What can be done is to make the site technically crawlable and understandable, and to write content that genuinely answers the questions people are asking.

Content architecture and service pages

The most common mistake on corporate sites is describing every service in a few paragraphs on a single "Services" page. That structure gives the visitor too little and stops each service appearing in its own searches.

The sound structure gives each service its own page: what it is, which problem it solves, what it covers, how the process runs and what happens next. Producing near-identical pages to raise the page count works against you.

Multilingual sites

If you also address audiences abroad, language support has to be planned from the start. Each language needs its own address, pages have to be declared as each other's counterparts, and the search engine has to be told which page belongs to which language.

A visitor switching language should land on the counterpart of the page they were on, not the home page. Publishing a half-finished language version harms both the visitor's experience and your search visibility.

Forms, conversion and measurement

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 all feed directly into that.

The technical side of the form matters too: submissions should be validated server-side, protected against unwanted traffic, and the user should clearly see the outcome. A form whose result is left ambiguous does not count as submitted.

On measurement, decide up front which actions will be tracked. Having analytics run only on cookie consent, and no measurement without it, also matters for legal compliance.

Security, maintainability and publishing

Even a presentation site has security requirements: all traffic over HTTPS, security headers defined, access to any admin interface restricted and the components in use kept current.

How updatable the content is is a separate decision. Which areas can be changed after launch (text, images, blog posts, team details) should be settled at the start; a structure that needs a developer for every change lets the site age.

Ownership on the domain, hosting and publishing side should be clear too: whose account holds the domain, where the site is published, whether backups are taken and who tracks certificate renewal.

Rebuilding an existing site

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 from the old address to the new one, the value that page had built up is lost.

So the first task in a rebuild 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 should keep its dates and addresses as it moves.

What scope to ask about when getting quotations

With the following written into a quotation, prices from different firms become comparable.

• How many pages, and which page types?
• Will the design be original or a template adapted?
• Who writes the content?
• Which languages are included, and who is responsible for translation?
• What does technical SEO cover here (metadata, sitemap, canonical, structured data, performance)?
• Which addresses move across from the existing site, and who sets up the redirects?
• Where do form submissions go, and how are they protected?
• Are analytics and cookie consent setup included?
• Which parts of the content will you be able to update yourselves after launch?
• Who is responsible for hosting, backups and certificate renewal?
• How are post-launch maintenance and support defined?

Conclusion

A corporate website is a visual front, but it is also a technical product with requirements for speed, accessibility, search visibility and security. Discussing those headings openly at the quotation stage shapes what you end up with.

If a new corporate site or a rebuild of your existing one is on the agenda, we can work out the scope and the addresses worth preserving together.

Frequently asked questions