A site is not a business card. It is your hardest-working employee.

Most conversations about a new website start with how it should look. That is understandable and it is the wrong order. A site is a tool: it has to do something. Bring in enquiries, get appointments booked, sell products, attract applicants, prevent phone calls. Whoever has that goal clear knows immediately which pages are needed, which copy matters and where the button belongs.

Plaincodelab therefore starts with three questions. Who comes to the site and with what question in mind? What does that person have to do before it is worth anything to you? And how will you know later whether that worked? The answer to that last question is nearly always countable: enquiries per month, appointments booked, orders, or simply fewer emails asking things the site could have answered.

From that goal the rest follows almost by itself. An installer who mainly wants quote requests needs a site that quickly makes clear which area they cover and keeps the request form within two taps. A hair salon that wants a full diary needs a booking button that travels along on every page. A wholesaler who wants fewer phone calls mostly needs good product information and a clear terms page.

What you do not need is more often worth discussing than what you do. A blog nobody keeps up, a newsletter without a plan, a photo gallery that never gets filled, a chat window nobody answers: it costs money to build and it costs credibility when it stays empty. Better five pages that hold up than twenty that are half finished.

That sharpness also saves money. A defined goal means a defined quote, which means you do not have to choose halfway through between paying extra or shipping something unfinished. Plaincodelab therefore writes that goal in one sentence at the top of the proposal and tests every page conceived afterwards against that same sentence.

The word website covers four very different things. They differ in price and above all in what becomes possible later. Choose the wrong form and you pay for it later in a rebuild that costs more than starting over.

A one-pager is exactly that: everything stacked on a single screen. Quick to build, cheap, and fine for a new initiative, an event or a service that explains itself in three paragraphs. The limit is findability: Google can rank one page well for one topic, so anyone who wants to be found for five services will not get far.

The company site is the most common form and the reason is simple: every service and every location gets its own page, and every page can be found on its own. Add a contact page, usually an about page, often news or cases, and an admin where you edit copy yourself. This is the form that grows with you without the setup getting in the way.

A web shop adds products, payments, shipping, stock and returns. That is not an add-on but a second system: the administration around it takes more attention than the site itself. For anyone selling dozens to hundreds of items that investment is worth it; for someone selling four, a simple order button with a payment link can be enough.

The web application is the fourth form and does not really belong in this list, except that people call it a website too. It is a closed environment where people log in and work: a client portal, a planning system, a case file. It does not need to be findable, it needs to work. It often sits next to the ordinary site and shares the same data.

Building a website is not an art piece but a series of steps that must happen in order. Plaincodelab works in short rounds with something visible at the end of each, so you are not left in the dark and changes stay cheap. The schedule itself is agreed once the commission is confirmed, before the build starts.

It starts with discovery: what you do, for whom, what makes you different and what people search for. That last question is not a side note. The words customers use are rarely the words of the industry, and the site should speak the customer's language. This step ends with a page plan: which pages there will be and what each page must do.

Then comes the copy, the step that decides the most and is underestimated the most. Design without copy is decoration; copy without design still sells. Plaincodelab writes with you or works from what you supply, but does not build on placeholder text — then at delivery the beautiful headline turns out not to match what you actually want to say.

After that the design, first for the phone and only then for the large screen. More than half your visitors arrive on a phone; design it the other way round and you end up squeezing a wide layout into a narrow screen. You get it as a clickable prototype, not as a picture.

Then the build, with a test environment you can follow live, followed by filling it with real content, and a checking round: speed, screen sizes, forms, error pages, accessibility and the technical basis for findability. Only when that holds does the site go live, with redirects from old addresses so you do not throw away your existing positions in Google.

After launch comes a period of watching and adjusting. Real use always reveals something you had not anticipated: a form that is too long, a text that raises questions, a page that draws far more traffic than expected. That adjusting belongs to the delivery, not to the next project.

Website prices vary widely, and that difference rarely lies in the looks. It lies in how much is made bespoke, how many pages genuinely have to be written, whether integrations are added and how many people are deciding.

Roughly: a simple site of a few pages on an existing template is the cheapest route and is often exactly enough for a freelancer starting out. A company site with its own design, ten to twenty pages, an admin and a technical base set up for findability sits clearly above that. A shop or a site with integrations into existing systems sits above that again, because alongside the site you are setting up a process.

What pushes the price up: every page that must be written rather than supplied, multiple languages, integrations with accounting or stock, a design that differs on every screen, and coordination with several parties. What brings it down: a clear page plan up front, copy and imagery ready on time, one decision-maker, and starting with the pages that matter now instead of everything at once.

