Frequently asked questions

We always proceed in a structured way: we first check whether the error comes from the system itself (core), from a plugin or from the theme, and whether it coincides with a change (update, hosting switch, PHP change). We then back up the current state, analyse server and system logs and narrow down the source of the error reproducibly. The aim is to make the site stable and accessible again quickly, without side effects (e.g. data loss or consequential damage to functions).

For admin login/dashboard problems, we check the complete chain: hosting status, PHP/MySQL availability, Joomla configuration, database permissions and typical timeout/limit problems. We work in such a way that no data is overwritten and the cause is identified cleanly. At the end we document what the cause was and which adjustment brings lasting stability.

We start with a short change analysis (what was updated and when), check the server context (PHP version, limits, caching) and then analyse the technical clues (logs/error patterns). This is followed by controlled narrowing down until it is clear which component is causing the failure. We pay particular attention to ensuring that existing content, shop functions and form processes are not damaged.

In such cases we don't work “on the open heart”, but with a clear backup and comparison strategy: we record the current state, check versions and dependencies and reconstruct how the error occurs. We then assess whether a targeted correction, a clean patch concept or a compatible alternative is the most sustainable approach. Changes are documented in a traceable way so that nothing gets “lost”.

We first check whether the problem comes from the theme itself, from page builder rules, from plugin CSS or from caching/minification. We then define which breakpoints/devices are relevant and implement adjustments so that updates remain stable and the layout doesn't collapse elsewhere. The result is a consistent display on smartphone and tablet, including a clean test procedure.

We always work with a safe process: a backup beforehand, controlled analysis, only targeted changes, followed by validation (content, links, search functions, shop/orders). Depending on the case, we use the hosting's database and admin tools as well as proven procedures within WordPress, always with a focus on data integrity. We document every relevant change so that it remains traceable.

We narrow down the problem via the server environment, Joomla version, plugin dependencies and typical conflict patterns. To do this, we check system messages and logs, compare installation states and assess whether the error is caused by incompatibility, limitation or faulty initialisation. We then implement a solution that remains update-capable in the long term instead of just “suppressing it briefly”.

We first check which function is specifically affected (frontend, backend, checkout, forms, custom functions) and whether it is an update conflict, a changed dependency or a cache/optimisation problem. We then restore the function in a controlled manner and check whether other processes (e.g. emails, tracking, payment methods) are also affected. At the end there is a clear final report with cause and measures.

We recommend immediate, orderly action: first stabilisation and damage limitation, then securing evidence and analysis, followed by cleanup. We prioritise ensuring that the site does no further harm (visitors, SEO, reputation) and that we trace the attack path so that the problem doesn't return straight away. To carry out the work, we always need the complete login details (website, hosting, FTP – if available).

We work in a fixed process: analysis of the infection pattern, identification of compromised files/entries, cleanup at file and database level, validation of the core functions and final hardening. We make sure that no hidden mechanisms (e.g. scripts that load further code) remain and that the site is update-capable and stable afterwards.

We first eliminate the technical cause (infection/backdoors/spam), then check whether the site is clean and stable, and then prepare the necessary evidence/steps for a new review. It is important to us that not only the warning disappears, but that the cause is completely removed so that the site isn't listed again.

We assess backups according to whether they date from before the compromise and whether they are complete (files + database). We also check whether the backup already contains malicious changes. The aim is a restore that doesn't just “seem to work” while unknowingly bringing the hack back.

We rely on a multi-level security concept: updates/compatibility, permissions, access protection, server-side protection, attack path reduction and monitoring approaches. In addition, we check typical shop risks (checkout, payment methods, admin access) and make sure that the measures remain practical and don't hinder operations.

We don't just remove visible content, but also check the cause: compromised users, manipulated editor mechanisms, database injections or permission problems. We then clean up in a structured way and make sure that the point of entry is closed. Finally, we check whether other areas (menus, modules, metadata) are affected.

The report contains a clear summary of the findings (type of infection), the affected components, the measures taken in a traceable order, as well as notes on login details, updates, prevention and monitoring. We write it in such a way that it is understandable for non-technical people too and can be used internally as evidence.

We work with a combination of pattern recognition, behavioural analysis and systematic review of critical areas. The aim is not just to remove “the obvious”, but to find persistent backdoors that reactivate themselves after a short time. This is followed by hardening that is tailored precisely to the actual point of entry.

We base this on security relevance, update type (major/minor/security), the plugins/themes used and the criticality of the website (e.g. shop vs. pure company website). Our maintenance approach minimises risk: preliminary check, controlled execution, follow-up check and documentation. The aim is maximum security with minimal risk of downtime.

