What is it? srcset is an HTML attribute that lets the browser pick the right one from several image sizes, depending on screen size and pixel density. This way, images are delivered sharp and at the right resolution – even on high-resolution HiDPI or Retina displays.
Why it matters before go-live: Without suitable resolutions, images look blurry on Retina displays or get scaled with distortion; images that are too large, on the other hand, slow down load time. Used correctly, srcset delivers sharp images with good performance.
How to set it up:
Upload images at a sufficiently high source resolution so WordPress can generate enough intermediate sizes for srcset.
Insert images through the media library, because WordPress then sets srcset automatically – instead of hard-coded <img> tags without responsive sizes.
In Elementor, choose a suitable image size for each widget (not simply “Full”) and set the aspect ratio correctly to avoid distortion.
Adjust the registered image sizes if needed and regenerate them with a plugin like Regenerate Thumbnails.
Check on the live site in DevTools that srcset and sizes are set and that the right resolution is loaded.
Add modern formats (WebP/AVIF) and compression with an optimization plugin to balance sharpness and load time.
Performance
Why upload images at the right size?
Problem: Images are often uploaded much larger than they're displayed (e.g. 4000 px in a 600-px slot).
Why it matters: Every oversized image wastes load time and visitors' data.
How to fix it:
Check the display width in the browser (right-click → Inspect)
Scale the image to about twice the display width (for sharp Retina displays)
What is it? Images can be compressed more or less heavily when they're saved. Many photos and graphics sit on the server at the highest quality setting, even though you can't see the difference on screen. This check shows how much file size could be saved without any visible loss in quality.
Why it matters: On most websites, images make up the largest share of the data that has to load. Unnecessarily large files slow down loading – especially on mobile and on weak connections – and use up your visitors' data.
How to fix it:
Export photos at a quality setting of about 75–85 % before uploading, e.g. with the free online tool Squoosh or the export dialog of your image editor.
Recompress images you've already uploaded in bulk – for example with an image optimization plugin for your CMS or the image optimization offered by your host or CDN.
Choose a modern format like WebP or AVIF right away – that saves even more.
Limits of the check: Only the images on the checked page are measured. Subpages with galleries may have considerably more savings potential.
What is it? Lazy loading means “load on demand”: the browser only fetches images and videos further down the page when someone scrolls there. This check flags images outside the visible area that are still loaded immediately when the page opens.
Why it matters: Without lazy loading, the browser has to load every image on the page up front – including the ones many visitors never get to see. That slows down how fast the visible page appears and costs data.
How to fix it:
Give images below the first screen the attribute loading="lazy". Many systems already do this automatically – WordPress, for example, since version 5.5.
Explicitly do not lazy-load the large image at the very top (title or hero image) – otherwise the most important element shows up later.
Check sliders, background images and embedded videos separately: loading="lazy" only works on regular images and iframes. Themes, page builders or optimization plugins often have their own option for this.
Problem: LCP (Largest Contentful Paint) measures when the largest visible element – usually the hero image – finishes loading. Good is under 2.5 s.
Why it matters: A slow LCP makes the page feel like it's stalling and costs you ranking and visitors.
How to fix it:
Deliver the hero image as WebP and in the right size
Preload the LCP image (<link rel="preload">) instead of delaying it with lazy loading
Improve server response time and caching
In detail
LCP measures when the largest visible element finishes loading – usually the hero image or a large heading. Visitors feel the page has “arrived” as soon as this element is in place.
Step by step:
Deliver the large image as WebP and in the right size (no 4000-px image for a 1200-px slot).
Preload the LCP image (<link rel="preload">) and do not delay it with lazy loading.
Improve server response time and caching (see TTFB).
Rule of thumb: under 2.5 s = good, 2.5–4 s = needs improvement, above that = poor.
Problem: CLS (Cumulative Layout Shift) measures how much content shifts around while loading. Good is a value under 0.1.
Why it matters: Jumping buttons and text lead to mis-clicks and feel unpolished.
How to fix it:
Specify a fixed width/height for images and videos so space is reserved
Set fixed container heights for ads/embeds
Load fonts with font-display:swap to avoid jumps
In detail
CLS happens when content is still shifting while loading – e.g. an image without reserved space pushes the text down, right as you're tapping a button.
Common causes & fixes:
Images/videos without dimensions → always specify width and height, so the browser reserves the space.
Ads/embeds → set a fixed container height.
Web fonts → load with font-display:swap so there's no line-wrap jump.
Problem: TBT (Total Blocking Time) measures how long the page fails to respond to input while loading – caused by heavy JavaScript.
Why it matters: A high blocking time makes the page feel sluggish, with clicks and scrolling lagging.
How to fix it:
Remove unnecessary JavaScript
Split scripts and load them with defer/async
Reduce third-party scripts (chat, tracking)
In detail
While loading, the browser executes JavaScript. As long as a script is running, the page does not respond to clicks or scrolling – these wait times add up to the blocking time.
Remove unnecessary JavaScript (chat widgets, old plugins, duplicate trackers).
Load scripts with defer or async so they don't block the page from rendering.
Split large scripts so the browser can respond to input in between.
TTFB is made up of several wait times: DNS resolution → connection setup → the time the server needs to generate the page. The last part is usually the biggest lever.
Step by step:
Set up a page cache: it stores the finished page instead of rebuilding it from the database on every visit. In WordPress, LiteSpeed Cache (free) or WP Rocket handle this.
Choose a fast host with an up-to-date PHP version – this noticeably shortens generation time.
Put a CDN in front (e.g. Cloudflare): it delivers content from a server near the visitor, shortening the distance.
Rule of thumb: TTFB under ~200 ms is good, from ~600 ms onward you should take action. You can measure it with PageSpeed Insights.
Performance
Removing unused CSS
Problem: Many themes and plugins load CSS that isn't needed on the page at all.
Why it matters: Unnecessary CSS makes the page bigger and delays rendering.
What is it? Before the browser can display anything, it has to fully load certain CSS and JavaScript files. If these files sit in the head of the page and are included without any extra attribute, rendering waits until all of them have arrived – they “block rendering”.
Why it matters: Every blocking file adds to the time before visitors see anything at all. On phones in particular, the page stays blank at first even though it's already loading in the background.
How to fix it:
Load JavaScript that isn't needed right away with defer or async.
Load only the CSS for the first visible area early (“critical CSS”), load the rest afterwards and remove unused stylesheets.
Cut down on external fonts and third-party scripts. Many caching and optimization plugins or build tools handle steps 1 and 2 with a setting.
Important: Check the display after every change – deferring too aggressively can break the layout or features such as menus and forms.
What is it? Web fonts are typefaces the browser first has to download. Without the right setting, it doesn't show the text until the font has arrived – this is known as “invisible text”. This check verifies whether fonts are included with font-display, so that text appears immediately in a fallback font.
Why it matters: Invisible text makes the page look empty and delays the moment visitors can start reading. On a slow connection, this can take several seconds.
How to fix it:
Add font-display: swap to the @font-face rule. Many themes and page builders offer a setting for this (“Font Display: Swap”).
Host fonts yourself where possible and only load the weights you actually use, e.g. Regular and Bold instead of the whole family.
Request the most important font early with <link rel="preload">.
Note: When the fallback font is swapped for the web font, the layout may shift briefly. A fallback font of similar width keeps this to a minimum.
What is it? The DOM is the blueprint the browser builds from a page's HTML – every section, every container, every line of text is an element in it. This check counts these elements. As a rough guide: the measuring tool Google Lighthouse flags pages with more than about 1,400 elements.
Why it matters: The more elements there are, the more the browser has to build, calculate and redraw. That costs load time and memory and makes the page more sluggish when clicking and scrolling – especially noticeable on older phones.
How to fix it:
Reduce nesting: page builders often create containers inside containers. Build sections with fewer levels, e.g. with modern flex or grid containers.
Slim down large blocks: huge menus, sliders with many slides, endless lists and duplicated content (one version only for mobile, one only for desktop) cost a particularly large number of elements.
Load content that's only needed on demand – such as comments or long lists – later instead of writing all of it into the HTML.
Limits of the check: The value applies to the checked page. Other pages on your website may be considerably larger.
What is it? By default, WordPress reveals the login names of registered users through the REST API (/wp-json/wp/v2/users) and through author links (?author=1). This enumeration makes it possible to systematically read out a site's valid usernames.
Why it matters before go-live: If an attacker knows the real login names, all that's missing for a brute-force attack is the password – half the work is already done. Before go-live, this unnecessary exposure of login names should be shut down.
How to set it up:
Check whether the names are visible: open /wp-json/wp/v2/users in the browser and append ?author=1 to the domain.
Restrict the public REST endpoint for users – with a security plugin (e.g. Wordfence, Solid Security) or with a code snippet that blocks unauthenticated access to /wp/v2/users.
Block or redirect ?author= requests, for example with a rule in .htaccess or via the security plugin.
Set display names/nicknames that differ from the login name, so the author name and the login aren't identical.
After the change, check again that the endpoints no longer return any login names.
Security
Trusted plugin and theme sources
What is it? Plugins and themes should only come from trusted sources – the official WordPress directory (wp.org), licensed vendors or your own or your agency's repository. So-called nulled (pirated) extensions are premium plugins offered for free that have often been tampered with.
Why it matters before go-live: Pirated extensions or ones downloaded from unknown sources often contain hidden malicious code, backdoors or spam injections, and they don't receive security updates. A single plugin like that can compromise the entire website and the server – this has to be ruled out before go-live.
How to set it up:
Take inventory of all installed plugins and themes and check for each one whether it has a traceable, legitimate origin (wp.org, vendor account, purchased license).
Remove nulled/cracked extensions and plugins from dubious download sites and replace them with the official, licensed version.
Completely delete unused, deactivated or no longer maintained (abandoned) plugins and themes – don't just deactivate them.
Enter valid licenses for premium extensions so that automatic security updates work.
Briefly vet new extensions before installing them (ratings, last update, active installations, compatibility) and, if in doubt, check them with a malware scanner like Wordfence.
Security
Encrypted handover of credentials
What is it? During the credentials handover, the client receives all login details for their website – WP admin, hosting account, DNS management and backup destination. “Encrypted” means this data isn't sent openly by email but through a protected channel.
Why it matters before go-live: Passwords sent in plain text by email can be intercepted, stay in mailboxes indefinitely and are a common point of entry. An encrypted handover protects the logins and also makes for a clean, traceable project wrap-up.
How to set it up:
Collect all relevant logins in full (WP admin, host/server, DNS/domain, backup destination, plus email and plugin licenses if applicable).
Never send login details in plain text by email or chat; where it can't be avoided, send the username and the password through separate channels.
Create individual accounts for the client instead of shared logins, and remove your own service-provider accounts once the project is finished.
Ask the client to change the most important passwords after the handover and to enable two-factor authentication.
Security
Error 403 – my site is protected by a bot firewall
Problem: The Web-Check fetches your page automatically from a server. If a bot firewall (e.g. Cloudflare, Sucuri) protects the page, it rejects such requests with “Error 403” – even though the page loads perfectly in a normal browser.
Why it matters: This isn't an error on your site and it isn't a bad sign – good bot protection makes sense. It just prevents testing tools from analyzing the page from the outside.
How to proceed:
Measure the page with a tool that works from a real browser – e.g. Google PageSpeed Insights or Chrome DevTools (Lighthouse).
Do you run the site and want to use our Web-Check? You can set up an exception for the check in the firewall – in Cloudflare, for example, a “Skip” rule for the user agent WM-Web-Check (our check honestly sends it on its first attempt). Ask your administrator or us about it.
Or let us check the page manually once – just drop us a line.
Recommended tool: Google PageSpeed Insights (measures from a real browser)
Problem: Missing HTTP security headers allow attacks like clickjacking.
Why it matters: Headers like HSTS, X-Content-Type-Options, and CSP harden the site against common attacks.
How to fix it:
Have your current headers tested
Add HSTS, X-Frame-Options, and X-Content-Type-Options via plugin or server
Retest until the rating is right
In detail
Security headers are small instructions your server sends with every page. They tell the browser how to behave to protect visitors. The most important ones:
HSTS – forces the site to always load over HTTPS.
Content-Security-Policy – allows only trusted sources for scripts, images & styles.
X-Content-Type-Options: nosniff – prevents file types from being misinterpreted.
X-Frame-Options – protects against clickjacking (embedding in other sites).
Referrer-Policy & Permissions-Policy – control origin data and browser features (camera, location …).
They’re set server-side – via server configuration, .htaccess, or a security plugin like Wordfence. Then double-check with SecurityHeaders.com (goal: grade A).
Problem: The issuer is the authority that issues an SSL certificate – often Let’s Encrypt (free and widely used).
Why it matters: A trusted issuer ensures browsers accept the connection without a warning.
How to fix it:
Let’s Encrypt is completely sufficient for most websites
Only use a paid certificate for special requirements
Make sure automatic renewal is on
Security
Providing security.txt (optional)
Problem: A file at /.well-known/security.txt names a contact for security reports.
Why it matters: It makes it easier for security researchers to reach you responsibly when they find a problem.
How to fix it:
Create a security.txt file with one line: Contact: mailto:security@your-domain.com
Place it at /.well-known/security.txt
Optionally add an expiration date (Expires)
In detail
The security.txt is a standardized text file (RFC 9116) at /.well-known/security.txt. It names a contact that security researchers can report discovered vulnerabilities to – responsibly and without detours.
Example:
Contact: mailto:security@your-domain.com
Expires: 2027-12-31T23:59:59Z
Preferred-Languages: de, en
Contact – required: email or form for security reports.
Expires – expiration date; after that the file is considered outdated.
Optional: Encryption (PGP key), Policy (link to policy).
The file is optional, but a sign of professionalism – especially for shops and services handling user data.
Security
Closing open directory listing
Problem: If directory listing is enabled, the server displays the entire file contents of folders without an index file.
Why it matters: An open listing exposes internal files and structure.
How to fix it:
Disable listing in the server configuration (Options -Indexes)
Problem: Cookies without protective flags can be intercepted or misused for attacks.
Why it matters: Secure (HTTPS only), HttpOnly (no JavaScript access), and SameSite (protection against CSRF) harden cookies.
How to fix it:
Set Secure and HttpOnly for session/login cookies
Set SameSite to Lax or Strict
Configure via server/plugin and check in the browser (DevTools → Application → Cookies)
SEO
How do I optimize the title and meta description?
Problem: Missing or generic titles and descriptions cost clicks in the search results.
Why it matters: They're your ad copy in Google – they decide whether someone clicks.
How to fix it:
Write a unique title (under 60 characters) with your main keyword for each page
Write a description (under 155 characters) that invites the click
Use an SEO plugin (Yoast or Rank Math) and check the snippet preview
In detail
The title and meta description are what appears in Google as the search result – basically your free ad.
Example:
Title (up to ~60 characters): Custom Wood Stair Treads for Your Staircase | Holzstufen24
Description (up to ~155 characters): Configure perfectly fitted wood stair treads online – high-quality materials, fast delivery. Calculate your custom size now.
Every page gets its own title with the most important keyword up front. An SEO plugin like Yoast or Rank Math shows you a live preview of the snippet.
SEO
How do I structure headings (H1-H3)?
Problem: Multiple or missing H1 headings confuse search engines.
Why it matters: A clear hierarchy helps ranking and readability.
How to fix it:
Use exactly one H1 per page
Structure subtopics as H2, details as H3
Work keywords naturally into the headings
In detail
Headings aren't just large text – they give your page a structure, like a book's table of contents. Search engines and screen readers use them to understand how your content relates.
H1 – the page's main heading. Only one per page; it names the main topic. Example: “Custom Wood Stair Treads”
H2 – the major sections underneath. Example: “Materials”, “Pricing”, “Installation”
H3 – subpoints within an H2 section. Under “Materials” e.g. “Oak”, “Beech”
What matters is the order without skipping levels: an H2 is followed by an H3, not directly by an H4. Common mistake: choosing a heading just to make the text look bigger – use regular formatting for that instead, and keep the structure logical.
SEO
What is Google Search Console for?
Problem: Without Search Console, you can't see how Google actually sees your site.
Why it matters: It shows indexing, errors, and the search terms people find you through.
What is it? Technically, a WordPress website can usually be reached under several host variants, for example with www and without www. The canonical domain defines the one variant that serves the content, while all others redirect to it with a permanent (301) redirect.
Why it matters before go-live: If several variants are reachable at the same time, Google sees the same content under different addresses (duplicate content) and splits the ranking signals across several URLs. Set before go-live, the canonical domain concentrates visibility and prevents contradictory internal links.
How to set it up:
Choose one variant (with or without www) and use it consistently everywhere.
In WP admin, enter the chosen address under Settings > General in “WordPress Address (URL)” and “Site Address (URL)”.
Set up a 301 redirect from the other variant to the chosen one – via .htaccess (Apache), a server block (Nginx) or a redirect plugin.
Also enforce https so that all four combinations (http/https, www/non-www) end up at a single target URL.
Check in the browser and with an HTTP header checker that the redirects actually return status 301 and don't loop.
What is it? hreflang is an annotation in the HTML head or the XML sitemap that tells Google which audience each language or country version of a page is intended for. It's only relevant if a website offers content in several languages or for several countries.
Why it matters before go-live: Without correct hreflang annotations, Google may show the wrong language version in search results or treat different versions as duplicate content. Set up properly before go-live, it makes sure visitors reliably land on the language version that suits them.
How to set it up:
First, clarify whether the site is multilingual at all; if it only has one language, you don't need hreflang.
Add hreflang annotations on each page for every language version, including an entry that points to the page itself.
Use correct language or country codes (e.g. “de”, “de-AT”, “en”) and add “x-default” for the fallback version if needed.
Make sure all versions reference each other (bidirectional linking) – otherwise Google ignores the annotations.
Depending on your setup, maintain hreflang automatically with a multilingual plugin (e.g. WPML, Polylang) or add it manually to the page head or the sitemap.
Check the result with an hreflang testing tool and keep an eye on Google Search Console.
SEO
404 error page
What is it? A 404 error page is shown when a requested address doesn't exist. What matters is that the server sends the real HTTP status code 404 and shows visitors a branded, helpful page with a clear way back.
Why it matters before go-live: If the page returns status 200 despite the error (a “soft 404”), Google keeps dead addresses in its index and wastes crawl budget. A bare or generic error page also makes visitors leave instead of guiding them back into the website.
How to set it up:
Deliberately open a URL that doesn't exist (e.g. your-domain.com/doesnotexist) and check whether an error page appears at all.
Use the browser's developer tools (Network tab) or an HTTP header checker to verify that status 404 really comes back and not 200.
Create a branded 404 template – as an Elementor template via the Theme Builder (404 page) or in the theme via the 404.php file.
Add helpful elements to the error page: a search field, a link to the homepage and the most important menu items.
After go-live, watch for soft 404 reports in Google Search Console and redirect permanently removed pages to a suitable target with a 301 redirect.
SEO
What is structured data (Schema.org)?
Problem: Without structured data, Google understands the context of your content less well.
Why it matters: It enables rich results like star ratings, FAQs, or business hours.
How to fix it:
Choose the right schema type (LocalBusiness, FAQ, Product)
Open Graph tags determine how a shared link looks on WhatsApp, Facebook & LinkedIn – title, description, and preview image.
Example:
<meta property="og:title" content="Custom Wood Stair Treads">
<meta property="og:description" content="Configure it online for a perfect fit.">
<meta property="og:image" content="https://…/preview.jpg">
The preview image should be 1200×630 px in size. After making changes in the Facebook Sharing Debugger, re-scrape the cache, or the networks will show the old preview.
What is it? This check looks up the Google Business Profile that belongs to your domain and reads the average rating and the number of reviews. An average of 4.0 stars or more counts as good.
Why it matters: The stars appear directly in Google Search and Google Maps – often before anyone visits your website. Many people decide based on the average and the number of reviews whether to call or keep scrolling. Only a few reviews, or very old ones, quickly make a business look abandoned.
How to fix it:
Claim your Business Profile and add your website address to it – only then can it be matched to your domain.
Actively ask satisfied customers for a review, e.g. with the direct review link from your profile in your email signature, on your invoice or via a QR code.
Reply to every review, and keep your replies to critical ones factual and friendly. Bought or self-written reviews violate Google's policies and can get your profile suspended.
Limits of the check: If the check doesn't find a profile, it may also mean that the profile lists a different website address, for example with or without “www”.
Problem: Over half of visitors come from mobile, but the site is built for desktop.
Why it matters: A site that isn't mobile-friendly directly costs you inquiries.
How to fix it:
Check the responsive layout on all devices
Font size at least 16 px, buttons large enough to tap
Go through the mobile view in Elementor section by section
Usability
Dummy text & placeholders
What is it? Dummy text (“Lorem ipsum”) and placeholders are temporary content used as filler during the build: sample texts, dummy images, sample contact details or demo content from theme and Elementor templates. Before go-live, all of it must be replaced with real content.
Why it matters before go-live: If any of these leftovers remain, the site looks unfinished and unprofessional, which spoils the first impression. Wrong placeholder contact details or demo addresses lead to misdirected inquiries or legal problems, for example in the legal notice and privacy policy.
How to set it up:
Go through all pages and posts in WP admin (the “Pages” and “Posts” menus) and search specifically for “Lorem ipsum”, “example”, “sample” and “dummy”.
Check imported Elementor demo templates and layouts, as they often bring placeholder widgets and sample images with them.
Identify demo and sample images in the media library and replace them with real images or delete them.
Check the contact details in the header, footer, legal notice, contact form and theme options for the correct address, phone number and email.
Check buttons, menu items and call-to-action links for placeholder targets like “#” or “example.com”.
Track down any remaining text fragments in the database with a search-and-replace plugin (e.g. Better Search Replace).
Usability
Responsive layout
What is it? A responsive layout automatically adapts to the device's screen size – smartphone, tablet or desktop. Content, images and menus stay readable and usable on every device, without horizontal scrolling or cut-off elements.
Why it matters before go-live: Most visitors now come on mobile, and Google primarily evaluates websites in their mobile view (mobile-first indexing). If the layout breaks on phones, you lose users and search visibility at the same time.
How to set it up:
Go through every page in Elementor using the device switcher in the desktop, tablet and mobile views.
Adjust font sizes, spacing (padding/margin) and the column layout for each breakpoint instead of simply reusing the desktop values.
Switch overly wide elements such as fixed pixel widths, large images or embedded tables and iframes to percentage widths or max-width: 100%.
On real devices or in the responsive view of the browser developer tools (F12), check specifically for horizontal scrolling and cut-off content.
Finally, double-check with Google's PageSpeed Insights in the mobile view and fix any layout problems it reports.
Problem: Light text on a light background is hard to read for many people.
Why it matters: The BFSG (in effect since June 28, 2025) requires good readability – at least 4.5:1 for normal text.
How to fix it:
Check the foreground and background color with a contrast checker
Adjust to at least 4.5:1
Also check buttons, links, and placeholder text
In detail
Contrast is the ratio between text and background brightness. The higher it is, the more readable – especially in sunlight or for people with low vision.
Normal text: at least 4.5:1
Large text (from ~24 px, or ~19 px bold): at least 3:1
Example: Light gray text #AAAAAA on white gives only ~2.3:1 – not enough. Dark gray #595959 on white reaches 7:1 – very good.
Check the foreground and background color with the WebAIM Contrast Checker and adjust the weakest spot. Also think about buttons, links, and placeholder text.
Problem: Images without alt text are invisible to screen readers.
Why it matters: Alt text is required for accessibility and also helps SEO.
How to fix it:
Give every content image a short, descriptive alt text
Mark purely decorative images with empty alt text (alt="")
Manage alt text directly in the WordPress media library
In detail
Alt text describes an image in words – for screen readers and in case an image fails to load.
Good vs. bad:
✗ alt="IMG_2043" or an empty alt on an important image
✓ alt="Oak stair tread with an oiled surface"
Rules: describe the content (don't start with “image of …”); purely decorative images get an empty alt (alt="") so screen readers skip them. Manage alt text in the WordPress media library.
Accessibility
How do I make my site keyboard-operable?
Problem: The site can't be fully operated without a mouse.
Why it matters: Many people navigate using only a keyboard – the BFSG requires it.
How to fix it:
Navigate through the entire site using the Tab key
Make sure there's a visible focus outline
Make all functions (menus, forms) reachable by keyboard
Accessibility
Understanding the overall accessibility score
Problem: The score (0–100) summarizes accessibility criteria that can be checked automatically.
Why it matters: It's a good starting point – but it only covers the part that can be checked by machine; some criteria need a manual review.
How to fix it:
First fix the specific issues flagged (contrast, link text, headings)
Also test manually with a keyboard and a screen reader
Measure again after making changes
Accessibility
Using descriptive link text
Problem: Link text should be understandable on its own – links that just say “here” are a common problem.
Why it matters: Screen readers often read links in isolation – “click here” then says nothing useful. It's also good for SEO.
How to fix it:
Name the destination instead of “here”, e.g. “See pricing”
Avoid bare URL or “more” links
Links with the same text should lead to the same destination
Accessibility
Fixing heading order
Problem: Headings should follow a logical order (H1 → H2 → H3) without skipping levels.
Why it matters: A clean hierarchy helps screen readers and search engines understand the page structure.
How to fix it:
Use exactly one H1 per page
Don't skip levels (no H2 followed directly by H4)
Don't use headings just to make text look bigger
Accessibility
Setting the language attribute
Problem: The lang attribute in the <html> tag specifies the page language.
Why it matters: Screen readers use it to choose the right pronunciation; it also matters for translation.
How to fix it:
Set lang="en" in the <html> tag (WordPress usually does this automatically)
Add a local lang attribute for foreign-language sections
Check that the value matches the actual language
Accessibility
Not disabling zoom
Problem: Some sites block pinch-to-zoom via a viewport setting.
Why it matters: Many people rely on zooming in – blocking zoom is a serious barrier.
How to fix it:
Don't use user-scalable=no or maximum-scale=1 in the viewport tag
Make sure the site stays usable up to 200 %
Test zooming on a smartphone
Accessibility
Labelling buttons clearly
Problem: Every button or control needs a recognizable label.
Why it matters: Icon buttons without text are otherwise empty and unusable for screen readers.
How to fix it:
Label icon buttons with aria-label or hidden text
Use meaningful text instead of just symbols
Double-check with a screen reader
Accessibility
Providing an accessibility statement
Problem: A page that states the current accessibility status and provides a contact for reporting barriers.
Why it matters: Mandatory for public bodies (BITV 2.0); since June 2025 the BFSG also requires it from many businesses with an online offering.
How to fix it:
Create an “Accessibility” page with the current status and a contact
State known limitations openly
Link it in the footer; get legal advice if in doubt
Accessibility
Offering easy language
Problem: Key content also available in easy language.
Why it matters: Mandatory for public bodies – and a clarity boost for all visitors.
How to fix it:
Summarize the most important information (offering, contact) in easy language
Short sentences, clear terms, no complex nested clauses
Link it somewhere easy to find
Accessibility
Providing sign language
Problem: Core content available as a video in German Sign Language (DGS).
Why it matters: Mandatory for public bodies; an important access point for deaf visitors.
How to fix it:
Provide key information as a DGS video
Add captions to the videos as well
Link it prominently on the homepage/accessibility page
Accessibility
Setting form labels correctly
Problem: Input fields without an associated label are unclear to screen readers.
Why it matters: Labels tell you what a field is for – required for accessibility and easier to use for everyone.
How to fix it:
Give every field a <label for> (or an aria-label)
A placeholder is not a substitute for a label
Double-check with a keyboard and a screen reader
AI visibility
How do I make my content machine-readable for AI?
Problem: AI systems have a much harder time understanding unstructured pages.
Why it matters: Schema.org makes content machine-readable and therefore easier to cite.
How to fix it:
Add FAQ, LocalBusiness, or Article markup as JSON-LD
Clearly mark up key facts (name, location, services)
Double-check with the Rich Results Test
In detail
Structured data is invisible extra information in the source code (in JSON-LD format) that clearly tells a machine: “This is a business with an address, opening hours, and a rating.” People don't see any of this – but Google and AI systems do.
Problem: Pure marketing prose without clear statements is rarely cited by AI.
Why it matters: AI systems prefer to draw on precise, directly answered questions.
How to fix it:
Phrase real user questions as headings
Answer briefly and factually right below them
Use lists and tables for clear structure
AI visibility
What is an llms.txt and do I need it?
Problem: Without signposts, AI crawlers can't reliably find your most important content.
Why it matters: An llms.txt file in the root directory points AI directly to your key pages.
How to fix it:
Create a file named llms.txt
Add a title, short description, and links to your key pages
Place it at yourdomain.com/llms.txt
In detail
The llms.txt file is a new, voluntary standard: a Markdown file at yourdomain.com/llms.txt that gives AI systems a curated overview of your most important content – similar to a sitemap, but for AI.
Example:
# Sample Company
> Custom-made wooden stairs from Bavaria.
## Important pages
- [Products](https://yourdomain.com/products/): All stairs & materials
- [Contact](https://yourdomain.com/contact/): Inquiries & consultation
A title (# heading) and a short summary (> quote).
A list of key pages, each with a brief description.
Note: llms.txt isn't read by every AI system yet – but it doesn't hurt, and it positions you early. It does not replace controlling crawler access via robots.txt.
Problem: If everything is wrapped only in <div> tags, your content lacks recognizable structure.
Why it matters: Semantic tags help search engines and AI classify content correctly.
How to fix it:
Use <header>, <main>, <article>, <nav>, and <footer>
Use exactly one H1 per page
Maintain a clean, logical heading hierarchy
AI visibility
Controlling AI crawler access (e.g. GPTBot)
Problem: The robots.txt file determines whether AI crawlers like GPTBot can read your content.
Why it matters: If you allow access, AI systems can learn about your content and recommend it – increasing your visibility.
How to fix it:
Decide in robots.txt which AI bots you allow
Allow the important bots for greater visibility
Deliberately exclude sensitive areas
AI visibility
Marking up FAQ schema
Problem: Frequently asked questions marked up as FAQPage schema (JSON-LD).
Why it matters: AI systems and Google especially like to cite clearly marked-up questions and answers.
How to fix it:
Add real questions and answers as FAQPage schema
Only mark up content that's actually visible on the page
Check with the Rich Results Test
In detail
FAQ schema marks up question-and-answer pairs in a machine-readable way. Google can show them as expandable questions right in the search result, and AI systems especially like to cite them.
Mini example:
{
"@type": "FAQPage",
"mainEntity": [{
"@type": "Question",
"name": "How long does shipping take?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Usually 5–7 business days."
}
}]
}
Important: Only mark up questions that are also visible on the page. Check with the Rich Results Test.
User-agent: * – this rule applies to all crawlers.
Disallow: /path/ – this area should not be crawled.
Sitemap: – reference to the XML sitemap.
Caution:Disallow: / blocks the entire site – a common, high-impact mistake. Also: robots.txt is not access protection – sensitive content belongs behind a password, not just in a Disallow entry.
Problem: Images should be served with the correct width/height so they don't load distorted or cause layout jumps.
Why it matters: Incorrect ratios cause distortion and layout shifts (CLS).
How to fix it:
Specify width and height on the image
Match the file's aspect ratio to how it's displayed
Check the display after making changes
Technology
Setting the doctype (info)
Problem: The <!DOCTYPE html> line at the top of the page turns on the browser's standards mode.
Why it matters: Without a doctype, browsers render in the outdated “quirks mode” with unpredictable results.
How to fix it:
Make sure every page starts with <!DOCTYPE html>
This is standard in modern themes
Double-check custom templates
Technology
Declaring the character encoding
Problem: The <meta charset="utf-8"> tag sets the character encoding.
Why it matters: Without UTF-8, accented characters and special characters display incorrectly.
How to fix it:
Set <meta charset="utf-8"> in the <head> (default in WordPress)
Consistently save content in UTF-8
Check special characters on the frontend
Technology
Avoiding deprecated browser APIs
Problem: Use of techniques that browsers have deprecated.
Why it matters: Deprecated APIs can be removed at any time and break functionality.
How to fix it:
Pay attention to console warnings about “deprecated” features
Keep themes/plugins up to date
Replace old scripts with modern alternatives
Technology
No geolocation request on load
Problem: Some sites ask for visitors' location right when the page loads.
Why it matters: An unprompted location request feels intrusive and puts visitors off.
How to fix it:
Only request location after a deliberate user action
Briefly explain beforehand why it's needed
Offer a sensible alternative if permission is denied
Technology
No notification request on load
Problem: Some sites ask for permission to send push notifications right when the page loads.
Why it matters: Immediate notification pop-ups are annoying and almost always lead to “Block”.
How to fix it:
Only ask for notification permission after a clear user action
Briefly explain the benefit beforehand
Avoid intrusive auto pop-ups
Technology
Checking iframe embeds
Problem: Third-party content embedded via iframe (maps, videos, forms).
Why it matters: iframes can affect load time, privacy, and security.
How to fix it:
Only embed trustworthy sources
Secure them with loading="lazy" and sensible sandbox attributes
Respect privacy (only load after consent)
Technology
What is an MX record and why do I need it?
Problem: Without a correct MX record in DNS, emails to your domain never arrive at all.
Why it matters: The MX record (Mail Exchanger) determines which server accepts emails for your domain. If it's missing or wrong, messages get lost or bounce back to the sender as undeliverable.
How to fix it:
Check in your host's DNS management whether an MX record points to the correct mail server
If you have multiple servers, set priorities (10, 20, …) sensibly
Allow up to 24 hours for DNS propagation after making changes
Test with an MX checker to confirm everything resolves cleanly
Problem: Email transport isn't encrypted by default – attackers can downgrade connections to unencrypted.
Why it matters: MTA-STS (SMTP MTA Strict Transport Security) tells sending servers that they may only deliver emails encrypted (TLS). This protects against eavesdropping and downgrade attacks.
How to fix it:
Create a TXT record _mta-sts in your DNS zone
Provide a policy file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt
Start in testing mode first, then switch to enforce
Use it together with TLS reporting to spot problems
Problem: Without feedback, you won't notice when emails to your domain are delivered unencrypted or not delivered at all.
Why it matters: TLS reporting has sending servers regularly send reports about encryption and delivery problems to an address you specify – so you catch issues early.
How to fix it:
Create a TXT record _smtp._tls.yourdomain.com with v=TLSRPTv1; rua=mailto:…
Set an email address for the reports
Review the reports regularly (or have them analyzed automatically)
Problem: If you run only one nameserver and it fails, your entire domain – website and email – becomes unreachable.
Why it matters: Nameservers translate your domain into your server's address. At least two, ideally on separate networks, ensure resilience against outages.
How to fix it:
Check with your domain/DNS provider that at least two nameservers are configured
Where possible, use separate locations/networks
Set sensible TTL values so changes take effect quickly
Why every service must be named in the privacy policy
Problem: Websites often run services like fonts, maps, analytics, or video that don't show up in the privacy policy.
Why it matters: The GDPR requires that every instance of data processing – i.e. every embedded service – be transparently disclosed. If even one is missing, the policy is incomplete.
How to fix it:
Identify all embedded services (e.g. via the browser's network tab or a scanner)
Add the purpose, provider, and legal basis for each service
Use a privacy policy generator that provides the text blocks
Problem: Many sites load tracking and marketing scripts right when the page loads – before the visitor has given consent.
Why it matters: Under the GDPR and TDDDG, non-essential cookies and trackers may only be set after active consent. Before that, it's not allowed and can trigger a cease-and-desist warning.
How to fix it:
Use a consent tool that only releases scripts after consent (Consent Mode v2)
Check that no marketing cookies are set before consent is given
Offer “Reject” equally to “Accept”
Document and respect the visitor's consent
Recommended tool: Consent tool (e.g. via eRecht24)
Privacy
Does my cookie banner need a 'Reject' button?
Problem: Banners with only an “Accept” option, or a hidden reject option, are not allowed – so-called dark patterns.
Why it matters: Consent must be given voluntarily. Rejecting must be just as easy as accepting – on the same level and with the same effort.
How to fix it:
Enable an equally prominent “Reject” button on the first level in your consent tool
Don't pre-check boxes for non-essential cookies
Save the visitor's choice and respect it on return visits
Problem: WordPress runs on PHP. Outdated PHP versions no longer receive security updates and are no longer supported by newer plugins.
Why it matters: An up-to-date PHP version brings security fixes and noticeably more speed. Old versions are an entry point for attacks and slow down the site.
How to fix it:
Check the current version in your hosting panel or under Tools › Site Health
Create a full backup before switching
Switch to an officially supported version (currently at least PHP 8.1)
Then test your website, forms, and shop features
If errors occur, update plugins and theme first
Recommended tool: WordPress Site Health / hosting panel
Security
WordPress version
Problem: An outdated WordPress installation contains publicly known security vulnerabilities.
Why it matters: As soon as a vulnerability is published, automated bots specifically search for sites running that exact version. Updates close it.
How to fix it:
Check the version under Dashboard › Updates
Create a backup before every update
Let small security updates install automatically
Apply larger updates promptly after a quick test
Check the site and key functions after updating
Recommended tool: WordPress Dashboard
Security
Plugin updates
Problem: Outstanding plugin updates are the most common way WordPress sites get hijacked.
Why it matters: Most attacks exploit known vulnerabilities in outdated plugins – not sophisticated hacks. Sites that update promptly fall outside the typical target profile.
How to fix it:
Check for updates regularly (Dashboard › Updates)
Always back up first, then update
Delete unused plugins instead of just deactivating them
Avoid plugins that haven't been updated in years
Establish a fixed maintenance routine
Recommended tool: WordPress Dashboard / maintenance plan
Security
Unmodified core files
Problem: If a WordPress core file is quietly modified, it doesn't stand out in daily use – the site looks completely normal.
Why it matters: Attackers like to embed malware in existing core files. A checksum comparison against the original from wordpress.org reliably reveals such changes.
How to fix it:
Compare core files against the original from wordpress.org (security plugin or host tool)
Have suspicious files checked instead of deleting them blindly
If core files have been altered, cleanly reinstall WordPress
Afterward, renew all passwords and the security keys (salts)
Recommended tool: security plugin with file integrity check
Security
Executable files in the uploads folder
Problem: The uploads folder (/wp-content/uploads/) is meant for images and documents – not executable program files.
Why it matters: If PHP code is found there, it's almost always a backdoor that lets attackers come back at any time – even after an update.
How to fix it:
Check the uploads folder for .php files
Back up any findings, then remove them
Block PHP execution in the uploads folder at the server level (server rule/.htaccess)
Then check core files and user accounts
Renew all passwords
Recommended tool: security plugin / file manager
Technology
Backups
Problem: Without a working backup, any defect, attack, or misclick can quickly turn into total loss.
Why it matters: A backup that has never been restored isn't really a backup. Only a tested restore counts.
How to fix it:
Set up automatic, regular backups (database and files)
Store backups outside the web server
Keep multiple versions and define a retention period
Test the restore process at least once for real
Take a backup before every major update
Recommended tool: Backup plugin / host backup
Security
Error display (debug mode)
Problem: If debug mode is active, visitors see technical error messages with paths and system details.
Why it matters: Such messages reveal internal details – server paths, versions, plugin names – giving attackers a foothold. They also look unprofessional.
How to fix it:
In wp-config.php, set WP_DEBUG to false
Disable the on-site display (WP_DEBUG_DISPLAY set to false)
Have errors written to a log file instead
Enable debug mode only briefly, ideally on a staging environment
Recommended tool: wp-config.php
Technology
Maintenance mode
Problem: An active maintenance or “Coming soon” mode shows visitors and search engines nothing but a placeholder page.
Why it matters: If it accidentally stays on after launch, the site is effectively invisible – no visitors, no rankings, no inquiries.
How to fix it:
Check whether a maintenance or coming-soon plugin is active
Deactivate it consistently after launch
For a relaunch, set a time limit and don't permanently block search engines
After disabling it, check the site in an anonymous/private browser window
Recommended tool: Plugin overview
SEO
Search engine visibility
Problem: Under Settings › Reading there's a checkbox that locks search engines out. It gets checked during setup – and is often forgotten after launch.
Why it matters: If it's checked, the website explicitly asks Google not to index it. Even the best page then gets zero visibility.
How to fix it:
Open Settings › Reading
Uncheck “Discourage search engines from indexing this site”
Also check robots.txt and noindex settings
Request re-indexing in Google Search Console
Recommended tool: WordPress Settings / Google Search Console
Accessibility
Skip link to content
Problem: Without a skip link, people who use the keyboard have to tab through the entire menu every time they load a page.
Why it matters: A “Skip to content” link right at the top of the page saves keyboard and screen reader users many keystrokes every time. It's one of the BFSG basics.
How to fix it:
Add a link to the main content at the very top of the source code (e.g. #content)
Hide the link visually, but make it visible on keyboard focus
Give the target area the matching ID
Test with the Tab key: the first tab should reveal the skip link
Recommended tool: Theme / Child Theme
Accessibility
Marking up page regions (landmarks)
Problem: Without semantic markup, a page is one long wall of text to a screen reader.
Why it matters: Regions like header, navigation, main content, and footer can be jumped to directly – but only if they're marked up (header, nav, main, footer, or ARIA landmarks).
How to fix it:
Mark up the page regions with the matching HTML5 elements
Use exactly one main region per page
Give multiple regions of the same type additional labels (aria-label)
Check with a landmark checker
Recommended tool: WAVE / axe DevTools
Accessibility
Visible keyboard focus
Problem: Many designs hide the focus outline because it's considered visually distracting.
Why it matters: Without a mouse, you then can't see where you currently are – the site becomes unusable. A visible focus indicator is required under the BFSG.
How to fix it:
Avoid outline: none without a replacement
Define a clearly visible focus style with sufficient contrast
Cover all interactive elements (links, buttons, form fields)
Tab through the entire page once from start to finish
Recommended tool: Browser + Tab key
Accessibility
Table headers
Problem: Tables are often built without real header rows, or just made bold visually.
Why it matters: Without real header cells (th), a screen reader can't assign meaning to the values – the table becomes a column of numbers without context.
How to fix it:
Mark up header cells as th
Define the association with scope="col" or scope="row"
Use tables only for data, not for layout
Split up complex tables or describe them with caption
Recommended tool: WAVE
Accessibility
Captions for video/audio
Problem: Videos and audio often run without captions or a transcript.
Why it matters: Without captions, content stays inaccessible to deaf and hard-of-hearing people – and to anyone watching without sound. For relevant content, captions are required under the BFSG.
How to fix it:
Create a caption file (e.g. .vtt) and add it
Always correct auto-generated captions afterward
Also provide a transcript
For audio-only content, provide a text version
Recommended tool: Caption editor / transcription service
Accessibility
Autocomplete (autofill)
Problem: Form fields often don't tell the browser what kind of data is expected.
Why it matters: With the autocomplete attribute, browsers can fill in name, address, or email automatically. This especially helps people with motor or cognitive impairments – and reduces drop-offs.
How to fix it:
Set the matching autocomplete values on standard fields (name, email, tel, street-address …)
Use the correct field type (type="email", type="tel")
Check on a smartphone whether the suggestions appear
Recommended tool: Browser DevTools
Accessibility
Respecting reduced motion
Problem: Animations, parallax effects, and auto-playing sliders usually run regardless of users' system settings.
Why it matters: For some people, motion triggers dizziness or nausea. Anyone who has turned on “reduce motion” in their system expects a calmer page.
How to fix it:
Check the media query prefers-reduced-motion: reduce
Turn off animations there, or shorten them significantly
Make auto-starting sliders and videos pausable
Don't let anything flash (seizure risk)
Recommended tool: CSS / system settings
Accessibility
Text resizable to 200%
Problem: When text is enlarged in the browser, some layouts break – text overlaps or disappears.
Why it matters: Users need to be able to enlarge content to 200 % without losing information or functionality. This is a core accessibility requirement.
How to fix it:
Define font sizes in relative units (rem/em) instead of fixed pixels
Avoid fixed heights and overflow: hidden on text areas
Click through the entire site at 200 % zoom
Pay special attention to menus, buttons, and forms
Recommended tool: Browser zoom
AI visibility
Blocking AI via meta tag
Problem: Besides robots.txt, you can also control AI systems' access directly in the page header – something that's often overlooked.
Why it matters: A meta tag lets you signal, page by page, whether content may be used for AI training and AI answers. That way, you make a deliberate choice instead of leaving it to chance.
How to fix it:
Decide whether your content should appear in AI answers (visibility) or stay protected
Add the appropriate meta tag to the <head>
Keep the setting consistent with robots.txt and llms.txt
Document your decision and review it regularly
Recommended tool: Theme header / SEO plugin
Performance
Compressed delivery (gzip / Brotli)
Problem: When HTML, CSS, and JavaScript are delivered uncompressed, unnecessary kilobytes travel across the network.
Why it matters: Compression (gzip or the more modern Brotli) often shrinks text files by 70–80 %. It's one of the biggest load-time levers for minimal effort.
How to fix it:
Check whether the server delivers compressed content (response header content-encoding)
Enable Brotli or gzip in the hosting panel or via a server rule
Problem: After redesigns, renames, or deleted pages, internal links often lead nowhere (404).
Why it matters: Dead links cost you visitors, trust, and search engine signals. They often go unnoticed for a long time, especially in menus and footers.
How to fix it:
Regularly check your website for broken internal links
Redirect (301) to the new target address instead of just deleting content
Specifically check menus, footers, and frequently linked content
Provide a helpful 404 page with search and a link to the homepage
Recommended tool: Broken link checker
Security
TLS version
Problem: Some servers still allow outdated encryption versions like TLS 1.0 or 1.1.
Why it matters: Old TLS versions are considered insecure and are flagged by modern browsers. TLS 1.2 and 1.3 are current.
How to fix it:
Check the supported TLS versions with an SSL test
Disable TLS 1.0 and 1.1 at the server level (via your host if needed)
Enable TLS 1.2 and 1.3
Test the site, forms, and payment paths after the change
Recommended tool: SSL Labs Server Test
Technology
Shop system detected
Problem: If you run an online shop, additional technical and legal requirements apply – ones that often get overlooked in everyday business.
Why it matters: Shop systems bring their own topics: order button, price information, right of withdrawal, payment data, and considerably more technology under the hood. If you know which system is running, you can check and secure it specifically.
How to fix it:
Keep your shop system and extensions consistently up to date
Check the legal requirements for shops (order button, prices, right of withdrawal, terms and conditions)
Regularly test checkout and payment methods yourself
Take a backup before every update
Recommended tool: Shop system backend
Technology
Blacklist entry (server IP)
Problem: Your server's IP address can end up on a spam blacklist – often through no fault of your own, because of other customers on the same server.
Why it matters: If the server IP is on a blacklist, your emails end up in spam or are rejected entirely. The website's availability can suffer too.
How to fix it:
Check the server IP with a blacklist checker
If it's listed, determine the cause (spam sending, hacked site)
Request delisting from the relevant blacklist operator
For recurring problems, switch hosts or use a dedicated IP
Problem: Without permalinks enabled, addresses look like ?p=123 instead of readable URLs.
Why it matters: Readable URLs are better for SEO, users, and word-of-mouth sharing. They require working URL rewriting (mod_rewrite).
How to fix it:
Choose a readable structure under Settings › Permalinks (e.g. Post name)
Check that the server rules (.htaccess or nginx) are working
After switching, check for 404 errors and redirect old addresses
Don't change the structure frequently after that
Recommended tool: WordPress permalink settings
Technology
Recommended plugins
Problem: With tens of thousands of plugins available, it's unclear which ones are actually useful and trustworthy.
Why it matters: The right tools for each area (security, performance, SEO, backup, GDPR) solve many web-check items at once – poor or duplicate plugins, on the other hand, create new problems.
How to fix it:
Choose one proven plugin per area instead of many overlapping ones
Look for active development, good reviews, and compatibility
Never run multiple plugins with the same function in parallel
Regularly clean out your plugin list
Recommended tool: WordPress Plugin Directory
Technology
PHP extensions
Problem: WordPress and many plugins need specific PHP extensions (e.g. mbstring, curl, gd, zip, intl). If one is missing, parts of the site won't work properly or at all.
Why it matters: PHP extensions provide important functions – from image processing to encryption to API calls. If they're missing, errors occur that are hard to track down.
How to fix it:
Check under Tools › Site Health which extensions are missing
Ask your host to enable the recommended PHP extensions
Test the affected features after activation
On shared hosting, contact support if needed
Recommended tool: WordPress Site Health / hosting support
Performance
Autoload data
Problem: In the database table wp_options, data marked “autoload” is loaded on every page visit. Over the years, this often accumulates megabytes of leftover data from uninstalled plugins.
Why it matters: Too much autoload data slows down every single page, because it's loaded completely from the database on every visit.
How to fix it:
Check the size of the autoload data (Site Health or a database plugin)
Clean up orphaned entries from uninstalled plugins – back up first!
Switch large entries to “autoload = no” if they're not needed on every visit
Clean up regularly
Recommended tool: DB cleanup plugin (e.g. Advanced Database Cleaner)
Performance
Object cache
Problem: Without a persistent object cache, WordPress queries the same data from the database again on every single visit.
Why it matters: A persistent object cache (Redis or Memcached) caches database results and noticeably speeds up dynamic pages and shops in particular.
How to fix it:
Check whether your host offers Redis or Memcached
Enable the service and connect it via a plugin (e.g. Redis Object Cache)
Compare load time before/after
If issues occur, clear the cache and check compatibility
Problem: Older installations often use the utf8 character set instead of utf8mb4. This causes emojis and some special characters to be stored incorrectly or lost.
Why it matters:utf8mb4 is the modern standard and supports the full range of Unicode. An outdated character set leads to display errors and broken characters.
How to fix it:
Check the database's character set and collation (Site Health)
Create a full backup before switching
Switch the database to utf8mb4 (host support or a migration tool)
Afterward, check content for correct display
Recommended tool: Site Health / hosting support
Security
Automatic updates
Problem: If updates are only installed manually, weeks often pass – enough time for known security vulnerabilities to be exploited.
Why it matters: Automatic security updates (at least for WordPress core) close critical vulnerabilities promptly, without you having to think about it.
How to fix it:
Keep automatic updates enabled for small security releases (default)
Specifically enable automatic updates for important plugins and themes
Always use a backup or staging site before larger updates
Briefly check the site after updates
Recommended tool: WordPress Dashboard / maintenance plan
Technology
WordPress memory limit
Problem: In addition to the PHP memory limit, WordPress has its own limit (WP_MEMORY_LIMIT). If it's too low, memory-intensive tasks fail.
Why it matters: A sufficient WordPress memory limit ensures stable operation in the admin area and with plugins – too little leads to errors and blank pages.
How to fix it:
Check the current limit under Site Health
Increase WP_MEMORY_LIMIT (and WP_MAX_MEMORY_LIMIT for the backend) in wp-config.php
Make sure the PHP memory limit is at least as high
Test after making the change
Recommended tool: wp-config.php / Site Health
Security
Finding malware and backdoors
Problem: After a successful attack, attackers often leave behind hidden malware or backdoors – invisible during normal operation.
Why it matters: Such code reads out data, sends spam, or provides permanent access. The sooner it's found, the smaller the damage.
How to fix it:
Regularly check the website and files with a malware scanner (security plugin or host scan)
Compare core files against the original from wordpress.org
Check suspicious files in the uploads folder
After a find, clean up and renew all passwords and security keys (salts)
Recommended tool: security plugin with malware scan
Security
Hidden links & cloaking
What is it? Cloaking means a website shows search engines something different from what regular visitors see. In the most common variant, attackers inject links to third-party sites into the source code – often gambling, pharmaceuticals or pirated software. A small script then removes these links again in the browser as soon as a real person opens the page. Google, Bing and ad platforms like Meta still see them because they don't run the script.
Why do attackers do this? Search engines treat links from other websites as recommendations. Placing large numbers of links to their own spam sites boosts those sites' rankings. Your website becomes an unwitting billboard – its credibility gets used and used up.
How can you spot it? In the browser, you see nothing. That's exactly the point. It only becomes visible when you look at the source code or request the page with a search engine's user agent. Typical traces are a block of several links at the very end of the source code, link texts in foreign scripts and a script containing a long list of search engine names.
Why is it dangerous? Google treats hidden links and cloaking as spam. This can lead to lower rankings or to your site being labeled as hacked. Ad platforms may reject ads that point to the affected page. Above all, though, the finding itself is the real problem: whoever managed to inject links had access to the website – and there's usually a backdoor in place so they can come back at any time.
What to do: First, create a full backup of files and database, but only for analysis: it's infected too. Then search the website for the injected search term – the Web-Check names it in the report. After that, restore a clean version, update everything and change all logins and passwords. Finally, check again. Seeing nothing in a normal browser proves nothing – that's the whole trick.
Limits of the check: Some attackers go further and verify the real IP address of Google's crawler instead of relying only on the user agent. No external test can detect that kind of cloaking. In that case, the only way to be sure is the URL Inspection tool in Google Search Console with “View crawled page”.
Problem: WordPress lets you edit theme and plugin files directly in the backend. Anyone who gains admin access can immediately inject malware through it.
Why it matters: The built-in file editor is rarely needed day to day, but it's a convenient tool for attackers. Disabling it shrinks the attack surface.
How to fix it:
In wp-config.php, set define('DISALLOW_FILE_EDIT', true);
Make file changes via SFTP or a deployment instead
Check that no functionality depends on the editor
Recommended tool: wp-config.php
Security
Number of administrator accounts
Problem: Over the years, multiple accounts with administrator privileges often accumulate – including from former service providers.
Why it matters: Every admin account is a possible entry point. The fewer there are, the lower the risk.
How to fix it:
Review the user list and remove or downgrade admin accounts that are no longer needed
Give every real user only the role they actually need
Immediately lock the access of people who have left
Check regularly
Recommended tool: WordPress user management
Security
Database table prefix
Problem: Many installations use the default prefix wp_ for their database tables.
Why it matters: A well-known prefix makes certain automated attacks easier. A custom prefix is a small but worthwhile extra hurdle.
How to fix it:
Choose a custom table prefix for new installations
On existing sites, change it only with a backup and care (tables and internal references)
Consider it part of a security hardening package
Recommended tool: security plugin / hosting support
Security
Two-factor authentication (2FA)
Problem: A password alone can be guessed, intercepted, or reused from data leaks.
Why it matters: With two-factor authentication, you also need a second factor (app code, security key). A stolen password alone is then not enough.
How to fix it:
Install a 2FA plugin
Make 2FA mandatory for all administrators at minimum
Prefer app-based codes (TOTP) over SMS
Store recovery codes securely
Recommended tool: 2FA plugin (e.g. WP 2FA)
Technology
Scheduled tasks (WP-Cron)
Problem: WordPress handles scheduled tasks (publishing, backups, updates) via WP-Cron – but this only runs when someone visits the site.
Why it matters: With low traffic, tasks run late or not at all; with high traffic, WP-Cron slows down the site. A real server cron job is more reliable.
How to fix it:
Check WP-Cron (Site Health or a plugin)
Disable the internal WP-Cron and set up a real server cron job instead
What is it? Cross-browser display means the website looks and works equally flawlessly in all common browsers: current Chrome, Safari, Firefox and Edge as well as Safari on iOS. Layout, fonts and interactive elements have to be right everywhere.
Why it matters before go-live: Browsers interpret CSS and JavaScript differently. Without testing, you risk shifted layouts, missing fonts or broken elements in individual browsers – which costs you visitors right at the first impression.
How to set it up:
Open the homepage and key subpages one after the other in Chrome, Firefox, Edge and Safari (desktop) and compare them.
Test iOS Safari on a real iPhone or in a simulator, since it often behaves differently from desktop Safari.
Click through interactive elements such as menus, sliders, forms, pop-ups and Elementor animations in every browser.
Check the DevTools console of each browser for JavaScript errors.
Fix any differences you find with targeted CSS adjustments (vendor prefixes / Autoprefixer if necessary) and test again.
Technology
Fonts from the live domain
What is it? A website's fonts must be loaded from the final live domain or an approved CDN – no longer from the build or staging domain where the site was developed.
Why it matters before go-live: If font URLs still point to the staging domain after the move, they lead nowhere: the fonts don't load, a fallback font or briefly invisible text appears, and the layout shifts. Fonts loaded externally from Google's servers are also a GDPR issue.
How to set it up:
After the move, open several pages and check in the network developer tools (filter: Font) which domain the fonts are actually loaded from.
Switch font URLs that still point to the staging or build domain to the live domain – in the theme and Elementor settings, in custom CSS and in @font-face rules.
Host fonts locally where possible – for example via Elementor's option to load Google Fonts locally or a plugin like OMGF – instead of fetching them from external servers.
Clear the Elementor cache as well as the server and caching plugin caches so the corrected font paths are served.
Ensure GDPR compliance: no unsolicited connections to fonts.googleapis.com, and cover this point in your privacy policy.
What is it? The health index combines many individual technical checks of a website into a single overall score. WordPress provides a basic rating under “Tools › Site Health”; tools like WM Guard extend it with additional security and operations checks.
Why it matters before go-live: Before go-live, the index shows at a glance whether critical issues such as an outdated PHP version, missing updates or inactive security features are still open. A green overall status is quick proof that no known critical issues have been overlooked.
How to set it up:
In WP admin, open the “Status” tab under “Tools › Site Health” and work through all items marked as critical.
Review the recommended improvements (e.g. missing PHP modules, object cache, HTTPS) and implement them where it makes sense.
Raise the PHP version at your host to a currently supported version.
If you use an extended tool like WM Guard, run through its additional checks as well and close any open items.
Open the index again right before go-live and document that it shows no critical issues (green).
Technology
Off-site backup
What is it? An off-site backup is a backup that isn't stored on the same server as the website but at an external destination such as cloud storage or another data center. That way, the backup stays accessible even if the web server fails completely.
Why it matters before go-live: If the only backup sits on the same server, it's often lost along with it in a server failure, a hosting problem or a ransomware attack. An external backup is the basic prerequisite for being able to restore the website at all after a total failure.
How to set it up:
Choose an external backup destination (e.g. S3-compatible storage, Google Drive, Dropbox or a separate FTP server).
Set up a backup plugin (e.g. UpdraftPlus, BackWPup, Duplicator) or your host's backup feature so the backup is automatically moved there.
Make sure both the database and the files (wp-content, uploads) are included.
Keep the credentials for the backup destination separate from the website.
After the first backup, check that the files have actually arrived at the external destination.
What is it? A restore test means restoring an existing backup on a trial basis to prove that it's complete and working. Only after a successful test is a backup truly usable.
Why it matters before go-live: In practice, backups often fail unnoticed – due to incomplete files, a missing database or corrupted archives. If you only find out in an emergency, you're left without a working restore; a backup that has never been tested is an unproven backup.
How to set it up:
Select or download a recent backup.
Restore the backup to a separate test environment (staging, local installation, subdirectory) – never directly to the live site.
Check whether the homepage, key subpages, login and forms work and whether the content is complete.
Check the database and the files separately, for example whether the media are present in the uploads folder.
Document the result and date of the test, and repeat the test after major changes.
What is it? This is about two things: every backup actively reports whether it succeeded or failed (notification), and old backups are automatically deleted after a set retention period (rotation).
Why it matters before go-live: Without notifications, a backup that silently failed is only noticed in an emergency. Without rotation, the storage fills up or only outdated backups are left – both put your ability to restore at risk.
How to set it up:
Enable email notifications in the backup plugin or at your host – at least for failures.
Define a retention rule, e.g. keep the last 7 daily and 4 weekly backups.
Turn on automatic rotation or deletion of old backups so the storage doesn't fill up.
Make sure notifications go to an address that's actively read – not to the website's own mailbox.
Check regularly that the success messages actually arrive – missing messages can be a warning sign in themselves.
What is it? With authenticated email sending, WordPress doesn't send its emails through the built-in PHP function mail() but logs in to a real mailbox or a sending service with credentials (SMTP or API). The sender is a real address on your own domain that the mail server is actually allowed to send from.
Why it matters before go-live: Without authentication, many recipients classify the emails as spam or reject them entirely because the sender address and the sending server don't match. This is critical before go-live, because otherwise contact form, order, registration and password reset emails silently fail to arrive.
Enter a real mailbox address on your own domain as the sender address (e.g. no-reply@your-domain.com), not the default address wordpress@servername.
Configure the sending method in the plugin: the SMTP credentials of the mailbox at your host, or an API key from a service like Brevo, Mailgun or SendGrid.
At your domain/DNS provider, set the SPF and DKIM records (and ideally DMARC) so the sending server is authorized to send for the domain.
Send a test email with the plugin's test function and check delivery, including the spam folder.
Test all real system emails (contact form, password reset, WooCommerce order confirmation if applicable) and check that they're delivered.
Technology
Email forwarding
What is it? Email forwarding automatically passes messages from one address on to another mailbox without running a separate mailbox for that address (e.g. info@your-domain.com to a private or central address). It's usually tied directly to the domain and set up at the host or email provider, not in WordPress.
Why it matters before go-live: When you switch domains or hosts, existing mailboxes and forwards don't move over automatically; if they aren't recreated in time, incoming emails are silently lost from the moment the DNS is switched. This especially affects important addresses like info@, contact@ or billing@, whose failure nobody notices right away.
How to set it up:
Document all existing mailboxes, aliases and forwards at the old provider (source and destination address for each).
Create identical mailboxes and forwards in the email/hosting panel of the new provider before the domain is moved.
Only switch the MX records in DNS once the mailboxes and forwards are ready at the destination.
After the switch, wait for DNS propagation and send a test email to every address to check that it's actually delivered.
Deliberately review or disable any catch-all setting so that emails to non-existent addresses aren't silently collected or discarded.
Specifically test autoresponders and business-critical forwards (e.g. info@, contact@) and check the result in the real destination mailbox.
Technology
Scheduled actions (Action Scheduler)
Problem: Many plugins (e.g. shops) use Action Scheduler for background tasks. If tasks pile up there, orders, emails, or syncs can get stuck.
Why it matters: An overflowing task queue is a sign of cron problems or overloaded resources – and leads to delayed or missing actions.
How to fix it:
Check the status of Action Scheduler (e.g. WooCommerce › Status › Scheduled Actions)
Investigate failed tasks
Ensure a reliable (server) cron
If the backlog persists, check resources or hosting
Recommended tool: Action Scheduler (in the plugin) / Site Health
Technology
REST API
Problem: The WordPress REST API is the programming interface that the block editor, apps, and connected services use to work with your website.
Why it matters: It has two sides: Operation – is it reachable? If it's blocked, the editor, preview, or integrations stop working. Security – it's open by default and can expose some information (e.g. usernames via certain endpoints).
How to fix it:
Make sure the REST API is reachable in general (otherwise the editor and apps break)
At the same time, secure unneeded, readable endpoints (e.g. restrict the user listing)
Use a security plugin that protects without blocking needed functions
After making changes, test that the editor and connected services still work
Recommended tool: Site Health / security plugin
Technology
Loopback (self-request)
Problem: For some tasks, WordPress sends a request to itself — a loopback (self-request) — such as for WP-Cron or Site Health. If this is blocked, those tasks fail.
Why it matters: Missing loopback connections cause scheduled tasks to not run and produce misleading error messages in Site Health.
How to fix it:
Check the loopback under Tools › Site Health
If there are errors, check your host, firewall, or security plugin as the cause
If necessary, use a server cron as an alternative
Test again after fixing
Recommended tool: Site Health / hosting support
Security
Folder and file permissions
Problem: Files and folders with overly permissive file permissions (e.g. 777, “world-writable”) allow virtually anyone on the server to modify or inject files.
Why it matters: Overly generous permissions are a common entry point: malware can be dropped and configurations manipulated. Secure default permissions significantly reduce the risk.
How to fix it:
Generally set folders to 755 and files to 644
Protect sensitive files like wp-config.php more restrictively (e.g. 640 or 600)
Don't grant 777 permissions – if a plugin or uploader requires it, ask for a more secure solution
Check and correct permissions via SFTP or your hosting file manager