Alongside the build sit the fixed costs. A domain name costs little, hosting depends on what runs, and maintenance is not a luxury: components get updated, backups checked, forms tested and security holes closed. Budget for that even if a third party built your site — a neglected site is the most common cause of hacked sites in smaller businesses.

Finally a warning about the very cheapest route. Sites offered for a small monthly amount are usually rental: you keep paying, you cannot leave, and what you build is not yours. That can be a fine choice if you need something fast, but know what you are buying. A site should be yours: domain and hosting in your own company's name, and content you can take with you.

Findability is not a trick you stick onto a site afterwards. It is the sum of three things: can a search engine read your site, is there anything useful on it, and do others think so too. Everything sold as a secret falls under one of those three.

The technical part is the least exciting and gets sorted first. Every page has one clear title and description, one h1, a readable address, and a canonical reference to itself so duplicate addresses do not compete. The site loads fast, works on a phone, has a sitemap and a robots file, and supplies structured data so search engines understand what a page describes: a business, a service, a product, a question with an answer.

The content part is the real work. One page per topic, with the visitor's question as the starting point and an answer complete enough that they need not look elsewhere. That means longer pages than most agencies deliver, with subheadings that repeat the question the way people ask it. Anyone who wants to be found for ten services needs ten good pages — not one services page with ten paragraphs.

Local is a separate track and for many businesses the most important one. Name, address and phone number identical on your site, in your Google business profile and in the directories you appear in. A page per town or service area, with copy that is genuinely about that place and not the same paragraph with a different town name in it. Ask for reviews and reply to them. Keep opening hours up to date, including around holidays.

What does not work: stuffing copy with keywords, buying links, a hundred near-identical location pages, and chasing rankings without checking whether anyone clicks and calls. What does work is dull and takes longer: pages that genuinely answer the question, a site that is fast, and enough patience to measure what happens before overhauling everything.

A growing share of people no longer search in a list of blue links but ask a language model, or a search engine that summarises an answer itself. That changes what a site has to do: not only rank, but be cited. In practice less changes than it seems, but what does change is worth the effort.

Models like to cite pages that answer one question completely, in clear language, with facts that can be checked. They like a clear structure: a heading that poses the question, an answer of a few sentences beneath it, and then the nuance. They do not like marketing language without substance, because there is nothing to extract. That is exactly why this site reads the way it does.

Practically that means: put questions and answers on the page where they belong and mark them up as question and answer in the structured data. Name concrete numbers, terms and conditions instead of 'sharp prices' and 'short lead times'. Repeat the key facts in ordinary sentences rather than only in a table or an image, because imagery is not read along. Keep business details identical everywhere so a model does not have to choose which version is right.

It also helps to receive machines hospitably. Do not block AI providers' crawlers if you want to appear in their answers. Put up an llms.txt file with a short, factual summary of who you are and what you offer. Make sure your site is readable without JavaScript, because not every reader executes scripts. That last one, incidentally, is also good for ordinary search engines and for visitors on a slow connection.

And be honest about the limits: nobody can guarantee a model will name you, just as nobody can guarantee a first place in Google. What you can do is be the source that is easiest to cite — clear, complete and verifiable. That is the same investment that convinces people too.

Speed is the part visitors talk about least and react to hardest. A page that opens slowly loses people before they have read anything, and that happens above all on a phone with poor reception — exactly the visitor who is in a hurry. Google measures that experience too, so speed touches both your visitors and your position.

What makes a site slow is nearly always the same list: oversized images, too many third-party scripts, fonts that load late, and a system that recalculates every page while nothing has changed. Plaincodelab therefore builds with pre-rendered pages where possible, compresses imagery into modern formats, loads only what is needed and keeps the number of external parties small.

That last point is a privacy matter too. Every external script — a chat widget, a video player, an ad pixel, a font from another server — is a third party watching along and slowing your site down. For most sites: the fewer, the better. What you genuinely need is loaded in a way that does not hold up the page.

At the back end the choice makes little visible difference as long as the result is fast and secure. Plaincodelab picks the technology per project: widely supported tools that fit what the site has to do, rather than pushing every project into the same shape. Where the site runs is your own choice; for Dutch and European companies a server inside the EU is the obvious one. More important than the brand of technology is that another developer can take it over: no home-grown inventions, but documented choices.

