Website Relaunch Agency Fürth

The trigger is rarely the look of the site. It is the daily grind. A price change takes three days because it has to go through an agency. Nobody dares to add a new page because the layout falls apart when they do. Form submissions land in an inbox nobody owns. Images get uploaded at full resolution because there is no other route.

Technical signs pile up on top. The CMS no longer receives security updates, the PHP version has been declared end of life, individual extensions are no longer maintained by their vendors. The theme was bought once and then customized so heavily that updating it is no longer possible. On a phone, parts of the site are barely usable.

Commercially, it surfaces elsewhere. A shop is supposed to be added, a second market, another language, a closed customer area. Or the site describes a company that no longer exists in that form, because services, audiences and contacts have all moved on.

It starts with an inventory of the existing pages together with their usage data. Every page then gets a decision: keep, merge, rewrite or drop. Structure, design and build come after that. The reason for this order is plain: design without that list and you produce pages nobody opens while missing the ones that bring inquiries. For companies in Fürth, Nuremberg and the surrounding area we like doing this part on site, because then the people who maintain the site every day are in the room.

We need three things from you early on. First, access to hosting, domain, CMS and the analytics accounts. Second, one contact who is allowed to decide, rather than a committee that postpones when in doubt. Third, content. Text, images, product data and references are the point where the schedule slips in almost every project.

A few questions also belong at the start: does the current system stay, who maintains the site afterwards, and which third party systems have to stay connected, such as ERP, newsletter or recruiting tools. We mostly work with WordPress and WooCommerce, but we check whether that fits the requirement before committing to it.

The most common source of delay is content. A draft can be shown quickly, but text for forty pages does not get written on the side, and product photos that follow one consistent standard rarely exist yet. If content is not planned early and nobody is made responsible for it, the launch date keeps moving.

The second source is approvals. When new people join a running project and reopen settled questions, every round costs more than the one before. Feature requests that appear mid build without anything else being dropped have the same effect. Both are avoidable by writing structure and scope down and approving them properly once.

Not every weakness justifies a rebuild. If the structure holds and only the design has aged, redesigning the main templates is the smaller move. If too few visitors arrive, the cause is rarely technical; it usually sits in content and visibility. And when a site is being replaced mainly because a competitor rebuilt theirs, the project has no goal against which anyone could later judge whether it paid off.