WordPress powers most of the websites we build, usually with Elementor as the page builder. After 110 finished WordPress projects, we have a good picture of what goes wrong – and it is rarely what clients expect. We went through every feedback round, internal note and chat message and counted in how many projects each problem came up.
The ranking
| # | Problem | Projects where it came up |
|---|---|---|
| 1 | Brand fonts, colours and design details | 57 (52%) |
| 2 | Mobile layout issues | 42 (38%) |
| 3 | Cookie banner, legal pages, GDPR questions | 39 (35%) |
| 4 | Hosting, domain and DNS access | 28 (25%) |
| 5 | Missing or late content | 23 (21%) |
| 6 | Booking and calendar functions | 21 (19%) |
| 7 | Integrations and APIs | 18 (16%) |
| 8 | Translations and multiple languages | 18 (16%) |
| 9 | Payments, checkout and shop setup | 17 (15%) |
| 10 | Scope changes during revisions | 16 (15%) |
A note on method: a project counts once per problem if the topic came up in its feedback, chat or work notes. It is a measure of how common a topic is, not of how severe it was.
1. Brand fonts, colours and design details
The most frequent feedback is about the look: exact brand colours, a specific font, the size of a logo, a stripe that should not overlap the logo. When a client has a brand guide, this is quick. When they do not, the website becomes the place where brand decisions are made. Fix: we ask for brand colours as hex values and font names at kickoff, and propose a typography set early if none exists.
2. Mobile layout issues
Menus that do not open, overlapping elements, headlines too large on small screens, buttons too close together. Most of these we catch in our internal quality check; the rest come from clients reviewing on their own phones. Fix: we check every page on real devices before each handover and ask clients to review on mobile first.
3. Cookie banner and legal pages
Imprint, privacy policy, terms and a cookie banner that actually blocks tracking until consent. Clients regularly ask whether a Google Maps embed is allowed under GDPR – it is, when it loads only after consent. Fix: legal pages and consent settings are part of our go-live checklist, and we use a consent tool that blocks external content by default.
4. Hosting, domain and DNS access
Finished sites waiting on staging because nobody can log in to the domain or hosting. Fix: access checklist on day one, and DNS inventory before any change so email keeps working.
5. Missing or late content
Placeholder photos, videos promised but not delivered, texts still in progress. Projects with content problems took a median of 74 days versus 26 days without. Fix: content checklist at kickoff, and we draft texts for approval when needed.
6. Booking and calendar functions
Appointment tools, course bookings with participant limits and waitlists, calendar integrations. These need decisions on services, durations, prices and opening hours before they can be configured. Fix: we collect the service list in a spreadsheet before building the booking flow.
7. Integrations and APIs
Property listings from a real estate CRM, vehicle listings from a marketplace, CRM connections for forms. A common trap: content that comes from a sync gets overwritten if edited on the website, so changes must be made at the source. Fix: we document which data lives where and show the client where to edit it.
8. Translations
Language switchers leading to half-translated pages, two translation plugins overwriting each other, German texts breaking layouts built for English. Fix: approve the main language first, use one translation system, translate last.
9. Payments and shop setup
Payment methods missing on staging, bank transfer details, checkout showing the wrong product variant in a bundle. Fix: payment decisions in the brief and a test order for every product type before launch.
10. Scope changes during revisions
New pages, a blog, extra filters requested in a revision round. Fix: we implement corrections within the round and estimate new features separately, so the launch date stays visible.
Honourable mentions
Just outside the top ten: image quality, page speed and form delivery problems. Speed issues in our projects were often caused by heavy images or a caching plugin misbehaving – in one case an optimisation plugin was breaking the site's CSS until we reconfigured it. Plugin conflicts in the narrow sense came up less often than people think: in 6 projects.
FAQ
Is WordPress the problem?
Rarely. Most of the issues above would appear on any platform, because they are about content, decisions and access rather than technology.
Which of these problems delays projects the most?
In our data, missing content and extra revision rounds had the biggest effect on delivery time. Access problems delay the final launch.
Can these problems be avoided completely?
Not completely, but most can be reduced with a good kickoff: content, brand details, access and one decision maker.
How long does a website update project take?
Our 10 update projects – new pages, sections or features on existing sites – had a median delivery of 8 days and 5.5 hours of work.
How soon will I see a first design?
In our WordPress projects the first draft was ready a median of 8 days after the start, and in landing page projects after 5 days – provided the brief, brand assets and main texts are available.
Where the numbers come from: our own project records in Odoo – 233 finished projects, 909 tasks and about 4941 logged hours, mostly from 2025–2026. Durations are calendar days from kickoff and we quote medians, so one unusually long project does not distort the picture.
Planning a WordPress project?
If you want a realistic plan for your own project, book a short call with our team and we will walk you through the phases, what we need from you and where projects like yours usually lose time. You can also browse finished work in our WordPress portfolio.
Comments