Imagine a furniture manufacturer's new company website. The design was approved, the pages load quickly, and everyone is pleased in the week it goes live. Six months later, the "new collection" banner on the home page still shows last season, a trade fair announcement is still up two months after the fair, and the careers page lists a position that has been filled. The marketing team knows about all of this. To change it, they email the agency, the work takes a few days, and then nobody writes any more.
The problem is usually not the people. The admin panel was built around the developer who made the site: everything is possible, nothing is easy. Changing a heading means finding the right page, the right block and the right language; after saving, there is no way to see what broke on mobile. After getting it wrong once or twice, the team learns not to touch the panel.
The seven settings below describe how to set up the panel so the site keeps living after launch. They apply whatever platform you choose: WordPress, a headless content system or a custom-built panel.
1. Design the panel for the person who will use it most
The person who updates the site most often is usually not a developer; it is a marketing specialist, an HR lead or an assistant. When you design the panel, sit with that person for half an hour and have them list the five changes they will make most often: adding an announcement, replacing a product photo, closing a job posting and so on.
The goal is simple: each of those five tasks should take less than two minutes, without training. If it does not, the panel needs rearranging; writing a longer manual for the user is not the fix.
2. Build pages from fields, not free blocks
Some panels give the content team a blank canvas: add any block, choose its colour, change the font size. This flexibility looks good on paper, and in practice it breaks the design a little more with every update.
The more durable approach is to define fields for each page type. For a product: name, short description, long description, up to eight photos, dimensions, related products. For a news item: headline, date, summary, cover image, text. The template decides the layout, and the team only fills in the content. Filling it in becomes easier, and two years later the site still has the same design.
Set limits in long text fields too. The text editor should offer bold, italic, links, lists and subheadings; it should not offer fonts, colours and point sizes. When text copied from Word is pasted, its formatting should be stripped. These limits may feel narrow to the team at first, but they are exactly what keeps every page of the site looking like part of the same family.
3. Offer a preview before publishing
Not knowing what the result will look like before pressing save is the most common reason people avoid the panel. A good preview shows the page in its real design, at desktop and phone width, and it is not live yet.
The preview should also have a shareable link. The person preparing the announcement should be able to send it to their manager for approval, rather than taking screenshots and attaching them to an email.
4. Make image handling the panel's job
The photos the team uploads come from phones, cameras and designers, in very different sizes and proportions. Resizing, compressing and cropping them should not be the content team's job.
The panel should convert each uploaded image to the required sizes and modern formats automatically and only ask the team to choose the crop area. The alternative text field should be required and show a short example of what to write. That way page speed and accessibility are not lost again with every update.
5. Add drafts, approval and rollback
Decide from the start who can publish what directly. In a small team, everyone may publish; in a larger company, a text prepared by an intern may need a manager's approval. In both cases, the draft and the live version should be kept separate.
At least as important is rollback. Every save should be stored as a version, and returning to the previous version should take one click. A team that knows an accidentally deleted paragraph can be brought back opens the panel much more willingly.
Who changed what and when should be visible as well. When someone needs to ask why a price or a phone number changed, the answer should be in the page's history, not buried in an email thread.
6. Fill search engine fields with defaults
Page title, meta description, URL and sharing image sit in a separate tab in most panels and are usually left empty. Instead of expecting the team to fill them in every time, define sensible defaults: the title comes from the page name, the description from the summary, the sharing image from the cover image.
The team should be able to change them if they want, without having to. If a URL is changed, redirecting the old address to the new one should also be something the panel does automatically.
7. Provide ready-made templates for recurring tasks
Some content arrives in the same form several times a year: a trade fair announcement, a holiday greeting, a new job posting, a campaign banner. Set up ready-made templates for these, with a start date and an end date.
The end date matters. If the announcement disappears by itself when the fair ends, an old announcement sitting on the home page six months later is prevented by itself too. On its own, this solves two of the three problems in the furniture example above.
A short test before handover
Before the site goes live, give the person who will update it three real tasks in the panel and sit next to them while they work: add an announcement, replace a photo, correct a paragraph on a page. Note where they hesitate and where they ask for help. This half-hour test is cheaper than months of "could you change this for us?" emails after handover.
In short
A company website stays alive as long as the person who updates it is not wary of the panel. Design the panel for the person who will use it most, build pages from fields, offer a preview, leave image processing to the panel, add drafts and rollback, fill search engine fields with defaults and provide templates with end dates for recurring content. Then try it out with the team before handover.
In company website projects, we plan the admin panel together with the design, starting from the tasks the content team will do most often, and before handover we test it with the team using real updates.
Planning a project like this?
Plan it in 10 steps