Yes, you can edit text and images on an Astro website yourself, if it has been built to support that. Astro does not dictate which editing tool you use. That needs to be chosen and configured as part of the project, based on who publishes, how often the content changes and what you want to manage yourselves.
For some businesses, sending changes to a regular contact is the most practical approach. Others need to publish news or correct a service description immediately. Both approaches can work. Before choosing a website setup, try the actual task from draft to published page.
Start with what you need to change
“We want to edit it ourselves” can mean several things. Correcting a phone number is a different task from building a new landing page. Ask for clarity on three levels:
- Content: Text, images, links, contact details, projects and articles within agreed templates.
- Layout: Moving sections or assembling a page from predefined content blocks. The setup needs to support this.
- Functionality: Changing a calculator, an ordering rule or a CRM integration. This is normally development work that needs testing.
A focused editor can simplify everyday tasks and keep pages consistent. You do not need unrestricted control over every element to manage your content well. It should still be clear which changes need assistance, how to request them and what they cost. Include this in your brief for a new website.
Three ways to organise editing
These approaches serve different needs. They can also be combined, but each type of content should have one clear place where it is maintained.
| Setup | May suit you when | What to agree |
|---|---|---|
| Content in files | One regular contact handles changes and publishing, or you have technical expertise in-house. | Who makes the change, how do you approve it, and who covers absences? |
| A connected editing tool | Staff need to update content regularly without working in the project files. | Fields, page templates, roles, previews, languages and the publishing workflow. |
| WordPress retained for agreed tasks | You have WordPress content or working practices worth keeping. | Whether WordPress supplies content to Astro or only handles other functions. |
Content in files
Astro can use content from text files. Astro’s Markdown documentation describes support for text and details such as titles and descriptions. A developer can organise these within reusable page templates. Files can be kept under version control so changes can be reviewed and earlier versions retrieved.
This can work well when editing is part of an agreed service. It is less suitable when several employees expect a simple publishing interface but only receive access to files. Agree how an urgent correction will be handled when the usual contact is away.
An editing tool connected to Astro
A CMS is a system for managing content. With a connected CMS, staff can have fields for a heading, introduction, image and contact person, while Astro handles presentation. Astro’s CMS guide explains this separation. An editing interface is not automatically included just because the website uses Astro.
Ask to try the fields and page templates you will actually receive. A polished demonstration of one news post tells you little about editing a service, replacing an image or updating two languages. Roles, scheduled publishing, approval and previews need to be assessed in the chosen setup.
WordPress as part of the setup
WordPress can remain the place where you write, while Astro presents the content to visitors. This is often called headless WordPress. Astro’s WordPress guide shows how content can be retrieved through the WordPress API. Existing designs, plugins and previews need separate assessment; they do not automatically become part of the new frontend.
Another option is to retain WordPress only for specific tasks, such as older media or forms. In that arrangement, WordPress may not be the editor for the Astro pages. Ask to see where each type of change belongs. This helps avoid updating an old administration panel without changing the public website.
If you are considering a change of setup, our guide to moving from WordPress covers planning, launch checks and rollback using our own website as an example.
How we manage our own website
On faerdermarketing.no, Astro powers the pages visitors see. We maintain content in files with version history. We use AI to support the work, review text and changes, check Norwegian and English, and build a new version before publishing. We then check the public page as well.
We retain WordPress in the background for historical material, older media files and specific functions relating to forms and consent. The articles you read here are edited in the project files. This is our chosen workflow, and a practical example of Astro and WordPress serving different roles within one setup.
A customer who wants to publish independently every week may need a different editing tool from ours. We establish that before development starts. Read why we build more with Astro and custom code for the reasoning behind our technology choices.
A fictional example: test a normal working day
Imagine a service business in Vestfold, Norway. The office manager updates contact details and publishes a project roughly every fortnight. A technical specialist approves the text. A developer maintains the form that routes enquiries. The example is fictional, but you can use these tasks in a demonstration:
- Create a draft: Add a project title, a short description, an approved photograph with a caption and a link to the relevant service.
- Check both languages: Preview Norwegian and English on mobile. Fix an awkward image crop and check the contact link.
- Approve and publish: Let the specialist review the content without giving them unnecessary access. Then confirm that the page is actually public.
- Correct a mistake: Replace an incorrect contact person and try restoring an earlier text version. Establish who will help if publishing stops.
If an everyday task requires the developer to find the right file each time, you have effectively chosen a content maintenance service. That may be appropriate, but it should be clear in the proposal. If employees are expected to do the task themselves, they need the interface, training and support to do so.
Saved content is not always published content
On a static Astro page, new content needs to be included in a new build and deployment before visitors see the change. This can be automated. Astro can also be configured to retrieve fresh content when a page is visited. Astro’s rendering documentation describes both options. How quickly a correction becomes visible therefore depends on the setup.
Ask for clear draft, approval and publishing statuses. Agree who is notified of failures, how cached content is refreshed and who can make an urgent correction. Test scheduled publishing if you need it. A date in an editor is not enough unless the rest of the setup acts on that schedule.
Agree access, backups and responsibilities
A colleague who needs to correct text does not necessarily need access to all customer data or technical settings. Define who can write, approve, publish and manage users. Test with ordinary user accounts and check that drafts and internal information are not publicly accessible.
Text version history does not replace backups of images, databases and other services. Ask for a specific explanation of what can be restored and who will do it. If WordPress is retained, that part also needs maintenance and a clear owner. Use the guide to ownership and handover when agreeing accounts, exports and documentation.
What the proposal should include
Ask the supplier to describe editing through tasks you recognise. Establish what you can change yourselves, which templates are included, how languages are handled, how publishing works and what support costs. Include training, any subscriptions and cover for absences in the cost over time.
You could write: “We need to create a project, update contact details and publish in Norwegian and English without changing code. Show us these tasks in the proposed setup, including previews and correcting mistakes.” Replace the tasks with your own. This is more useful than asking for a website that is “easy to edit”.
When we plan a website for your business, editing is part of choosing the setup. Tell us who will publish, which changes are urgent and what you want to handle yourselves. This gives us a practical basis for deciding what to retain, adapt or build.
