Corporate website checklist: what to settle before you commission one

Before commissioning a corporate website, settle what job the site has to do, who will update its content and how, and who will own the domain, the code and the data. Languages, speed, accessibility, KVKK and cookie compliance, and responsibility for maintenance should all be written down before anyone talks about design. This checklist walks through the questions an organisation should answer internally before it asks for proposals.

How do you define the goal of a corporate website?

The most common mistake in a website project is to start with colours and sample sites. Design is the visual expression of a goal; if the goal is vague, the design stays open to debate and the project drags on through rounds of personal taste. The first meeting needs one simple question: once the site is live, which job will it do better than today?

For an association, that job might be winning new members and reducing questions about dues. For a journal or a congress, it might be letting authors and attendees find the submission rules in one go; for a small business, getting the right customer to fill in the quote form. The more concrete the goal, the easier it is to decide the page structure, the menu and the order of content.

Answering the questions below together inside the organisation prevents most of the disagreements that would otherwise surface later.

• Who will visit the site most often, and what information will they be looking for?
• Is there an action we want visitors to complete, such as an application, a registration, a contact form or a document download?
• Which questions are asked most often by phone or email today, and where on the site will their answers live?
• What will tell us the site is working: fewer repeated questions, more applications or a more orderly flow of information?
• Will the site only present the organisation, or will it work with a system for membership, payments or applications?

What should content management look like?

Over a corporate site's lifetime, most of the effort goes into content rather than design. Announcements, events, team changes, documents and FAQs are updated all the time. The content management panel therefore needs to be simple enough for a non-technical member of staff to use on their own.

The proposal should list exactly which areas can be edited from the panel. A setup where you can add news but have to email the agency every time the homepage sections, menus or footer change soon becomes a bottleneck for the organisation. Building pages from blocks, so that ready-made parts such as text, images, document lists and FAQs can be rearranged, gives flexibility without breaking the design.

Where several people enter content, roles and an approval flow matter too. Letting one unit prepare a draft while someone else approves publication, seeing who changed what and when, and being able to return to an earlier version all shorten the time incorrect information stays live on a corporate site.

What matters for a multilingual site?

For associations with international partners, academic journals, congresses and exporting companies, a second language is usually a necessity. The first decision is that every language has its own address. Setups where the language changes at the same address purely according to browser settings confuse visitors and make it harder for search engines to index the page in that language correctly.

The second decision is who translates and through what workflow. Machine translation can help with a draft, but terminology, titles and official names in institutional texts must be reviewed by a person. Entering the Turkish and foreign-language versions of each field side by side in the panel also makes it easy to see which pages still lack a translation.

The language switcher should take visitors to the same page in the other language, not back to the homepage. The language markup that tells search engines which pages are translations of each other should also be listed separately in the proposal; when it is added as an afterthought, every page usually has to be revisited.

Why should speed and infrastructure be discussed from day one?

A slow site loses visitors however well it is designed. On mobile connections in particular, oversized images, unnecessary scripts and fonts reloaded on every page spoil the first impression within seconds. Speed is not a later optimisation; it is an architectural decision.

At proposal stage, ask whether images are automatically resized and converted to modern formats, whether pages are rendered on the server and where the site will be hosted. The difference between a site on a crowded shared server and one with dedicated resources shows clearly at peak times, such as the last day of an application or registration period.

Speed also needs to be measurable. Asking for page load times to be measured on mobile and desktop before launch, and for those measurements to be part of the handover, turns a promise that the site will be fast into a concrete acceptance criterion.

How should accessibility and KVKK compliance be handled?

Accessibility means the site can also be used by people with visual, hearing, motor or cognitive differences. The international reference is WCAG, and corporate sites usually aim for level AA. Sufficient colour contrast, menus that work with a keyboard, alternative text for images and labelled form fields cost nothing extra when planned at design stage; added later, they mean rebuilding most components.

Every form that processes personal data needs to be assessed under KVKK. Asking only for information that is genuinely needed in contact, application and newsletter forms, keeping the privacy notice accessible next to the form, and, where explicit consent is required, collecting it separately and with a record, are the basic expectations. A cookie preference panel that gives visitors a real choice about non-essential cookies belongs here too.

These topics require legal assessment, and a web agency's proposal is no substitute for legal advice. The soundest approach is for the organisation to finalise the texts with its own legal adviser and to check current obligations against the official sources of the Personal Data Protection Authority. What you should expect from the agency is that these decisions are implemented correctly in technical terms.

A good corporate website is finished not on launch day but on the day the organisation can update it on its own.

Who should own maintenance, security and the site itself?

A live site is a running system that needs updates and monitoring. Unless security updates for software components, regular backups, certificate renewals and who responds to an outage, and how quickly, are written down, none of these tasks belongs to anyone until the first problem occurs.

Ownership, meanwhile, usually comes up only when the organisation wants to change agencies. Having the domain registered to the organisation rather than the agency, giving the organisation its own access to the admin panel and hosting account, and making the site's source files deliverable are preconditions for deciding freely later on. We recommend that the contract spells out the items below.

• The domain is registered to the organisation, and it is clear who is responsible for renewing it.
• The organisation holds at least one full-access account in the admin panel and access to the hosting environment.
• The site's source files and content data are delivered within a reasonable time on request.
• How often backups are taken, where they are stored and how restoring them is tested are written down.
• Response times for security updates and outages are defined.
• What maintenance covers and what counts as new work is explained with examples.

There are a few baseline expectations on security as well. Serving the site only over an encrypted connection, strong password rules and ideally two-step verification for the admin panel, limits on failed sign-in attempts and protection against automated spam on forms should all be standard for a corporate site. Personal panel accounts are far safer than one shared password passed between departments; when someone leaves, closing their account is all it takes.

The maintenance budget needs realistic thought too. The build fee is a one-off cost, but keeping the site secure and up to date takes effort over years. When comparing proposals, looking at the total cost over the first few years rather than the build fee alone makes it easier to spot offers that look cheap at first but price every small change separately.

Frequently asked questions

How do you choose between a ready-made theme and a custom design?

For a small organisation with little content and a purely promotional goal, a well-chosen ready-made theme can be enough. If the organisation has its own workflow, a multilingual structure or a connection to another system, solutions forced into a theme become more expensive over time. The choice should be driven by what the site has to do rather than by how it looks.

How long does it take to build a corporate website?

The biggest factor in the timeline is usually not the software but whether the content is ready. Projects run predictably in organisations that plan texts, images and approvals in advance. When you request proposals, ask for the schedule to state clearly at which steps it waits for content or approval from you.

Can we move the site to another company later?

Yes, if the domain is registered to the organisation, hosting access sits with the organisation and the contract covers delivery of source files and content data. If these points were not agreed at the start, a move can turn into an expensive job that goes as far as re-entering content by hand.

Is accessibility only required for public institutions?

No. The scope of obligations can vary by type of organisation, and the current position should be checked against official sources, but an accessible site is more usable for everyone. Clear headings, readable contrast and understandable forms make things easier for every visitor, with or without a disability.

How should you use this checklist?

Answering these questions internally before asking for proposals lets you compare offers against the same criteria and makes it clear what belongs in the contract. Most price differences are really differences in scope, and these questions make that visible. At Bir Web Ajans we build corporate websites together with their content management, language setup and maintenance plan, so that the organisation can run them on its own.