We treat this as a stability problem: we check why the state got stuck (update process, permissions, caching, limits) and then restore clean normal operation. It is important to us not only to remove the visible effect, but also to clarify the cause so that it doesn't happen again.

We regularly check the system status, update situation, anomalies in logs, user/permission constellations and typical attack surfaces (plugins, templates, external integrations). We also look out for early warning signs such as unusual performance peaks, changed files or suspicious content. The aim is to detect problems before they visibly escalate.

We rely on a combination of systematic checks after updates and monitoring approaches (error patterns, function checks, server-side signals). What matters is that relevant business processes (contact, checkout, emails) are actively checked, not just whether “the page loads”. Anomalies are documented and dealt with according to priority.

We check layout stability, module positions, navigation, responsive behaviour and critical functions such as forms, search and shop elements if applicable. We also check loading times and console/error messages, because template updates often create interactions. The result is a reliable statement on whether the update went cleanly.

We check whether the form triggers technically, whether delivery works reliably, whether spam protection is effective and whether error cases are handled correctly. We also check whether form events conflict with tracking/CRM processes, if present. The aim is a contact channel that is really reliable in everyday use.

We work with a controlled process: assessment of update relevance, compatibility check, execution in an orderly sequence and subsequent function checks. We also make sure that critical components are not updated blindly, but with a safe procedure that prevents outages and ensures traceability.

We immediately prioritise stabilisation and availability, narrow down the cause and safeguard the functionality of the most important processes. We then decide whether it is a follow-up to maintenance (compatible correction) or a separate issue (e.g. a fundamental conflict, technical legacy). In any case, we document transparently what happened and how we secured it.

We start with a root cause analysis, because “slow” can have many sources (database, images, theme, plugins, server, external scripts). Only when it is clear where the bottlenecks are do we optimise in a targeted way instead of “tuning” across the board. With the database, we pay particular attention to stability, clean structures and making sure shop/form processes are not affected.

We never choose caching across the board, but according to content type, user roles, multilingualism and shop functions where applicable. We check which level makes sense (CMS, server, CDN) and whether dynamic content is handled correctly. The aim is measurably faster loading times without content being delivered incorrectly or functions being “frozen”.

We work on the typical main drivers in shops: rendering, script load, image/font strategy, caching, database access and third-party integrations. What matters is that product pages, category pages and the checkout are consistently fast, not just the homepage. We measure before/after and deliver traceable results.

We check image sources, formats, delivery, sizes, lazy loading strategy and whether the theme scales correctly. We then implement the optimisation in such a way that quality is preserved and the site doesn't “break” (e.g. incorrect cropping). The aim is a clean balance between image quality and loading time.

We first check real bottlenecks (timeouts, memory, CPU, I/O, database latency) and only adjust settings in a targeted way, to suit the Joomla version and extensions. We pay attention to stability and avoid settings that help in the short term but cause errors or security problems in the long term.

We analyse which assets are actually used, which come from plugins/themes and what is just “loaded along”. We then reduce the ballast in such a way that updates remain possible and no functions are lost. The aim is a lean frontend with stable maintainability.

We check whether the load is caused by caching deficits, database bottlenecks, bot traffic or resource limits. We then implement measures that absorb load peaks without restricting the site's functionality. It is important to us that the solution fits the hosting setup and the business model.

We work with clear before/after measurement points: real page views (important templates), Core Web Vitals, loading times, server response times and function checks. We also document the changes so that the development remains traceable and later updates don't unnoticeably make things worse again.

Yes, if it is done in a controlled way. To do this, we check the WordPress core, plugins, theme, shop components and server-side modules for compatibility and choose a process that minimises downtime. Clean testing of critical processes (login, forms, checkout, emails) and traceable documentation are important.

After migrations, we systematically check typical consequences: paths, permissions, rewrite environment, PHP modules, caching and absolute references. We then implement corrections so that the installation works stably again and search engine, email and redirect issues are properly taken into account.

We first check whether WordPress becomes unstable due to limits (memory/timeout), I/O, database parameters or caching conflicts. We then adjust settings in a targeted way to suit the hosting stack. The aim is stable operation under normal load and during peaks, without constantly having to “fight fires”.

We assess the current state (versions, extensions, hosting limits, security situation) and stabilise step by step: first operational reliability, then modernisation, then protection. We treat outdated installations with particular care, because changes can often trigger chain reactions.

