Frequently asked questions about websites, internal apps, SEO and AI

Not every older website has to be rebuilt. A relaunch makes sense when several fundamental problems come together: outdated technology, poor mobile use, unclear content, security risks, slow pages or a structure that no longer fits the business. If the foundation is sound and the website is already visible, a targeted website optimisation after a technical audit can be more economical.

With a redesign, technology, content and URLs largely stay the same; mainly the design and components change. A relaunch can also change the information architecture, CMS, templates, content, tracking, integrations and URL structure. The more layers change at the same time, the more important migration, testing and a clear rollback plan become.

Yes. Common causes are deleted content, changed URLs without matching redirects, lost metadata, faulty canonicals, broken internal links or a noindex setting carried over by accident. That is why I treat a website relaunch as a design, development and SEO migration project.

Relevant URLs with rankings, backlinks or traffic should be kept or redirected with a permanent 301 redirect to the matching new content. For this, a URL mapping is created before launch, tested and monitored after go-live. Redirecting all old pages to the homepage across the board is not a clean migration strategy.

Only if there is a clear business or technical reason. Every additional change increases the number of possible sources of error and makes root-cause analysis harder. If a domain change is necessary, redirects, Search Console, sitemaps, internal links, email DNS and external profiles are planned as a separate migration strand.

Normally the existing website remains available while the new version is built in a separate environment. The actual go-live is prepared, tested and kept as short as possible. Technically, email is a separate service; when DNS or hosting changes, MX, SPF, DKIM and other records must be carried over deliberately so that no messages are lost.

A focused rebuild can be delivered in a few weeks. For a strategic SME relaunch, eight to sixteen weeks are often realistic; larger, multilingual or integrated systems take longer. Texts, photos, internal approvals and later changes to the scope usually affect the schedule more than expected.

Before the relaunch, baseline values are documented: qualified enquiries, organic clicks, important rankings, conversion rate, completed forms, Core Web Vitals and indexing errors. After go-live, the same measurement points, important user journeys and technical signals are checked. A professional relaunch therefore doesn’t end immediately after the switch.

When a recurring workflow is business-critical and constantly loses time through duplicate entries, follow-up questions, a lack of overview or disconnected programs. An internal app for SMEs pays off not because it has as many features as possible, but when a clear bottleneck measurably shrinks.

When several people need the same data, versions drift apart, entries are made on the move, permissions are missing or an error has direct consequences for orders, billing or customer service. For personal calculations and rarely used lists, Excel often remains the better solution.

Standard software is usually cheaper and ready faster if it covers the core process well. Custom software becomes interesting when an important workflow of your own only works with standard products through permanent workarounds, duplicate maintenance or many add-on tools. Often the best solution is a lean custom interface that connects existing systems.

A clearly defined first web app can start at a mid four-figure sum. Several user roles, complex integrations, offline use, data migration or extensive business rules usually lead to a five-figure project scope. Quotes only become comparable with a concrete first workflow and clear acceptance criteria. A process check for €390 clarifies scope and cost frame; it is credited if you go ahead.

For many internal processes, a responsive web app that runs in the browser on computer, smartphone and tablet is enough. That saves separate app store releases and multiple codebases. Native apps make sense when device features, reliable offline use or special performance requirements justify them.

Often yes, if the system provides a suitable API or a reliable import and export. Some providers only make their API available in certain plans or through partner programmes; in that case, data exchange via import and export is often the more economical solution. Before implementation, the available data, rights, technical limits, costs and error cases must be checked. An integration should reduce duplicate entries, not just copy data uncontrolled.

Yes, after the spreadsheets, formats, duplicates, required fields and data quality have been checked. It is also important to document rules that only individual people know today. Only then can you decide what is migrated automatically, cleaned up or deliberately left behind.

Yes, if a frequent workflow costs a lot of time, causes errors or delays revenue. With only a few invoices, contacts or tasks, standard software is usually more economical. For sole traders, a first version should stay particularly small and have a clearly calculable benefit.

