When the live site behaves differently

The same site in three different places

Almost everything that looks like the site behaving differently is one of three places being mistaken for another. They are not equally real, and the gap between them is deliberate rather than accidental.

The editor's preview and the free grafter.build address you hand out are the same thing in different clothes: your site running inside a sealed frame on a page of ours. The seal is there because the site is written by a model, so it is kept away from your account, your browser and everything else on that page. The price of sealing it is that a few ordinary things a website does are switched off inside.

The third place is the site on hosting of your own, which is what Publish and then Put it online gives you. There the frame is gone. The site is an ordinary website with nothing around it, and nothing is held back.

• The editor's preview: your site in a sealed frame, with the builder around it.
• The free grafter.build address: the same sealed frame on a page of its own, with nothing around it. It looks like a finished website because it is one — it is just still inside the frame.
• Hosting of your own: no frame. The only one of the three that behaves like a normal website in every respect.

Note. Two of those three are the same frame, so testing on the free address instead of the preview proves less than it feels like it does. It is the right test for a form and the wrong test for anything that leaves the page.

You typed things into your app and a reload wiped them

Add five jobs to a tracker in the preview, reload, and the five jobs have gone. Nothing you built is wrong.

Inside the sealed frame the browser refuses to let the site save anything. Every attempt to write is turned down with an error, and so is every attempt to read back. There is nothing to load on the next reload, so the app starts again from the data it was seeded with.

The reload control makes it look worse than it is. It builds the frame again from nothing rather than refreshing what is inside it, so whatever the app was holding in memory goes as well. That is the only reliable way to reset a page that has already thrown an error.

On hosting of your own the saving works, and it is worth knowing whose saving it is. What an app keeps in the browser is kept in the visitor's browser on the visitor's device. Your laptop and your phone are two separate copies, and nothing anybody types is visible to you.

Tip. The free grafter.build address does not remember either, because it is the same frame. If remembering is the thing you need to check, only hosting of your own answers the question.

The Send button does nothing when you press it

In the sealed frame a form submission is stopped before your site's own code is reached. The work behind the button is never run, so the button looks dead rather than doing anything.

It comes down to which kind of button was written. A button that submits the form around it is dead in the preview and dead on the free address, and works on hosting of your own. A button that simply runs its own code when it is clicked works everywhere, the preview included.

So the preview is the test, and it is a reliable one. A button that does something there is the ordinary kind and needs nothing. A button that does nothing at all there is the submit kind, and the free address will not tell you any different, because it is the same frame.

1. Press Send in the preview and watch for anything at all — a thank-you line, a message under the form, a field turning red. Any of those and the ordinary kind was written. There was never anything to fix.
2. If nothing happens whatsoever, the submit kind was written. Ask for it in one line: make the send button an ordinary button that runs on a click rather than a form submit.
3. Press it again after the change. What works in the preview works on the free address too.

Note. We tell the builder to write the ordinary kind, and the same instructions carry a sample written the other way, so both keep turning up. That is our mistake rather than anything about how you asked.

You pressed Fix, were charged, and it is still broken

When something inside the frame throws an error, the preview lays a card over it — This doesn't compile, or The page crashed while running — with a button reading Ask Grafter to fix it. There is a standing version of the same offer above the message box that says the preview is broken.

Pressing it sends a real change to the builder and costs a turn like any other. For most errors it is the right button. For two of them it is not, and we should not be offering it at all: an error mentioning security or storage, and a submit button that does nothing, are both the frame refusing to do something rather than a mistake in your site. No rewrite removes the cause, so the card comes back and the turn is gone.

There is still something worth asking for, and it is a different request. A page that crashes on a storage error is a page that gave up when the browser said no. Ask for the app to carry on when the browser refuses to save, and it stops crashing on every surface while still saving properly once it is on hosting of your own.

• Worth pressing Fix for: a module that cannot be found, a name that is not defined, a blank preview after a build ran out of time.
• Not worth pressing Fix for: SecurityError, anything about storage being refused, a submit button that does nothing.
• Worth one turn instead: asking for the app to keep working when the browser will not let it save.

Tip. A crash card in the editor matters more than it looks. The free address is the same frame with no card on it, so a site that crashes here is a blank page for whoever you sent the link to.

The phone number won't dial and the map is blank

The frame has no way to leave itself. It cannot open a new tab, it cannot hand a number to the phone's dialler, and it cannot pull in a map or a Facebook page. A link out does not fail slowly or look blocked. It does nothing at all.

This is the one that costs people work, because it holds on the address you hand out as well. A tap-to-call number that looks live while you are building is dead on the phone of the customer you gave the link to, which is the worst possible place to find out.

Requests the site makes quietly in the background are a separate matter and are not blocked. That is why a contact form can still deliver from inside the frame while a link next to it cannot open.

The builder is also told never to write a web address it was not given, so a map or a social link is usually missing rather than broken. On a trade site it is told to write the area out as named towns and postcodes instead of embedding a map at all.

