DEV Community

Cover image for What's Behind a Professional Website?
Matthias | StudioMeyer
Matthias | StudioMeyer

Posted on Originally published at studiomeyer.io

What's Behind a Professional Website?

Two websites can sit next to each other looking alike, and still one is a shop window and the other is a working business. The difference is not on the home page. It shows when somebody searches. When a program wants to read the site. When an enquiry needs to arrive. When the domain moves. When something breaks.

That is hard to put in a proposal, because it is not a list but a sequence of decisions. This piece makes them visible, from the first measurement to what keeps running after launch.

Before Anyone Designs Anything, We Measure

If a site already exists, we do not start with an opinion. Load time on a phone and on a desktop, measured separately, because the same page performs very differently on the two and the phone figure is the one that counts. Which extensions are running, in which version, and whether that version has a reported vulnerability. Which addresses are reachable from outside that should not be. Whether the legal pages match the services actually embedded.

Then a look at the business from outside, not just at the site: what someone finds who searches for the name, and what someone finds who searches for the service. What the answer engines say about the business and where they got it. And the Google profile, which for a local business often carries more than the home page. Categories, opening hours, reviews, the linked destination.

The most revealing part is a comparison hardly anyone makes: do the profile, the website and the industry directories say the same thing about address, phone and hours. Often they do not, and nobody noticed, because you have to put all three side by side to see it.

Two rules belong to this measurement. First: a finding from outside is evidence, the absence of a finding is not. We can say that we found nothing, and that is exactly how it is written down, rather than selling a clean measurement as a certificate of health. Second: every number comes with its source and the date it was taken. We do not adopt outside measurements unchecked, not even the flattering ones. A number you pass on becomes your own, including its measurement error.

Research in Four Directions Before the First Line Exists

Then comes research, in four directions at once. How the best sites in this industry are built, taken apart technically: colour values, type system, motion patterns. What people in this industry actually search for and with what intent. What the competitors say and where the gap is. And which pages are needed at all, in what order.

All of it converges into a single build brief, and the build runs against that. The order is inconvenient but it has a reason: research after the first draft changes nothing. Whoever designs first and then looks at what the market does will defend the draft instead of changing it. Not out of stubbornness, but because a finished draft is already an argument in the room.

The Design Is Derived, Not Picked

There is no template a client moves into. Templates make sites resemble one another, and you can tell, even when you cannot say what gives it away.

Instead a design direction is chosen deliberately, with a reason for why this one fits this business. Editorial or strictly minimal, narrative in the scroll or calm in the grid, warm or technical. A collection of styles, colour worlds and type pairings is available, each with its known weaknesses, but those are candidates and not a catalogue: the choice is argued against this client, never the first hit, never without our own adaptation.

One rule applies explicitly to ourselves. Our own look does not get copied onto the client. Falling back into a familiar handwriting is tempting enough that the review later has a dedicated check for it, and that check is invalid without screenshots someone actually looked at. Design cannot be judged from source code.

As for the Material, Nobody Has to Prepare Anything

For the copy, bullet points are enough, we handle the shape. We prefer real photos, and where there are none, we take care of it. We design a logo if there is none. The legal wording we write anyway. What the client provides is used verbatim and not rewritten, because the moment somebody smooths a sentence out, there is a claim standing there that nobody verified.

The domain switch comes at the very end of this process, after sign off. Putting it at the beginning turns a harmless step into an obstacle.

We Also Build What Your Visitor Never Sees

This is the part a site builder does not build, because nobody orders it.

Every page gets a structure machines can read. Not a few keywords in the header, but a coherent description of the business: who this is, where it sits, what it offers, when it is open, how the pages relate to each other. The address in there is the same as in the legal notice, character for character, because a deviation turns one business into two.

On top of that comes a second version of every page in plain text, for programs that have no browser. No layout, no scripts, no noise. That is what makes the site properly readable for such programs in the first place, and several developer tools now request this version on their own. It is not a guarantee that an assistant will then relay the business correctly: whether it gets cited depends on more than one file.

Then the question of who gets in at all. There are many programs reading websites by now, and they have different intentions. Some send visitors, some collect for training, some answer questions. The site tells them what is permitted, in a form that actually gets read. This is not a setting you make once: the lists change, and what was right yesterday locks out someone today that you want inside.

And finally the numbers and facts themselves. On a site that has grown, the same figure appears in many places at once: in copy, in the search description, in the machine readable structure, in the chatbot's answers. Here it comes from a single file. Without that one source, some of those places drift within weeks, and language models then pass the old figure along as the current one.

Legal Pages That Fit the Site Instead of a Template

A legal notice with the real details. A privacy policy describing exactly the services running on this site. A template always makes two mistakes at once: it describes services that are not here and stays silent about the ones that are. The second is the serious one. Where an industry is subject to its own regulations, a lawyer still belongs on top of it at the end, and we say so.

As long as nothing is embedded that sets cookies or passes data to third parties, the site needs no consent banner. That is not a design decision, it follows from the choice of tools, and it holds exactly as long as it holds for every single element: an embedded map, a video player or a typeface from someone else's server tips it back over.

Review Comes From Someone Other Than the Builder

Whoever builds does not sign off on their own work. The finished work goes to a different language model with the explicit brief to refute it rather than confirm it, and that runs in rounds until nothing real comes back.