Possible causes are a new or not yet indexed domain, technical blocks, weak or unclear content, missing internal links, strong competition or a search query the page doesn’t match. First, indexing and Search Console are checked, then content, search intent, local signals and technical quality. A blanket “SEO setting” doesn’t solve these different problems.

Usually not on its own. For local searches, a fully maintained Google Business Profile, consistent company data, suitable service and location information, reviews and a technically clean website are important building blocks. Website and business profile should not contradict each other in name, address, services and contact details.

Not necessarily. The causes often lie in unsuitable search terms, unclear positioning, a lack of trust, weak calls to action, form problems or conversions that aren’t measured. 2,000 relevant visitors with clear guidance can be worth more commercially than 10,000 irrelevant ones – SEO and conversion have to be considered together.

Technical foundations, information architecture and a clean migration can be delivered as a project. Search demand, competition, content and your own offer change continuously, however. Not every business needs a large monthly SEO contract, but relevant pages, search data and technical errors should be reviewed regularly.

No, not honestly. Rankings depend on search intent, competition, location, quality, freshness and Google’s systems; no provider controls these. What can be agreed is concrete work, technical standards, content, measurement points and transparent reporting – but not a permanent position that doesn’t belong to the provider.

Technical fixes can become measurable quickly; new content and stronger rankings often take weeks or months. After a URL migration, temporary fluctuations are normal; small to medium-sized websites are often largely reprocessed within a few weeks, larger websites take longer. What matters are clean redirects, sitemaps, crawlability and ongoing monitoring.

Yes. For prototypes, landing pages and small websites, AI can generate design, copy and code very quickly. The more important question is who makes sure the result is still secure, fast, maintainable, findable and extensible in six or twelve months.

Because code is only one part of the project. AI doesn’t automatically take care of business goals, information architecture, existing rankings, migration, analytics, data protection, accessibility, integrations, security, QA and operation. Where AI saves work, that efficiency should lower the price or free up more time for quality and testing – not be artificially ignored.

Not automatically. What matters is technical accessibility, accuracy, structure, performance and real usefulness – not whether a draft was created with AI. Mass-produced generic content without first-hand experience is weak; real projects, expertise, measurements, processes, decisions and identifiable authors are strong.

No. Crawlable pages, clear information architecture, helpful content, internal links, a good page experience and credible sources remain fundamental for generative search too. Google describes GEO and AEO as part of search optimisation, not as a replacement for SEO, and recommends the same solid fundamentals for AI search experiences.

A placement cannot be guaranteed. The best foundation is public, crawlable content, clear service and company information, genuine expert articles, case studies, consistent data and credible external mentions. GEO and AI search optimisation therefore extends solid SEO and content work; there is no secret markup and no single llms.txt file that forces recommendations.

No. A chatbot makes sense if it solves a concrete problem: answering frequent questions, searching complex information, qualifying leads or relieving support. A chat window without a clear benefit, on the other hand, creates costs, data protection questions and maintenance effort. AI consulting should therefore start with the process, not the tool.

The challenge is usually not the design, but the number of dependencies: many stakeholders, hundreds of URLs, several languages, roles and approvals, CRM or ERP, recruiting, newsletter, analytics, consent, APIs, security and existing campaigns. The relaunch thereby becomes a migration and risk management project.

First, content, URLs, languages, owners and technical dependencies are inventoried. This is followed by the target structure, migration rules, redirect mapping, automatable imports, spot checks and approvals per market or content area. Not every old page has to be carried over, but every deliberate merge or removal needs a traceable decision.

Before the rebuild, systems, data flows, owners, authentication and important events are documented. In the new system, it’s not just scripts that are added – complete user journeys are tested: enquiry, CRM handover, consent, conversion, notification and the error case. Monitoring after go-live is part of the migration.

Through accounts under company control, documented infrastructure, exportable data, accessible source code, backups, clearly regulated licences and widely used standards where they make sense. Custom development is not automatically lock-in; undocumented dependency is. For critical systems, handover, cover and restart should also be plannable in practice.