That depends on the state of the code, the manufacturer's maintenance and dependencies. We check which components are cleanly compatible and where adjustments are needed (e.g. deprecations, outdated libraries, stricter typing). We then decide whether an update, patch or replacement is the most sustainable option.

We first check the basics: PHP/DB versions, modules, permissions, paths, caching, DNS/SSL and differences in the server stack. We then narrow down the source of the error and stabilise operations. The focus is on making sure the site runs reliably over the long term afterwards, not just “for now”.

We check whether these are real memory bottlenecks or whether a plugin/template is drawing unusual resources. We then decide whether server-side adjustment, structural optimisation or compatibility work is needed. The aim is stability without “oversized” settings as a permanent sticking plaster.

We start with structure and target group logic (sitemap, page types, content), then set up a clean technical foundation and build the design and components with mobile use in mind from the start. This is followed by performance basics, a GDPR foundation, form flows and an orderly go-live check. The result is a maintainable, fast and clear company website.

We take into account the usual basic GDPR topics: privacy policy/legal notice structure, cookie/consent logic (depending on the setup), clean integration of external services and technical foundations that avoid unnecessary data outflows. The aim is a practical basis that can be properly extended later.

We set up a clear page structure, clean URL logic, a basic meta concept and technically clean indexing. We build in schema/structured data so that it fits the site (organisation, LocalBusiness, website, products/services where applicable). The result is a solid foundation, without “SEO tricks”, but with clean technology.

We pay attention to robust delivery, clear validation and effective spam protection without slowing down genuine enquiries. We also check that sending paths (SMTP/hosting) are reliable and that form flows really work in everyday use. The aim: less spam, no lost leads.

We deliver a basic technical configuration that suits the site: cache-capable, stable, update-friendly. For images, we pay attention to sensible formats, sizing logic and delivery. The setup is chosen so that it doesn't work against content/plugins later on, but grows with them cleanly.

Before go-live we systematically check: page views, navigation, forms, responsive behaviour, SSL, indexing, performance basics and typical error patterns. After go-live there is a short real-world check so that no consequences of the switch (DNS, cache, certificates) go unnoticed.

That depends on how much is customised and how update-proof it needs to be. We always plan customisation in such a way that later updates don't overwrite the changes. The aim is a solution that remains maintainable and doesn't have to be “rebuilt” with every update.

We first structure the shop from a business perspective (categories, attributes, product logic, variants), then set up the technology cleanly (checkout, emails, shipping/tax logic, legal text structure) and then test the complete ordering process. The aim is a shop that is not just “online”, but sells reliably and remains manageable.

We work in a migration-safe way: inventory, data model comparison, controlled export/import, checking the resulting data (products, customers, orders, media, URLs) and subsequent function validation. The aim is to ensure data integrity and traceability, especially for order history and customer accounts.

We integrate common payment providers, tailored to the target market, risk requirements and shop setup. For us it's not just about “installing a plugin”, but about a clean, stable checkout process including test cases and correct email/status logic.

We first check whether it is a theme/plugin conflict, a cache/optimisation issue or a change in WooCommerce itself. We then narrow it down reproducibly and make the cart/checkout stable again. It is important that no consequential damage occurs afterwards (e.g. incorrect taxes, shipping logic, payment status).

We analyse the template, shop queries, image/asset strategy and server context and optimise where the biggest bottlenecks are. The aim is faster category and product pages and a stable checkout, without over-optimising and breaking dynamic shop functions.

We first clarify whether custom fields need to be linked to products, variants, orders or customers. We then implement this so that it remains update-capable, is stored cleanly and can be used correctly in the frontend/backend. It is important that shop processes (search, filters, export, checkout) do not become unstable as a result.

Yes. We start with a clear functional description, data flow (where do leads come from, where should they go), roles/permissions and security requirements. We then develop the plugin so that it remains update-capable, maintainable and performant. At the end we deliver clear documentation so that the system can be operated in the long term.

We first define which data flows in which direction, which authentication is required and how error cases are handled. The connection is then set up so that it is robust and traceable (logging, rate limits, retry logic). The aim is an integration that doesn't fail with every small API change.

We work with update-proof methods: clear separation of the core theme and customisations, clean overrides/custom structures and documented changes. The aim is that updates remain possible without design customisations being overwritten or scattered “wildly” across the system.

We first check whether WordPress standards (post types/meta/taxonomies) are sufficient or whether a real table structure is required. We then implement changes so that they are migration-capable, versioned and traceable. Data security and performance always come first.

We define data models, endpoints, authentication, the permission concept and security measures. We then build the connection so that it works stably under real load and can be monitored properly. The result is a controllable link instead of a fragile “DIY job”