Measurement belongs with it, otherwise speed is an opinion. After launch, real visitors on real devices are observed: how quickly the first screen appears, whether anything shifts during loading, and how quickly the site responds to a tap. Those are the three things Google weighs and your visitor feels.

A site may look good, but the first job of design is guidance. Where am I, what can I do here, and what is the next step. If a visitor has to think about that, something went wrong — however handsome it looks.

That starts at the top of every page. Within seconds it must be clear what you do, for whom and what the visitor can do now. Not with a slogan that could apply to anyone, but with a sentence that is only about you. Below that the story can unfold calmly, with subheadings you can scan, because most people do not read top to bottom but jump.

Mobile first is not fashion but arithmetic. More than half your traffic arrives on a phone, often standing in a shop, in a car or on the sofa with one hand. Buttons should be big enough, forms short, phone numbers tappable, and the important thing within thumb's reach. Design for the wide screen first and you leave the majority of your visitors eating leftovers.

Accessibility runs right through this and is more than a checkbox. Enough contrast between text and background, text that can scale without the layout breaking, form fields with real labels, images with a description, and a site fully operable by keyboard. For government-related organisations that is a legal requirement, and with the European accessibility directive it now applies to many shops and service providers too. Beyond that: it makes your site nicer for everyone.

Finally trust. People do not buy from a site that feels anonymous. A real address, a real phone number, real photos of real people, clear terms and reviews that are not too good to be true. That convinces more than any animation effect, and it costs less.

A site you cannot update yourself grows old. Opening hours no longer match, an old price stays put, and after a while nobody dares change anything. That is why every site comes with an admin environment in which an ordinary colleague finds their way easily.

There are roughly three routes. The first is a well-known system such as WordPress: widely used, many ready-made extensions, many people who can work with it. The price is maintenance — plug-ins and core must stay updated, and a neglected installation is the most common reason sites get hacked.

The second is a system where the content sits apart from the site itself, so pages can be pre-rendered at high speed and the same content can also feed an app or a screen in the shop. For companies who want to grow with their site that is often the most comfortable route: fast, secure and without the clutter of dozens of extensions. Which of the three it becomes depends on what you want to do yourself and how much has to be bespoke.

The third is a hosted package you pay for monthly. Quick to set up, few worries, but you are tied to what the package can do and you take little with you when you leave. For a simple site that can be perfectly fine; for a site that has to do something particular you will hit the ceiling sooner or later.

Whichever route it becomes, the requirements stay the same. You can change copy, photos and prices yourself without calling a developer. There is a test environment or a preview, so you can look at something before it goes live. There are roles, so an intern cannot accidentally delete the home page. And there are backups that can actually be restored — a backup never tested is a pile of hope.

A web shop is not a site with a basket bolted on. It is a sales channel with administration underneath, and that administration decides whether the work pays off or pays off plus headaches. The site is the easy part.

It starts with the products themselves. Good photos, real descriptions, sizes and specifications, and variants that are correct. A shop with three hundred items has that work three hundred times, and it is the line item quotes systematically underestimate. If you have a product file you can import; if not, someone has to write.

Then fulfilment: payment by iDEAL, credit card, Bancontact or pay-later, shipping costs that differ per country and weight, parcel labels, returns and the statutory fourteen-day cooling-off period. A customer expects a confirmation, a shipping notice and a clear returns policy. Those are not extras, they are baseline expectations — and largely legally required.

Stock is next. If you also sell in a shop or through a marketplace, you want one stock level that is correct everywhere instead of three lists drifting apart. That is an integration with your point-of-sale or stock system, and it is usually the hardest technical part of the whole project.

Finally findability and selling power. Every product page deserves its own unique copy — the supplier's text sits on a hundred other sites and earns you nothing. Category pages deserve a real introduction. And nearly half your revenue hangs on details that have nothing to do with technology: clear shipping costs before the last step, a visible phone number, and a checkout that does not demand an account before someone may pay.

A website collects personal data faster than people think. A contact form, a newsletter sign-up, an analytics script, a chat widget, an embedded video: all of them process something belonging to your visitor. GDPR does not ask for a thick dossier, but it does ask you to know what you do and be able to explain it.

The practical core is short. Ask only for what you need — a phone number you never call does not belong in the form. Tell people on a privacy page what you collect, why, how long you keep it and who you share it with. Sign a processor agreement with parties processing data on your behalf, such as your host or your mail system. And keep data inside the EU, or make sure there is a valid basis when it is not.

