A recent conversation with a prospective client exposed one of the most frustrating problems I continue to see with WordPress websites.
Their existing developers had given them limited access to the website. Then their hosting company told them they should have full WordPress administrator access so they could make changes themselves.
From the client's perspective, that recommendation sounded reasonable. They own the website. Their hosting company suggested that the developers had restricted access because they wanted the client to depend on them and pay for every change.
Now the developers looked suspicious.
The hosting company looked like the party defending the client.
The client started questioning why they could not access everything.
This situation can quickly turn into a dispute about ownership, trust, billing, and control. WordPress creates many of the conditions that allow this disagreement to happen because the platform combines content management, website configuration, design controls, plugins, themes, users, and other administrative functions inside the same dashboard.
A business owner who needs to change a paragraph should never have to think about whether changing that paragraph could damage the website.
Yet many WordPress websites put businesses in exactly that position.
WordPress Administrator Access Gives Someone Far More Than Content Access
The phrase "admin access" sounds simple. It can sound like the website equivalent of having the keys to your own building.
WordPress gives the Administrator role access to essentially all administration features on a standard single-site installation. WordPress documentation lists capabilities that include activating plugins, switching themes, editing theme options, importing content, managing users, managing site options, publishing pages, and many other administrative functions.
Most marketing departments need a much smaller set of capabilities.
Someone updating a services page may need to:
change a heading, revise several paragraphs, replace an image, update a testimonial, add a new project, change an employee biography, update a call-to-action button, or publish a new landing page from an approved layout.
None of those tasks require permission to install plugins, change themes, modify users, alter sitewide settings, or reconfigure the technical foundation of the website.
WordPress technically supports roles and capabilities, including custom roles. Developers can add and remove capabilities and create additional roles beyond the defaults.
The practical problem appears when a website's content editing system also exposes its layout and design system.
That happens frequently with page-builder websites.
Page Builders Can Turn Content Editing Into Website Building
A traditional page builder may give someone control over sections, columns, containers, widgets, margins, padding, typography, colors, responsive behavior, animations, backgrounds, templates, and dozens of other settings.
The business owner may only want to replace three sentences.
They open the page builder and see the mechanism that constructs the entire page.
A seemingly small mistake can create a much larger problem. Someone can delete a container that controls spacing for an entire section. They can duplicate a section and accidentally publish both copies. They can change desktop spacing while unknowingly changing tablet behavior. They can replace an image and remove settings that controlled its dimensions. They can move content into the wrong container. They can edit a reusable element that appears on several other pages.
A person does not need to be careless for these problems to happen. The interface gave that person controls that exceeded the task they needed to perform.
This creates an uncomfortable situation for developers.
The client reasonably asks, "Can we update our website?"
The developer knows that the editing interface also exposes controls that can alter the design.
The developer starts restricting access.
The business owner sees missing menus and limited permissions.
A hosting company or another consultant later inspects the account and says, "They didn't give you Administrator access?"
Distrust starts growing from there.
A Page Builder Needs Guardrails
Page builders can work better when developers use them as controlled component systems.
For example, a website could provide a predefined testimonial block. The marketing department could change the quote, person's name, company, photograph, and perhaps the order of the testimonial within the page.
The website would keep control over typography, spacing, alignment, mobile behavior, image proportions, and the visual treatment of the component.
A predefined services block could allow someone to select services, change their order, update descriptions, and choose from approved presentation options.
A call-to-action component could expose the headline, copy, link, and perhaps an approved visual variation.
Those controls match the work that content editors actually need to perform.
A completely open page builder creates a different environment. The same person editing the headline may also have access to every spacing value, container setting, template option, global style, and structural control used to produce the page.
Businesses eventually encounter a governance problem.
Someone has to decide which controls people should use.
Developers often solve that problem by hiding controls because the CMS did not establish a clean separation during development.
Restricted Access Can Protect a WordPress Website
Developers sometimes restrict access because experience has taught them how quickly an unrestricted WordPress website can develop problems.
Consider a business that has several employees working on its website. One employee wants a new feature and finds a plugin through Google. Another employee installs a different plugin to solve another problem. Someone changes a theme option while trying to update the header. Someone edits a page-builder template that controls several pages. Another administrator removes a user account without understanding who owns an integration.
Each individual decision can seem reasonable to the person making it.
The developer later receives a support request because a page has stopped working correctly, the layout has become misaligned, a form behaves differently, or an update has introduced a compatibility problem.
The client may have no idea which change caused it.
The developer now has to investigate modifications they did not make.
Backups help recover from severe mistakes, but restoration introduces another decision. Restoring yesterday's backup can also remove legitimate content updates, new form submissions, orders, comments, or other changes that occurred afterward.
Developers who repeatedly encounter these situations start locking WordPress down.
That decision can protect the website technically while creating a communication problem with the client.
Some Agencies Give Clients Good Reasons to Be Suspicious
Website owners also encounter agencies that refuse to provide reasonable access.
A client may discover that the agency controls the hosting account, domain registration, DNS, WordPress administrator account, analytics, and other essential services. The agency may provide little documentation about where anything lives.
The client eventually asks for credentials and encounters resistance.
Sometimes the agency claims that providing access would create security problems. Sometimes it refuses to explain the infrastructure. Sometimes a client has difficulty obtaining a complete website backup or moving the site to another provider.
Those practices damage trust across the entire industry.
A business should know where its website runs, who controls its domain, which services the website uses, who can access those services, and how the organization can take control if its relationship with the agency ends.
Clients have legitimate reasons to question arrangements where a vendor refuses to provide that information.
That history also explains why a hosting company's support representative may immediately become suspicious when they discover that a client has limited WordPress permissions.
The representative may have seen businesses trapped by previous providers.
The recommendation still needs technical context.
Hosting Companies Make the Situation Worse When They Treat Administrator Access as the Solution
Telling a client to demand WordPress Administrator access can solve an ownership concern while creating unnecessary technical risk.
WordPress Administrator access includes capabilities far beyond editing website content.
A hosting company may tell the business owner, "It's your website. You should be able to go in and change whatever you want."
That statement ignores how the site was built.
If the website uses a highly configurable page builder, the client may now have access to the same controls developers use to construct and configure pages. If WordPress plugins provide major website functions, Administrator access may also allow the client to install, deactivate, delete, or configure those plugins.
The hosting company does not usually accept responsibility for what happens afterward.
The developer does.
That creates an unhealthy arrangement. One provider encourages unrestricted access while another provider receives the support request when something changes unexpectedly.
The client gets caught between them.
Website Ownership and Website Permissions Need Separate Conversations
A business should own or control the assets required to operate its website.
That includes appropriate access to its domain, hosting environment, CMS, analytics, accounts, content, and other important services.
Website permissions serve another purpose.
Permissions determine what each person can change during normal operations.
Your accounting department may control the company's accounting records without every employee receiving permission to modify payroll settings.
Your marketing department may control brand materials without every employee receiving permission to modify the master design files.
A website needs the same level of operational planning.
Someone who writes case studies needs permission to create case studies.
Someone who updates employee biographies needs permission to manage employee information.
Someone responsible for marketing campaigns may need permission to create landing pages from approved components.
Someone managing website infrastructure may need much broader access.
Ownership does not require every user to operate with the highest available permission level every day.
Our Approach to WordPress Administrator Access
We provide WordPress Administrator access when a client requests it.
We also explain what that access controls.
If the client chooses to make changes to plugins, themes, templates, page-builder structures, technical settings, or other areas that affect the website, they also accept responsibility for the consequences of those changes. Repairing problems created outside the work we manage may require billable support.
That policy gives the client control while establishing clear responsibility.
Transparency plays an important role here.
Clients should understand which areas of their website they can safely modify, which areas control design or functionality, and which changes may require developer involvement.
That conversation becomes much easier when the CMS itself supports clear boundaries.
Content Editors Should Spend Their Time Editing Content
A CMS should make routine content work predictable.
A person replacing the photograph on a leadership profile should not need to understand page-builder containers.
A marketing director adding a project should not need to understand a global template.
Someone publishing a new case study should not need access to plugin configuration.
A person updating a call-to-action should not have to determine whether a particular setting affects one page or 40 pages.
Defined components give businesses a much cleaner way to manage these responsibilities.
The developer creates the component.
The designer determines how it should appear.
The CMS exposes the content fields.
The marketing department manages those fields.
Everyone works inside clearly defined boundaries.
Storyblok Handles This Relationship Much More Naturally
This separation represents one of the reasons we like building websites with Storyblok.
Storyblok uses reusable blocks that developers define for the website. A block can contain a set of fields that work together as a website component, such as a group of cards, a gallery, a hero section, or another reusable section.
We can build a hero component that contains fields for a headline, supporting text, image, button label, button destination, and approved display options.
The client edits those values.
Our website code controls how the hero works across desktop, tablet, and mobile screens.
The client does not need access to the code that determines spacing, responsive behavior, animation, accessibility attributes, or the technical implementation.
Storyblok also provides granular permissions for stories, blocks, individual fields, assets, languages, datasources, tags, and applications. Administrators can create roles based on the organization's actual content responsibilities.
Its Visual Editor allows content editors to work directly with components while viewing the page, which gives businesses a visual editing experience without requiring them to operate the website's frontend code.
For our projects, we can give the client complete access to the CMS functions they need to operate their content. We do not need an agency-only version of the content system hidden behind a special WordPress Administrator account.
Development remains in the codebase. Content management remains in the CMS.
That separation removes a major source of conflict.
The Client Does Not Need to Become a Web Designer
Website owners often hear that greater flexibility means greater control.
Unlimited design controls can create more work for the business.
Most companies already paid a designer and developer to establish their website's typography, spacing, responsive layouts, page structure, components, and brand presentation.
The marketing department should be able to use that system without rebuilding it every time someone creates a page.
Consider a company with 40 project pages.
A structured project component can provide fields for the project name, market, location, description, services, photographs, project statistics, related projects, and call to action.
The marketing department enters the information.
The website displays each project consistently.
Now consider 40 project pages that someone assembled manually in a page builder. Every page can eventually develop small differences. Someone changes spacing on one page. Another person uses a different heading size. An image receives different dimensions. A call to action gets rebuilt slightly differently.
The website becomes harder to maintain because each page carries more individual decisions.
Defined components reduce those decisions.
Better Content Access Also Helps Keep Websites Current
Website access affects more than convenience.
Organizations accumulate outdated content when employees cannot easily maintain the website.
A staff biography remains online after someone leaves.
An old service continues appearing in navigation.
A project description still references capabilities the company no longer offers.
An outdated PDF remains linked from a resource page.
A marketing department delays updating a campaign because every change requires an agency ticket.
Storyblok calls the broader accumulation of outdated, duplicated, inconsistent, and difficult-to-manage content "content debt."
Its 2026 research with FT Longitude surveyed 550 senior executives from companies with more than $1 billion in annual revenue. The report estimates the global cost of unmanaged content at $4.63 trillion and reports an average of 5.9% of revenue at risk.
Source: Content Debt: A $4.63 Trillion Business Liability
Those figures come from very large enterprises, so they should not serve as a direct financial estimate for a smaller organization. The underlying operational problem applies at every size: content becomes outdated when businesses cannot update it efficiently.
to appear in theA company that has to contact a developer every time it needs to change basic website information will eventually postpone some updates.
A company that gives everyone unrestricted control over the website can create a different set of problems.
A structured CMS provides a better operating model. Businesses can update the information they own while the website continues following the system that designers and developers created.
WordPress Makes Everyone Argue About the Wrong Permission
WordPress Administrator access has become a proxy for website ownership.
Clients ask for it because they want control.
Developers restrict it because they want stability.
Hosting companies recommend it because they want to protect clients from vendor lock-in.
All three parties can have reasonable motives.
The platform still leaves them fighting over one oversized permission level.
WordPress includes roles and capabilities, and developers can customize them. The difficulty grows when plugins and page builders introduce their own interfaces, settings, and editing models inside the same administration area.
Every WordPress project then needs someone to decide where content editing ends and website administration begins.
Sometimes that decision happens carefully during development.
Sometimes nobody considers it until after launch.
Sometimes the agency hides menus.
Sometimes the client receives Administrator access.
Sometimes another provider arrives later, sees restricted access, and assumes the worst.
That recurring conflict tells us something important about the architecture.
A content management system should make content ownership easy to understand.
A Better Website Handoff Starts During Development
Businesses should establish access expectations before the website launches.
A responsible website provider should be able to clearly explain:
- which accounts the client owns and how the client can recover them;
- which website content the business can update directly;
- which users should have access to specific content;
- which controls can affect design or website functionality;
- who manages the domain, DNS, hosting, analytics, CMS, repositories, and third-party services;
- how the client can obtain its website and content if it changes providers;
- what happens when someone makes technical changes outside the agency's management;
- how backups work and what they can recover;
- which changes fall under ongoing support; and
- how the CMS prevents routine content updates from altering the underlying website system.
This conversation removes much of the suspicion that appears later.
Clients understand their rights.
Developers understand their responsibilities.
Hosting providers have less reason to interpret restricted WordPress menus as evidence that someone is holding the website hostage.
The CMS Should Support the Relationship You Want With Your Website Provider
Website technology affects the working relationship between a business and its developers.
WordPress can support carefully controlled permissions, but many WordPress implementations still rely on a combination of administrator accounts, custom roles, page-builder permissions, plugin settings, hidden menus, documentation, and support policies to establish those boundaries.
That creates opportunities for misunderstanding.
We prefer systems where developers define how the website works and businesses receive clear control over the content they need to manage.
Storyblok gives us that model.
Clients can manage their content through visual editing and reusable components. Developers can maintain the code that controls presentation and functionality. Permissions can match actual business responsibilities rather than forcing every user into the same broad administrative role.
The result produces a healthier client relationship because nobody has to hide the website from its owner to keep the website stable.
Clients should have control over their website.
They should also have a CMS that lets them use that control safely.