We first analyse at which point in the process the intervention should take place (product, cart, checkout, email, shipping, payment status). We then implement the extension so that it is update-proof and doesn't conflict with other plugins. The aim is a clean extension that remains maintainable in the long term.

We first check which services actually transfer data (analytics, maps, fonts, videos, chat, tracking). We then implement a consent concept that works cleanly from a technical point of view and doesn't just “show a banner”. The aim is that consents actually control what is loaded and that the implementation remains stable in everyday use.

We don't choose headers across the board, but to suit the system and the integrated services. The aim is a security gain without breaking functionality (e.g. with iframes, APIs, payment, tracking). We document the configuration in a traceable way and make sure it can be tested cleanly.

We identify which resources are still embedded from insecure sources (theme, plugins, content, external scripts) and correct this in a structured way. The aim is completely clean HTTPS delivery without browser warnings and without side effects on caches/optimisers.

Yes, we set up backups so that they are complete, reliable and can be restored quickly in an emergency (files + database, sensible rotation, secure storage). What matters is not just “a backup exists”, but that it can be restored and is protected against manipulation.

We check the most important WCAG/BITV-relevant points: contrast, keyboard operability, semantics/structure, form labels, focus management, alternative texts and typical template problems. We then implement measures that are practical in everyday use and properly documented so that the site remains compliant in the long term.

We check which external resources are loaded and whether this makes sense from a data protection and technical point of view. We then establish local, stable embedding that reduces loading times and GDPR risks without breaking the layout or functions.

We plan migrations with controlled switchover logic: preparation of the target environment, complete transfer, function check, DNS/switchover window and follow-up check. The aim is a clean transition with minimal risk to availability, emails, forms and shop processes.

We always look at domain moves holistically: website, DNS, SSL, email routing as well as redirects/indexing. The aim is that emails continue to work reliably and that search engines/links don't end up nowhere. After completion, we check all critical paths in a clear acceptance check.

Yes, if it is modelled cleanly. We check content, media, structures, special types, URL logic and SEO relevance and then plan the transfer so that content is mapped correctly. The aim is not just “the text is there”, but that structure, linking and findability remain stable.

We carry out a systematic final check: availability, SSL, performance basics, backups, forms, emails, admin areas, logs and critical business functions (shop/tracking). The result is a documented state that serves as a basis for acceptance.

Yes, we migrate emails in a structured way, including folder structures and delivery logic, and then check that sending/receiving runs stably. It is important to us that clients (Outlook/Apple Mail/mobile) also work properly afterwards and that no silent delivery problems occur.

We first clarify which data is collected, how double opt-in is implemented and how forms/tracking are integrated cleanly. We then integrate the system so that it is practicable under GDPR and runs stably from a technical point of view. The aim is a clean lead process instead of just “plugin installed”.

We first define the requirements (single dates, series, categories, tickets, frontend submission, moderation) and then set up the calendar so that it remains maintainable and is cleanly integrated into the template. We then check typical cases such as mobile view, searchability and performance.

We always build multilingualism with structure: language logic, URL concept, translation workflow, media/SEO and plugin compatibility. The aim is a system that isn't “different on every page”, but works consistently and remains maintainable in the long term.

We first clarify which roles, moderation logic, anti-spam measures and data protection requirements are needed. We then integrate the forum so that it remains technically stable, secure and maintainable, including a performance and permissions concept.

We integrate tracking so that it measures correctly from a technical point of view but is also embedded in a GDPR-compliant way (consent logic, loading only after consent, clean tag strategy). The aim is reliable data collection without compliance risk

We structure content so that it makes editorial sense and is technically clean: clear content types, fields, taxonomies, templates and maintenance processes. The aim is a site that grows without becoming confusing and that can be cleanly extended for SEO/schema.

We start informally by email. To carry out the work, we always need all login details for the website, the hosting/server and – if available – FTP. After the project is completed, we deliver a detailed report and ask you to check it within a week.

We narrow down the scope based on the current situation and the goals and then draw up a clear fixed-price quote. If an issue only turns out to be bigger during the analysis, we communicate this transparently before continuing.

For technical problem solving in WordPress and Joomla, for cleaning hacked websites and for clean, stable setups without agency waffle. We work in a structured way, document properly and deliver results that are maintainable in the long term.

We have over 300 Google reviews and over 500 5-star reviews on ProvenExpert. Our work is strongly driven by recommendations and geared towards sustainable technical quality.

We work with fixed-price quotes so that the costs are clear in advance. Our hourly rate is €85 net.