Answers on board
Frequently asked questions about web design,
Hosting and visibility.
Here we collect the questions we receive most frequently: about web design, hosting, SEO, contract durations, and costs. If your question isn't listed, write to us, and we'll add it.
01Frequently Asked Questions
This collection is growing. Questions we receive via form, phone, or WhatsApp will be added here once they have been asked more than once. The glossary explains terms.
02Still open
Frequently asked Questions.
More than most people realize. The web server is the software that accepts every request from the browser and delivers the page. The most common type is open source and free, which is why it's found almost everywhere. However, there are more powerful, paid alternatives. In our high-speed environments, we rely on precisely that: LiteSpeed. The difference is less noticeable with a single visitor than when many arrive simultaneously. Finished pages are stored in the cache instead of being recalculated with each request. For you, the name is secondary; what matters is the noticeable result.
A website is typically rebuilt each time it's requested: the system retrieves text and images from the database, assembles a page, and sends it. This requires processing time every time. A cache stores the finished result and simply delivers this copy on the next request. For content that rarely changes, this is the single biggest speed improvement there is. The trick is to clear the cache at the right moment so that changes are immediately visible.
Because it grows, usually unnoticed. Over the years, pages are added, images are uploaded in increasingly higher resolutions, extensions accumulate, and the database fills up with legacy data from deleted content and old versions. None of these things are noticeable on their own, but together they add up. A website isn't a piece of furniture you just set up; it's more like a vehicle that needs maintenance.
Less than the score suggests. Common tools measure a single request, often from a simulated mobile device with a throttled connection, and summarize the result into a single number. This number fluctuates considerably between measurements. The individual metrics below it are more meaningful: how long does it take for the first visible content to appear, does the layout jump around during loading, and does the page respond to the initial input? Optimizing only the overall score polishes a metric instead of reflecting the experience of real visitors.
Because three things come together there. The mobile network is slower and less reliable than a landline in the office, a phone's processor is weaker and yet has to execute the same program code, and many websites load the same large images on small screens as on large ones. The last point is the most annoying because it's the easiest to fix.
This depends less on the number of visitors than on what the page has to do with each request. A page served from the cache can handle many times more work than the same page without it. The critical point typically isn't during everyday use, but during peak loads: a press release, a newsletter, a campaign. The page absolutely mustn't crash at those times, because that's the moment it was built for.
Usually less than the term suggests. Such a network distributes copies of the website across servers worldwide to keep the distance to the visitor short. If your customers are all within a hundred kilometers, this distance is short anyway. The benefit then lies more in side effects like protection against DPS attacks. For regional providers, a fast server in the right location is usually the more effective investment.
The problem lies in recurring patterns rather than isolated glitches. The site becomes noticeably slower at certain times of day, the administration area responds with a delay, uploads fail, or error messages appear sporadically, disappearing after a reload. Every environment experiences occasional glitches. However, when these occurrences become more frequent and correlate with visitor traffic, a critical threshold has been reached.
Because they were built for different tasks. A system that manages a company website with thirty pages has different requirements than one that supports a corporate website in twelve languages with tiered editorial rights. The market has segmented along these requirements, not along quality lines. Therefore, the question is never which system is the best, but rather which one requires the least effort relative to the task at hand.
Only if you plan to edit the content yourself. A simple online business card that remains unchanged for years can manage without one and is even faster and more secure. However, as soon as you regularly add text, images, dates, or job postings, a system immediately pays for itself. The deciding factor isn't the size of the website, but rather how frequently content is updated.
A theme defines the look and feel of the entire website, including fonts, colors, header, and footer. A website builder is an additional tool that allows users to freely assemble individual pages from building blocks. Both have their place, but the combination becomes problematic when the same design is used in two different places. Then, later on, no one will know where a particular color actually came from.
Because their widespread distribution makes them targets. If a vulnerability is discovered in a widely used extension, it is publicly documented, and automated attacks can scour the entire network for it within hours. The time lag between the publication of the vulnerability and the first attack attempt is the real danger zone. Updates are therefore not merely cosmetic, but rather the closing of precisely this window of opportunity.
Numbers are the wrong metric. Twenty lean, well-maintained extensions do less damage than three bloated ones, each loading its own program libraries on every page. Three questions are crucial: Will the extension continue to be developed? Does it load its components only where needed? And is there a leaner solution for the same goal? Every extension is an ongoing commitment, not a one-time decision.
Initially, nothing happens, and that's precisely the trap. It continues to function, but no longer receives security updates and eventually fails during a major system update. Anyone who only notices this when it fails is under pressure to find a replacement. Therefore, every maintenance check should include verifying when an installed extension was last updated.
Yes, but the effort is rarely where you'd expect it. Texts and images can be transferred; that's the easy part. The real challenge lies in everything tied to the old system: forms, special functions, the address structure, and the established design. Therefore, switching is almost always like building from scratch with content migration, not a move in the literal sense.
Technically, yes, but in practice it ends up in the spam folder. Large email providers decide whether a message is delivered at all based on the sender's reputation, and a web server, which otherwise only delivers pages, has none. Added to this are the documentation requirements for the consent process. Newsletters therefore belong on a separate, dedicated delivery path with properly documented sender authentication. Anyone who skips this step is writing messages for a folder that nobody opens.
Because the receiving end decides, not the sending end. Among other things, checks are performed to see if the sending server is even authorized to send messages for your domain, whether the message has been altered in transit, and how previous messages sent from this address have performed. If any of these checks are missing, even a completely harmless message ends up in the suspicious folder. The most common reason isn't an attack, but an incomplete configuration.
Three components that together prove an email truly comes from you. The first specifies which servers are authorized to send emails on your behalf. The second adds a digital signature to each message, making any subsequent alterations detectable. The third determines what should happen if the first two fail. Without these entries, your domain is vulnerable to forgery, and your genuine emails become suspicious.
For three reasons. First, you don't actually own the address; you can't transfer it when switching providers. Second, you can't provide proof of proper delivery yourself because you don't own the domain. And third, it appears to be a temporary solution. An address on your own domain costs little and is one of the most cost-effective ways to build trust.
Anyone subscribing to a mailing list initially receives only an email with a confirmation link. Only clicking this link activates the subscription. The reason is simple: otherwise, anyone could enter someone else's email address. For you, proof of this confirmation is crucial evidence in case of a dispute. Therefore, it must be documented and stored, not just performed once.
The crucial factor isn't a specific number of emails, but rather the transition from occasional to regular mailing. From the point where a mailing no longer takes just a few minutes, sending speed, return handling, and the reputation of the sender's email address all come into play. Those still using an occasional mailing solution will notice declining open rates before they notice error messages.
Bounced messages are messages that could not be delivered, for example, because a mailbox was deleted or is full. Ignoring them and continuing to send messages to the same addresses signals to mailing servers that you are not maintaining your distribution list. This negatively impacts the deliverability of all other messages. A regularly cleaned distribution list with fewer addresses ultimately reaches more people than a large one with inactive accounts.
As often as there's something to say, and regularly enough that it doesn't get forgotten. Balancing these two things is the real challenge. A rhythm that can be maintained for six months is more effective than an ambitious plan that fizzles out after the third issue. Incidentally, the most common reason for subscriptions isn't frequency, but rather irrelevance.
Generally, it's not straightforward. A business relationship alone does not constitute consent to advertising, and the exceptions are narrowly defined and subject to conditions. The safest approach is to actively request consent from existing contacts, even if this initially reduces the size of your mailing list. In case of doubt, this request should be made before sending any emails and before seeking legal advice, not afterward.
Closer than it looks. The registration form is on the website, consent is given there, the privacy policy is located there, and the linked content leads back there. A newsletter without a target audience on the website itself is ineffective, because that's where the intended purpose happens. Thinking of these two things separately is the most common conceptual error.
More likely than expected, but different than feared. Hardly anyone specifically targets a regional company website. The norm is automated programs that constantly scan the entire internet for known vulnerabilities and strike wherever they find one. For these programs, every accessible website is a target. Size doesn't offer protection, but maintenance does.
Very little. A backup that no one has ever tested is an assumption, not a safeguard. Typical nasty surprises in a real emergency: the database is missing, only files were backed up, the backup is located on the same server as the original, or it has been silently failing for months. The only proof that a backup works is a successful restore.
As often as you're willing to lose work. That's the only sensible metric. For a website that's updated once a quarter, a long interval is sufficient. For a shop with daily orders, the same setting will cause serious damage. It's also important to consider how many versions are retained, as problems sometimes only become apparent weeks later.
The first reflex to simply restore the last backup is usually the wrong one. As long as the cause is unknown, you'll allow the same attack to happen again through the same vulnerability. The correct sequence is: take the site offline, find the point of entry, close the vulnerability, restore a clean state, renew all access points, and then monitor. The last step is most often skipped.
Yes, even a purely informational page without a form. Browsers now visibly mark unencrypted pages as insecure, which deters visitors before they even see the content. Furthermore, an unencrypted connection can be manipulated while in transit. The days when encryption was an extra-cost option are over; it's now standard.
Maintenance is planned and runs in the background: updates, backups, monitoring, and regular checks. Support means having access to a contact person when something unexpected happens or a change is needed. If you only have one, you'll notice it at the worst possible moment. Without maintenance, incidents pile up; without support, you're left to deal with an incident on your own.
That translates to almost nine hours of downtime per year, significantly more than the figure suggests. Two places higher, at 99,99 percent, it's still just under 53 minutes. More important than the number itself, however, is what it includes: whether planned maintenance windows are excluded, over what period the average is calculated, and who is conducting the measurement. A figure without these parameters is a marketing claim, not a guarantee.
First, check if the problem is actually on the website: try accessing it from a different network, for example, via your mobile network instead of your office network. Surprisingly often, the cause is local. Next, check the obvious culprits, such as an expired domain, an expired certificate, or a failed update. Anyone who has set up monitoring will usually already know all of this before the first customer calls.
Since June 2025, many digital services in Germany have been subject to mandatory accessibility requirements that previously only applied to the public sector. These requirements primarily affect services with sales or booking functions; micro-enterprises are partially exempt. Regardless of the legal requirements, sufficient contrast, user-friendly forms, and meaningful image descriptions benefit everyone, including search engine optimization. If in doubt, consult a legal professional to determine whether and to what extent your service is affected.
In short, everything that allows for clear identification and contact: full name or company name, a valid address for service of process, a means of quick contact, depending on the legal form, the commercial register and registration number, and, if applicable, the VAT identification number. A P.O. box is not sufficient. Incorrect information is one of the most common reasons for cease-and-desist letters, and verification takes minutes.
Only if your site loads something that isn't technically necessary. Purely informational pages without analytics, embedded videos, or externally loaded fonts don't require it. However, as soon as audience measurement, maps, videos, or advertising tools are involved, explicit consent is required and must be obtained before loading. A banner that only provides information but still loads everything immediately doesn't fulfill its purpose.
Whenever a service provider processes personal data on your behalf, this includes even the operation of your server, as form entries and access logs are stored there. The contract regulates what the service provider is and is not allowed to do with this data. You remain responsible, therefore it is not merely a formality, but the basis for proper documentation of data processing.
No, not even if there's no copyright notice. The absence of a notice doesn't mean there's no protection. Even with free image databases, it's worth checking the terms and conditions, because some licenses restrict commercial use or require attribution. Photographs of people are particularly sensitive, as copyright is compounded by the right to one's own image. Evidence should be archived, not just checked once.
Not necessarily; within the European Union, the legal situation is straightforward. For providers outside the EU, it becomes more complex because additional documentation is required. A location in Germany simplifies the documentation and is easier to explain to customers. It also shortens the distance to the customer, which improves speed.
No, and this mistake is costly. A new website is essentially a building without a road. Search engines need to be able to find it, understand it, and categorize it, and they need a reason to prioritize it over existing results. This is achieved through content that answers a specific question, technical clarity, and links from other websites. Without these factors, even the most beautiful website remains invisible.
Longer than anyone involved would like. Technical fixes can become apparent within weeks, content development takes months, and building a domain's reputation takes years. Anyone promising quick results is either referring to paid advertising or methods that will later cause damage. The honest comparison isn't advertising, but compound interest.
Paid visibility is a rental: it takes effect immediately, is easily controlled, and ends the moment you stop paying. Grown visibility is owned: it requires an upfront investment, but it's permanent and becomes more affordable over time. Most businesses benefit most from a combination of both, with paid advertising bridging the gap while building your own inventory.
Because everything around you is constantly changing. Competitors are publishing, search engines are continuously adjusting their rankings, and the results page itself is constantly evolving: cards, direct responses, and other sections push the actual results down. Therefore, a ranking is not a fixed position, but a snapshot in time. The development over several months is more meaningful than the ranking itself.
From the same publicly accessible sources that search engines draw their data from, but with a different weighting. They favor content that answers a question directly and completely, is clearly structured, and can be unambiguously attributed to a specific author. Those who present their content in such a way that a machine can summarize it without further input will also be cited. This is why questions and answers appear here in this format.
It answers questions that your service pages can't, without becoming cluttered. Every good article is an additional entry point to your website for a search query that otherwise wouldn't have led anyone to you. The prerequisite is substance. Four well-thought-out articles a year are more effective than forty that consist of common knowledge.
It depends on who is listed as the owner, not who pays for or manages it. If the agency is listed there, it effectively belongs to them, and a change can be problematic. Your company should always be listed as the owner, even if technical support is provided by a service provider. This can be checked in a few minutes and is one of the most important safeguards you can have.
With proper preparation, no. The process is always the same: the site is fully built and tested on the new environment while the old one continues running, and only then is the switchover performed. The network migration then takes some time, during which both environments must be accessible. Outages almost never occur due to the migration itself, but rather because the old environment is shut down too early.
It doesn't become available immediately, but goes through several stages. First, it's simply inaccessible, then there's a grace period during which reactivation is possible but expensive, and only after that is it available to everyone. The damage is rarely the fee itself, but rather the website and email outage on a day when no one expects it. Therefore, the expiration date should be monitored, not just remembered.
The problem isn't with the technology, but with the content and decisions. The most frequent cause of delays is missing texts, images, and approvals, or because no one in the company is authorized to make final decisions. The second most frequent cause is the project's scope expanding unnoticed during the course of the project. Both of these issues can be mitigated beforehand: with a dedicated contact person on the client side and a clearly defined scope.
The part most people underestimate. The first few weeks reveal what no one saw in the preview: unexpected paths through the site, forms used differently than anticipated, content searched for more often than expected. A website isn't finished when it goes live; it's the first time it becomes measurable. That's precisely when the real work begins.
Open question?
Ask us directly.
Your question isn't listed here yet? Write it to us, we'll answer personally and add it to this collection if it comes up frequently.