How we run a baseline measurement, before anything changes
The trouble with measuring afterwards
A rebuilt website always looks better than the old one. That is not an achievement, that is what new looks like. The question that matters is whether it also works better, and you can only answer that if you recorded the old state before it disappeared.
That is where it nearly always goes wrong. Not out of carelessness, but because the old state refuses to come back. Analytics fills in nothing retroactively. The old pages are gone. And remembering that it felt slow is not a measurement.
So every project here starts with a baseline. A document that improves nothing and advises nothing, and does exactly one thing: record where we are starting from, with a source under every number.
Five angles at once, and nobody echoing anybody
A baseline written by one person measures whatever that person happens to care about. So we split it into five angles that run at the same time and cannot see each other's results: technical delivery, findability, content and internal structure, the comparison with similar businesses, and the visual language.
Keeping them apart is not an organisational nicety. Anyone who already knows the previous result will reason towards it. Two measurements that agree because the second one read the first are worth no more together than one.
The rule the whole document rests on
One rule comes before all the others: no number without a source. Every finding carries the URL, the command or instrument used, and the timestamp. A finding without evidence gets cut, however plausible it sounds.
That sounds strict and it is mostly practical. Six months on, nobody remembers where "about a second of server wait" came from, and the number is then worthless at exactly the moment you need it. With the source attached, anyone can repeat it. Including us.
And when something cannot be measured, that is the answer. Not "roughly", but: this cannot be measured without access to X. And then X gets requested.
The part that actually matters: the second pass
This is where a baseline separates from an impression. Every finding is measured again, by someone who did not write the first report. Only what survives that second pass enters the document as fact.
What gets killed is almost always the kind of finding presentations love. A load time that is spectacularly slow in one run and never comes back across three re-runs, because an animation makes the measurement throw the occasional outlier. The underlying point stands. The number does not.
Certainty gets killed too. "No external links anywhere" often becomes, on re-measurement: not on some of the pages. "No prices anywhere" becomes: somewhere, just not along the route a visitor walks. A conclusion can hold while the number in the margin turns out to be an outlier. That difference belongs in the document.
Every one of those killed findings stays in the report, with the reason and with whatever replaced it. That is not penance. It is the only part of the document that shows you how strictly the rest was measured.
Measure what a visitor gets, not what the source code promises
The fourth rule is the dullest and pays the best. Measure the page as it arrives at a visitor, in a real browser, with JavaScript executed, rather than as the source code promises it.
That is exactly where the heaviest findings sit, and they are invisible in the source. A button that looks perfectly good in the markup can be a link to nothing in the rendered page. Read only the source and you see a row of calls to action. Click, and you may find that none of them work.
The same goes for structure. It happens more often than you would think that a large share of the pages has no internal link pointing at them at all. They exist, they sit in the sitemap, and there is no route to them from the site itself. You do not find that by counting pages. You find it by writing down, for every page, who links to it, and then looking for the rows that stay empty.
And then the kind of fault nobody thinks to check: a site entirely in Dutch that tells search engines, on every page, that it is in English.
What ends up at the bottom
The baseline ends in a table of starting values per angle. Server wait, page weight, number of reachable pages, number of articles, positions on the search terms that matter. Empty columns beside them for the re-measurement.
What strikes me again and again is how much more positive the verdict tends to be than the list of problems suggests. A site can be soundly delivered on the technical side and faster than its comparison group, while what is broken underneath is largely dead weight that a rebuild removes for free. That is a favourable starting point, and it belongs in the document just as much as the dead buttons do.
Six weeks later, same table
The re-measurement is set for six weeks after launch, with exactly the same values and the same method. That table already exists, with empty columns, the moment the baseline is finished.
Deliberately so. Decide what to measure only after the rebuild and you will quietly pick the numbers that flatter you. That is not bad faith, that is how people work. The only remedy is to fix the yardstick before you know which way the result will fall.
What you can take from this yourself
You do not need an agency for this. Three things, and you can have them in an afternoon.
Record where you stand today, with the date on it. Speed, number of pages, the terms you get found on. Even roughly: a rough measurement from today beats a precise one from six months out.
Have someone else re-measure your most important finding. Not the person who found it. You will be surprised how much comes out differently the second time.
And click your own buttons. All of them, including the fifth and the ninth. It is the cheapest measurement in existence, and it often produces the most expensive finding.
Frequently asked questions
What is a website baseline measurement?
It is a record of the measurable state of a site before anything about it changes. Speed, technical delivery, findability, content and how it compares to similar businesses, with the source and timestamp under every number. You need that starting point to show later what a rebuild actually did, because without it every result afterwards is just a story.
Why measure a site before rebuilding it?
Because once the rebuild lands you can no longer reach the old state. Analytics fills in nothing retroactively, the old pages are gone, and remembering that something felt slow is not a measurement. Start measuring afterwards and all you can say is how things are now.
How do you keep wrong numbers out of a baseline?
By measuring every finding a second time, independently of the first, and keeping only what survives. That almost always costs a few findings, often the most spectacular ones. What gets killed belongs in the report too, with the reason it was dropped.
What exactly does a baseline measure?
Five angles at once: technical delivery, findability in search, content and internal structure, a comparison with similar businesses, and the visual language. And it measures the page as a visitor receives it rather than as the source code promises it, because those two come apart more often than people expect.
When do you measure again?
Six weeks after launch, using exactly the same values and the same method. The table is already sitting there with empty columns the moment the baseline is finished. Decide what to measure after the rebuild and you will quietly pick the numbers that flatter you.