1. Check the number is on the page as large readable text near the top, rather than sitting behind a Call button and nothing else. That is what the builder is told to do, and it means somebody on a phone can read it off and dial it by hand while the tap-to-call link is dead.
2. If you need a dialler link, a map or a payment link to actually work, publish the site to hosting of your own. Nothing is sealed there.

Note. Nothing has been lost while you sort this out, and nothing needs rebuilding. The same files behave differently in the two places because of where they are running, not because of what they say.

Where a lead from your form actually goes

A contact form built now posts what a visitor types back to us, and it appears on the Leads screen in the left-hand column of that site's dashboard. It arrives from the free address and from hosting of your own alike.

The part worth knowing is that the visitor is always thanked. The address the form posts to answers with a success whatever happened at our end, because the person on the other side is a member of the public filling in a form on a plumber's website and there is nothing useful to tell them. The cost of that is unkind: a form that delivers and a form that delivers nothing look identical from the outside.

And which one you have is not something you can work out by reading the page. The instructions we send the builder used to contradict each other, so a site built before August 2026 may have been given a form that shows a thank-you and keeps what it collects. That is ours. The instructions agree now, but it does not go back and repair a form already built, so trying yours is the only way to know.

1. Open the address you hand out, fill the form in with your own name and number, and send it.
2. Open that site's dashboard and choose Leads.
3. If it is there, the form delivers. If it is not, ask for it in one line: make the contact form send leads to my Grafter dashboard.

Tip. A test message is a real lead and lands in Leads with the rest. Put something in the message you will know your own hand by, so you can tell it from a real one later.

Note. If you were told at some point that a contact form here does not send anything, that was true once and was still being said in the help, the terms and the menu that builds the form long after it stopped being true. Those are corrected. Open Leads before you assume it is empty: there may be leads sitting in it that you were told could not exist.

A client's form that worked and then stopped

An exported site is less self-contained than it looks, and this is the one place that costs somebody real money.

The form inside it, and the counter that feeds the visitor numbers, both point back at the Grafter project the site was built in, with our full address written into the code. A relative one would look for the form's destination on the client's own host and find nothing there, which loses every lead silently — so the absolute address is the lesser of two bad options rather than an oversight.

The consequence is that a site living on somebody else's hosting keeps filing its leads into the project here, indefinitely. They arrive on your Leads screen rather than the client's. And if you delete that project when the job is done, the leads stop arriving and nobody is told: the visitor still reads a thank-you and the message is thrown away as it comes in.

That is our design and our fault to carry. It is worth knowing before you tidy up rather than afterwards.

1. If you have handed a site over, leave its project here alone. Deleting the project is what quietly ends the form.
2. Tell the client where their leads land, and either forward them or hand over the account holding the project.
3. If the site is being handed over properly, ask for the form's destination to be changed to something of the client's own before you deliver it.

Tip. Anyone who has already deleted a project should assume leads have been lost since that day rather than that there were none. Nothing is written down at our end either, so there is nothing to go back for.

Right in the editor, and the publish fails

The other direction. A site that looks finished in the preview and on the free address, and then will not build when you send it to hosting of your own — and will not start from the downloaded zip either.

The usual cause is one missing file, and the preview is what hid it. Every project needs a small file whose only job is to mount the site: src/main.jsx. A build that ran out of time very often has not written it yet, because the builder writes the design and the sections before it writes the thing that starts them. The preview does not mind. It finds your main component, writes a stand-in and mounts that instead, so what you are looking at is a finished-looking site. Real hosting has no stand-in to fall back on.

So the tell is in the file list rather than on the page.

1. Open the Code tab and look down the file list for src/main.jsx.
2. If it is not there, ask for it: add src/main.jsx that mounts App and imports the stylesheet.
3. Publish again. Nothing else needs redoing.

Note. The preview does mention it, quietly — a small note appears among the preview's own controls, and resting on it says it mounted your main component directly. It is easy to read past, and it is the same fact as the failed publish.

Common questions

Which address should I test on?

For anything that stays inside the page — the layout, the wording, buttons that only change what is on screen — the editor's preview is enough. For saving, a dialler link, a map or anything else that leaves the page, only hosting of your own tells you the truth.

Do leads from the free grafter.build address reach me?

Yes, if the form was written to post them. The frame is sealed against links opening, not against the site sending a request. Send yourself one and check the Leads screen.

Will my visitors lose what they type on the live site?

Not on hosting of your own. An app there saves in each visitor's own browser and survives a reload. On the free address nothing is saved, because that address is the same sealed frame as the preview.

Does pressing Fix cost credits when there is nothing to fix?

Yes. It sends an ordinary change to the builder and is charged like one, whatever it finds. That is why a storage error is not worth pressing it for, and why we should not be putting the button there.

I deleted a project. Can the leads it lost be recovered?

No. A message arriving for a project that no longer exists is discarded as it comes in and nothing is written down, so there is nothing to go back and read.