Custom website development services
in Baltimore

A redesign changes how a site looks. A restructure changes where things are. The second one carries the risk, and the risk is concentrated in the addresses.

Every URL that has been live long enough has value attached to it. Links from other sites. Bookmarks. Entries in a search index. Printed material nobody can recall. Change the address without a forwarding rule and all of that lands on an error page.

The work starts with a complete list of what exists now. Not the list the new site plan describes. The list the live site actually has, taken from the server, the sitemap and the analytics, then reconciled. Pages nobody remembers are exactly the ones that break.

Then the map. Every old address gets a decision: it moves here, it merges into that, or it is retired on purpose. A merge is a permanent redirect to the page that now covers the topic. Retirement should be rare, because a redirect costs nothing to keep.

Two mistakes recur. The first is pointing everything at the home page, which tells a visitor nothing and tells a search engine the content is gone. The second is a chain of redirects, each added by a different migration, until one click passes through five hops. Chains should be flattened to a single step.

Assets are part of this. Images and files have addresses too, and they are often the ones embedded in other people’s pages.

After launch the map has to be checked against reality rather than against the spreadsheet. Crawl the old list. Every entry should answer with one redirect to a live page. Anything that answers with an error or a chain goes back on the list.

Then watch for a few weeks. Error logs show the addresses you missed, and they show them in order of how much they are used. That list is worth more than any audit written before launch, because visitors wrote it.

Analytics usually arrives backwards. A tag goes on, dashboards fill up, and nobody can say what decision any of it informs. Two years later the reports are opened once a quarter, out of duty.

Start from the questions instead. There are rarely more than four or five that matter: which pages bring enquiries, where people abandon the form, whether the phone number is used more than the form, and which sources send readers who stay. Write them down before choosing a tool.

Then decide what counts as a result. A submitted enquiry is a result. A page view is not. A site with no defined conversion cannot tell a good month from a lucky one, and every argument about the site becomes a matter of taste.

Consent changes the picture, and it should be handled honestly rather than hidden. Some visitors will decline tracking. The numbers you keep are therefore a sample, not a census. Measurement that acknowledges this is more useful than measurement that quietly pretends otherwise.

Server logs are the part that gets forgotten. They record every request, including the ones that never run a script: bots, feeds, files, errors. For questions about crawling and broken addresses they are the only honest source.

More tags do not mean more insight. Every additional script slows the page and adds another party to your privacy notice. If a tool is not answering one of the written questions, it is costing you twice.

Reporting should be short and repeatable, with the same handful of numbers for the same period and a sentence about what changed. A long report is read once. A short one gets compared.

We set the questions first and the tooling second. That order is the whole difference between a measured site and a monitored one.

Organisations funded by grants usually have reporting duties. So do those regulated by a body that publishes standards. Many of those duties land on the website. They land there late. Somebody discovers in the final month that a document has to be publicly accessible in a specific form.

Treating this as a build requirement rather than a content task changes the outcome. The requirements are usually written down somewhere, covering which documents, in what format, how long they stay available, and whether a reader must be able to find them without searching.

Permanence catches teams out. A filing may have to stay available for several years. The site gets redesigned every three. The address has to survive the redesign, which means it should be chosen deliberately rather than generated by whatever system happens to be in use.

Format requirements can be specific. Occasionally they are awkward. A document may have to stay a downloadable file, with a readable text layer, sometimes in more than one language. Automated conversion from a design tool often produces a file that looks correct and carries no usable text, which fails the requirement without any visible sign.

Accessibility is frequently part of the obligation rather than an aspiration. That raises the bar on the documents themselves. The pages around them are the easier half. A scanned filing is an image, and an image is not accessible to a reader using assistive technology.

There is a practical benefit alongside the compliance one. The same material is usually what a prospective partner, a journalist or a board member wants to see, and an organisation that publishes it well is easier to deal with. Burying it in a subdirectory nobody links to satisfies the letter of the duty and wastes the rest.

We build these sections with an owner, a review date and a check that runs on a schedule, so a broken link in a filing is found by the site rather than by a regulator.