Cookies are a separate chapter many sites get wrong. For functional storage — your basket, your language choice, the security of a form — you need no consent. For anything that tracks, measures or advertises you do, and that consent must be given in advance, be as easy to withdraw as to give, and not be forced with a bar that only says 'agree'. A bar without a refuse button is not consent, and that has been enforced accordingly.

Fortunately there is a way out that pleases everyone: privacy-friendly analytics that build no personal profiles. With them you know how many visitors you have, where they come from and which pages work, without a consent bar and without sending data to an ad network. Plaincodelab takes that route by default, unless you genuinely want to measure advertising.

Security, finally, is mostly hygiene. A valid certificate so everything is encrypted, strong passwords with two-step verification for the admin, components kept up to date, forms protected against abuse, and backups you have restored so you know they work. Most hacked sites are not the target of an attack but the victim of an outdated installation that was found automatically.

The biggest damage from a new website rarely occurs during the build. It occurs on launch day, when addresses change without redirects and years of accumulated findability evaporate overnight. That is preventable with a few dull steps that are often skipped.

Step one is taking inventory. Which pages exist, which of them get traffic from Google, which produce enquiries, and which other sites link to you. That list is your starting point: everything with value gets a place or a redirect on the new site.

Step two is laying the new structure next to the old one. Every old address gets exactly one new address. Where a page disappears, you point to the most related page and not to the home page — a redirect to the home page is treated as though the page no longer exists.

Step three is keeping what works. If an old page performs well, take that copy along and improve it instead of replacing it with something shorter and prettier. The temptation to rewrite everything is strong, and it is the most common reason traffic drops after a new site.

Step four is testing before launch: walking through all redirects, submitting forms, running a crawler over the site to find broken links, and checking that the test environment is not accidentally indexed itself. Step five is the launch itself, preferably at a quiet moment.

Step six is watching. Right after a rebuild the numbers always fluctuate; that is normal. What you want to see is that the most important pages keep their traffic and that no error reports come in. That should be followed actively instead of waiting for someone to call.

A site is not a painting you hang up. It runs on software that changes, sits on a server that gets attacked, and speaks to visitors whose expectations shift every year. Maintenance is therefore not aftersales but part of ownership.

Technical maintenance is the least visible part: updating components, renewing certificates, making backups and restoring them to know they work, testing forms, and watching whether the site stays reachable. Monitoring belongs with it, so an outage is noticed before a visitor or a customer is, instead of only when someone calls.

Content maintenance is the part that earns money. What are people searching for that you have no page about? Which page draws traffic but produces nothing? Which text raises questions you see coming back in your inbox? An occasional hour on those questions does more for your enquiries than a new design.

Measurement belongs with it, but the right measurement. Not every visit is valuable and not every spike is good news. The numbers that matter are: how many people do what you want, via which pages do they arrive, where do they drop out, and what does it cost you to win one. Privacy-friendly analytics deliver that fine, without a consent bar.

And then the part nobody plans: change. A new service, a second location, a price change, a vacancy. If changing those becomes a project, it does not happen. That is why Plaincodelab delivers a site where you can make such changes yourself, with one point of contact for the work that does need a developer.

The technology under a site is largely the same for a hair salon and a law firm. What differs is what the visitor looks at, what holds them back and which step they must take. Plaincodelab therefore has a separate page for sixty industries, each with the questions and objections of that sector.

In services with urgent work — installers, plumbers, vehicle repair — everything turns on reachability: service area, phone number, and the promise of how quickly someone arrives. In appointment work — hair salons, nail studios, dentists, therapists — it turns on online booking, prices and who you will see. In retail and trade — shops, wholesalers, showrooms — on stock, delivery time and return conditions.

In professional services — lawyers, accountants, consultants — credibility counts most: demonstrable knowledge, recognisable cases and a first step without a barrier. And in hospitality and leisure it is about imagery, current opening hours and booking without hassle, because decisions there are made from a phone more often than in almost any other sector.

All those emphases sit in the industry pages beneath this one. They are not a sales pitch but a checklist: this is what your sector needs, these are the search terms that matter, and this is what it delivers. Anyone who does not see their own industry listed can simply ask — the approach stays the same.

Almost every site that delivers nothing does so for one of these reasons. They are all preventable, provided you know them beforehand.

The first is starting without copy. The design is approved on the basis of placeholder text, and when filling it in the real story turns out not to fit the boxes. Then either the design gets torn up or the copy is trimmed until it says nothing. Write first, design second.

The second is talking about yourself instead of the customer. 'We are a young and dynamic team' appears on ten thousand sites and answers no question at all. The visitor wants to know whether you solve their problem, what it costs and how quickly you can.