The reason is not caution but a property of reviews: whoever checks their own work checks it with the same assumptions they built it with. That is why test runs reliably catch the errors somebody thought of and miss the others. A sentence contradicting a feature two screens further down fails no check. A stranger spots it immediately. Which patterns these invisible errors follow is a piece of its own.

That does not replace a human pair of eyes, because two models share part of their blind spots. So at the end somebody stands in front of the finished site and looks at it, in every language and at phone widths. In between, review runs in several directions: whether the design stands on its own, whether the statements match the source, whether the site works with a keyboard and the contrasts hold, whether the machine readable surfaces really get delivered, whether redirects are clean, whether it is fast.

Where the Site Runs Decides What Can Happen to It

Client sites run on our own server, each in its own enclosed space with its own limits. Without such limits, a single site going haywire drags the whole server down, and then every client is standing still.

Underneath sits a protective layer nobody ever asks about and that gets built every time regardless: a firewall leaving only the necessary doors open, an automatic block for repeated login attempts, access by key only, a database unreachable from outside, automatic security updates, daily backups.

The real difference lies elsewhere though. The best protection is the attack surface that does not exist. A finished site delivers files. There is no program assembling content from a database on every request. There are no third party extensions running in the same process. And where the site needs no login of its own, it has none, so there is nothing for anyone to try passwords against.

On the other side, every extension is its own attack surface with its own update rhythm and its own reported gaps, and somebody has to attend to all of them every month. That is not the operator being careless, it is the price of the construction method.

In front of it sits a dedicated network layer per client domain, holding together what elsewhere gets bought piece by piece: name management, a firewall in front of the site, the cache, protection against bot load, global delivery and encryption. The difference to the usual kit of extensions is not the price, it is the position. This layer sits in front of the website, not inside it. What gets turned away at the network edge never reaches the application.

Moving Day Is the Day Nobody Should Notice Anything

Building and sign off happen on a preview address. The domain is touched last. Whoever switches early has either a construction site in public or downtime.

The trickiest part of that day has nothing to do with the website. When name management changes, the business's email can break without anything looking broken. With some providers a setting has to stay explicitly active so their mail system keeps being used. If it is missing, mail is still accepted, the sending server gets its confirmation, and nothing is delivered. No error, no bounces, just a mailbox where suddenly nothing arrives. So before any such switch we check what depends on the mail path, and the mail record only moves once the new address demonstrably accepts post.

For the existing visibility to travel along, every single address of the old site is captured beforehand, per language. Every old address gets its new destination. What gets signed off is not the list of rules but a run against the new site: every old address has to arrive in one hop. A map checked only against itself never knows about the addresses missing from it.

Measurable From Day One, Not From the First Question

Right after the switch we set up what the business does not have yet: the accounts at Google and Bing with a verified domain and a submitted page overview, plus a visitor counter of its own. That runs on our infrastructure, without cookies, without stored IP addresses, without profiles across sites.

Doing it immediately has a reason that is easy to miss: the data starts on the day of registration, not on the day of launch. Whoever attends to it later has spent the time in between blind, and it does not come back.

The accounts are in the client's name, not ours. We get read access, to evaluate and improve. If they leave, they keep their data and their history.

And the site does not then wait to be found. On every change it announces itself. Why a new site still goes unfound at first is a story of its own.

What Keeps Running Once the Site Is Up

The default is simple: we make every change. That is what ongoing care is for.

Anyone who still wants to work on a text or an image themselves finds an interface for it in their own area. What gets saved does not go live immediately but into a draft first, and the preview shows the real page on phone and desktop. Colours there are a selection from the brand rather than a free colour picker, so the design does not fall apart piece by piece. And whoever wants to can have their own chat connected to the site. That connection brings more than access: it brings rules and knowledge about this specific website, so the assistant they already have open knows their business.

Every website also gets a chatbot, without a second subscription. It answers from the real content of this business rather than from a model's general knowledge. That does not make it infallible, but it takes away its most common failure: a bot inventing something plausible about opening hours is worse than no bot at all.

Once a month comes a report on what the site brought in: what people searched for, what they found the business through, who actually came by. What counts as a visitor in there is a human being. The larger figures a network provider reports count every machine as well, which is why they do not appear as visitor counts.

What We Deliberately Do Not Do

We do not change anything directly on the server. Every change goes through version control, through a history where every state is named and one step away from being restored. A state that lives only on the server is gone at the next deployment, and nobody can say what was in it. A site builder offers no such thing, because the layout there sits in the system's database: an earlier state is at best a backup of everything, never a single change taken back.

And we do not report anything as finished that nobody looked at. At the end the client gets more than an address: they get the state of things, along with an honest list of what is still open. Such a list is not a weakness. It is the difference between a project that is done and one where somebody later asks why the placeholder image is still there.

The Actual Difference

Most website proposals contain roughly the same words. Security, SEO, performance, GDPR, mobile optimised.

The difference is not in the list. It is in how much of it actually gets built instead of merely switched on, in what order it happens, and who checks afterwards.


Originally published on studiomeyer.io. StudioMeyer is an AI-first digital studio building premium websites and intelligent automation for businesses.

Top comments (0)