Your website's address
The address the public uses, exactly as they type it.
From a website nobody but a developer can change, to your own team editing and publishing it. Eleven steps, in the order they have to happen.
Steps 1 to 6 are done once, with Dakyworld, and take about half an hour. Steps 7 onwards are the everyday use of it.
Three things. If any of them is missing, start with step one anyway and we will sort it out together.
The address the public uses, exactly as they type it.
A GitHub repository, and somebody who can grant access to it — usually whoever built the site. If you do not know, we will find out.
The names and email addresses of the people on your side, and which of them should be allowed to publish.
Done with you on a call. You do steps 3 and 6; we do the rest while you watch.
Who does it: Dakyworld. How long: minutes.
We open your site in the Builder's compatibility report. It reads every page and grades each one: fully editable, editable with limits, developer-managed, or not supported.
We go through the findings with you out loud. Each one is a sentence you can act on — “three pages have forms, whose behaviour stays with your developer” — not a technical warning.
If your website is one the Builder cannot carry, this is where we say so. An application whose pages only exist once a browser runs them cannot be edited this way, and no amount of setup changes that.
Who does it: Dakyworld.
We add your site to the Builder with its public address and name. Nothing is connected to your code yet, and nothing can be published.
Who does it: you, or whoever administers your GitHub account. How long: about a minute.
Open the Dakyworld Website Editor app on GitHub and press Install.
When GitHub asks which repositories, choose Only select repositories and pick the one your website lives in. Do not choose “All repositories” — the Builder needs one.
GitHub will show you exactly what it is granting before you confirm:
What this is not: you are not creating a password or a token, and you are not giving Dakyworld access to anything else you own. The access is limited to the repository you picked, GitHub enforces that rather than us, and the credentials it lends expire every hour.
Taking it back: at any time, in your GitHub settings under Applications → Installed GitHub Apps. You can remove a repository or uninstall it entirely without telling us — the Builder notices within seconds and says the access was withdrawn.
After you confirm, GitHub returns you to a page whose address ends in installation_id= followed by a number. Send us that number, or read it out on the call.
Who does it: Dakyworld.
We put that number into the site's settings, pick your repository from the list the installation reaches, and confirm the branch your live site is built from.
Then we scan. Every page of your website appears in the Builder with a plain name and a count of what can be edited on it.
Who does it: Dakyworld.
We add your own colours and typefaces so the editor offers yours rather than Dakyworld's — without this, somebody picking a colour is choosing from our palette for your brand.
We then link the parts that repeat: your header, your footer, a call to action that appears on several pages. Once linked, changing one changes all of them, and the editor says how many pages that is before anybody types.
Who does it: Dakyworld, with your list. What you decide: who gets which.
Each person gets their own login. Choose what each one may do:
A common arrangement: everyone who writes is an Editor, one person is a Publisher, and nothing reaches the public without that person looking at it.
Your team sees only your website. The Builder is part of a larger system Dakyworld runs, and none of the rest of it is visible to a client account.
This is the part your team does every week. It is worth doing once together on something harmless.
Sign in and choose Pages. Pick the page you want to change and it opens with your real website on the right and a panel on the left.
The panel has two halves. Layers lists everything on the page, in the order it appears, so you can reach something that is three screens down or has nothing visible to click. Below it, whatever you have selected.
Words: double-click any text on the page and type. The cursor is in the real heading, at the real size.
Pictures: select one and replace it, either from the files already on your site or by uploading. Always fill in the description — it is what somebody using a screen reader hears, and what search engines read.
Links and buttons: select one to change its words, where it goes, whether it opens in a new tab, and which of your site's button styles it wears. The list of destinations offers your own pages, so a typo cannot send somebody nowhere.
If what you selected is shared, the panel says so above everything else — “used on 7 pages” — and asks whether the change is for all of them or only this page. Choosing “only this page” makes this copy independent; nothing on screen moves when it does.
The design controls show what your website already says. A heading might read 72px · Website: that is the size your site sets, not a blank box.
Change one and it is marked Override with an arrow beside it. Press the arrow and it goes back to what your website had. You can always get back to the original.
Switch between Desktop, Tablet and Phone at the top. Values shown are the ones that width actually uses, and a change made under Phone applies to phones only.
A good habit: change the words first, publish, and only then adjust design. Two kinds of change in one publish are harder to review and harder to undo.
Your work saves as you go, privately. The public site is untouched until you publish.
Press Publish and you are shown what will change, in words: the old sentence and the new one, for each thing you touched. Read it. This is the last moment before it is public.
Then the Builder tells you the truth about what happened next. “Published” means committed to your repository; your website is rebuilt by its host afterwards, which takes up to a couple of minutes. So the Builder keeps looking at your live page and reports Live site updated with how long it took — or warns you that the live site has not changed, which is a real thing that occasionally happens and is worth knowing.
If a change is shared across pages, it is published from the shared change rather than from one page, so every page it affects goes out together or none of them do.
While editing: Ctrl+Z, as anywhere else. Before publishing: Discard throws the whole draft away.
After publishing: open Versions. Every publish is listed with what it contained and who made it. Restoring one puts that version back as a draft you can review and publish, so a rollback goes through the same door as any other change.
Each of these has a specific cause and a specific fix. None of them means your website is broken.
Your change reached your repository, and your website's host has not rebuilt from it. Usually it is simply slow — wait a minute and look again. If it persists, your host's build has failed and your developer needs to look at it; nothing was lost, and the change is safely in the repository.
Two people edited the same page. Nothing was overwritten. You will be shown both versions field by field, and you choose which to keep for each one.
Your developer changed the same page in the code after you started. The Builder refuses to publish over their work. Reopen the page to see it as it now is and make the change again — it will be quick, and the alternative is silently undoing somebody.
The GitHub app was removed from the repository, or uninstalled. Someone with access to your GitHub account can add it back under Applications → Installed GitHub Apps. Editing still works meanwhile; publishing does not.
Not everything is editable, and the compatibility report from step one says which parts. Text inside an embedded map, a form's behaviour, or anything your site builds while it runs belongs to your developer. Send it to us and we will do it, or tell you why it cannot be done.
If something in the Builder does not do what this guide says, that is worth telling us — either the software is wrong or this page is, and both get fixed.
Get in touchThe editor starts in Client editing mode. Follow the first-edit guide to select a heading, change it, check Phone and Preview, and review before publishing. More reopens the guide and contains Designer controls, Versions and Download HTML.
For images, preview the replacement, choose Use this image, and adjust Crop & focal point if needed. Wait for Live after publishing and open the live website to inspect the result.
Click an element on the canvas. Use Content for words, images and links; Style for typography, spacing and colours; and Interactions for hover, keyboard focus and active states. Open Layers when you need the page structure. Use Inspector to hide the sidebar for more canvas space.
Highlight only the words you want to colour. Crop & focal point keeps the original image. Save creates a draft; Publish opens a before-and-after review. More contains Versions, confirmed Discard, Designer controls, the walkthrough and the light/dark editor theme.
Keyboard: Ctrl/Cmd+S saves, Ctrl/Cmd+Z undoes, Ctrl/Cmd+Shift+Z redoes, and Ctrl/Cmd+Enter opens publish review. AI suggestions, when enabled in site settings, can be previewed before you apply them to a draft.
If repeated words cannot be traced, use Name these fields, then wait for the updated build. Named fields take priority over identical unnamed text. Joined fixed strings can also be edited; runtime calculations still need source changes.