The third is hiding the enquiry. One contact page at the very bottom of the menu, a form with eleven fields, no phone number in sight. Every extra click and every extra field costs enquiries, and that is directly measurable.

The fourth is letting the site expire: outdated prices, a news item from 2021 at the top, a team member who left long ago. That raises more doubt than having no news at all.

The fifth is not owning the site. Domain in the agency's name, hosting with a party you have no access to, no copy of the content. Then moving is not a choice but a negotiation. Domain, hosting and content belong in your own company's name, with an export and documentation at delivery.

Quotes for websites are full of words that make comparison harder rather than easier. Below are the terms that come up most often, briefly explained, so that with two proposals you can see where they genuinely differ and which item is missing.

The most useful thing to do with this list: for every term, ask what it concretely means for your site and what happens if you leave it out. A supplier who cannot explain that in two sentences will not explain it during the project either.

Of all the parts of a website, the content is the only one you cannot outsource without being there. Plaincodelab can do the technology alone; the knowledge about your trade, your customers and your exceptions sits in your head. So the question is not whether you take part, but in which form.

In practice this works best: you supply the raw material, PCL turns it into copy. One conversation per topic yields more usable material than a request to write it yourself, because everyone finds talking easier than writing. Out of that conversation comes a first version you check on facts rather than on style.

What must come from you in any case: prices or price indications, service area, opening hours, terms, insurance or certifications, and the things your customers always ask. That last one is gold: every question you often answer by phone is a subheading on your site and a chance to be found.

Imagery deserves a separate note. Stock photos of smiling models with headsets convince nobody any more; a real photo of your own workshop, your own van or your own team does. One session with a photographer yields enough material for a long time, and it sets you apart more than any design. Where that is not possible, PCL picks imagery that stays neutral rather than fake-personal.

And then maintaining the content. A site that never changes after delivery slowly loses ground. Adding a topic now and then is enough: explaining a new service, adding a frequently asked question, describing a project. PCL can do that, but the best result comes when you supply the questions you are asked most.

As soon as a site serves more than one language or more than one location, structure matters more than design. Do it well and the versions reinforce each other; do it sloppily and they compete for the same visitor and both lose.

For languages: each language gets its own address, for example with the language code up front. Every page refers to its counterparts in the other languages, so a search engine knows it is the same content and shows the right version. There should also be a reference for visitors whose preference is neither. Automatically redirecting based on country is a bad idea: it often goes wrong and it keeps search engines out.

Translating is also not copying. A machine translation of your Dutch copy reads to an English customer like someone trying hard but not quite there, and the search terms differ per language anyway. Better one language that is right than two that are half done — and if a second is added, then as its own version with its own copy.

For multiple locations the rule of thumb is: a page per town, provided that page has something of its own to say. Address, route, opening hours, the local team, photos of that building, and what is different in that town. Twenty pages differing only in the place name are recognised for what they are and help nobody.

Those same pages are your hook into maps and local results. Link every location page to its business profile, keep name, address and phone number identical everywhere, and put opening hours in the structured data too. For companies with a service area rather than a location the same principle applies: one page per area you genuinely cover, with copy that proves it.

Beneath every site sit three things that are rarely explained in a quote and can shut your business down if something goes wrong: your domain name, your hosting and your email. They belong together and they should be yours.

The domain name is your address and your identity. Register it in your company's name, with your email address as the contact, and switch on automatic renewal. A domain that expires because the reminder went to an old address is one of the most painful and most common failures there is — and re-registering does not always work. Choose deliberately too: a short name without hyphens, with an ending that fits your market.

Hosting determines how fast the site is, how often it is reachable and how well it is protected. For most businesses solid hosting inside the EU is enough, with a certificate, backups that can genuinely be restored, and an environment that scales with a spike. What you mainly want to know: where does the data sit, who can access it, and how quickly is someone there when it goes wrong.

Email is the part forgotten most often and the one causing the greatest silent damage. Mail from your own domain should be configured correctly with the three technical records that fight spam — otherwise your quotes land in the junk folder without you noticing. Keep mail separate from your website too: if the site moves, the mail must simply keep working.

Finally, the keys. You should always have access yourself to the domain, the hosting panel and the site's admin, even when someone else manages it. Those accounts belong in your own company's name, even when someone else does the day-to-day work, with documentation alongside. That sounds obvious, but in practice it is the most common reason business owners are stuck with a supplier they want to leave.