A static-file handoff, made clear — with a little gremlin energy

Your words
survive the refresh.

Meta Sites keeps the content in the page itself. Muse edits the file. Git-FED uploads it. GitHub Pages serves the exact version you published.

Follow the signal How persistence works Support Git-FED

Static between edits. Persistent after refresh.

M·

THE PAGE FILE

GGoogle Sitespoints to the page

PGitHub Pagesserves the file

MMuseedits the HTML

FGit-FEDuploads the update

ONE FILE · ONE PUBLISHED VERSION

The handoff

A simple chain.
No mystery storage.

Each step has one job. The published HTML is the source of the text visitors see.

01↗

Google Sites links

It points visitors to the GitHub Pages URL or embeds that published page.

ENTRY POINT

02⇢

Git-FED sends

The current HTML and any requested text or images are sent to Muse for the edit.

HANDOFF IN

03✎

Muse edits

The requested changes are made in the supplied page files, then handed back.

FILE EDIT

04↑

Git-FED uploads

Git-FED uploads the returned version. GitHub Pages publishes that version.

LIVE VERSION

The important distinction

Refresh reloads
the same file.

The page is not a live conversation or a database. Its text stays because the text is part of the published page. A refresh asks the same host for the same file again.

Read the persistence note

index.htmlPUBLISHED

01<main>

02 Your text is part of this page.

03 Refresh → reload this same file

04</main>

✓ CONTENT LIVES IN THE PUBLISHED FILESTATIC · PERSISTENT

01 / HOSTING

Google Sites is the doorway.
Pages is the page host.

Google Sites alone reloads its own published copy. For the Muse-edited text to appear on refresh, visitors must reach the host serving the edited file: GitHub Pages.

Understand the difference

02 / SETTINGS