# Move Exported Grok Website Files to Another Host

> Export a Grok Build site to GitHub, deploy it on Cloudflare Pages, Netlify, Vercel or GitHub Pages, test it, then retire the grok.me copy.

## Move a Grok Build website without breaking it

Grok Build publishes each app to its own `grok.me` address. You choose who can open it: only you, anyone with the link, or the whole internet ([xAI announcement](https://x.ai/news/grok-build-for-everyone)). Grok Build can also export the whole project to GitHub. That export is the cleanest way to move a site to a host that you control. Examples of such hosts are Cloudflare Pages, Netlify, Vercel, and GitHub Pages.

In short, treat the move as a static-site migration. A static site is a site of plain files with no server code. Find out what the project depends on, and then export it to GitHub. Deploy it on the new host from that repository. Test it at a temporary address. Keep the grok.me version until the new site passes every test. Then retire (take offline) the grok.me version.

![Grok start page, where you sign in to reach your Build projects](/assets/en/blog/how-to-migrate-a-grok-build-website-to-revdoku/grok-service-page.webp)

*Sign in to Grok. Open the Build project that contains the website that you want to move.*

## What can move away from grok.me

A website made of HTML, CSS, browser-side JavaScript, images, fonts, and downloadable files can run on almost any static host. A complete move needs the full project, not only the text of the public page.

Some Grok Build projects use more than static files. Examples are data from connectors, sign-in, stored data, server functions, and AI features. None of that moves with the files. Each part needs its own replacement on the new host, or you must remove it.

## 1. Ask Grok for a dependency check

Before you export anything, ask Grok what the project relies on:

```text
Audit this Grok Build website for migration to a static host.

List every HTML, CSS, JavaScript, image, font, document, and data file.
Identify server functions, databases, storage, authentication, secrets,
external APIs, connectors, AI features, and platform-only services.
Tell me which parts can run as a static website and which need replacement.
Tell me the build command and the output folder, if the project needs a build.
Do not print or copy private credentials.
```

This prompt finds backend dependencies (server parts that the site needs). A polished preview hides them.

## 2. Export the project to GitHub

Use the **Export to GitHub** option in Grok Build to push the whole project to a repository ([xAI](https://x.ai/news/grok-build-for-everyone)). Then open the repository on GitHub and make sure that:

- `index.html` exists at the root, or the project has a build step that makes it.
- The folders are intact. If you move CSS, JavaScript, or images out of their folders, relative links break.
- Every image, font, script, and data file that the site uses is present.
- The repository has no API keys, passwords, `.env` files, private prompts, or customer data. If someone committed a secret, rotate it (replace it with a new one). If you only remove the file, the secret stays in the history of the repository.

If you cannot use the export, ask Grok to list every file with its full path and contents. Then make the same folder structure on your computer. A page that you save from your browser is not enough. It misses other routes, scripts that load later, and files that the page only links to.

## 3. Prepare the folder for a static host

If the project uses a framework, it needs a build. Run the build locally, often with `npm install` and then `npm run build`. Write down the output folder, usually `dist`, `build`, or `out`. If the project is plain HTML, the repository root is the site.

Before you deploy, preview the site. From the site folder, run `python3 -m http.server 8000`. Then open `http://localhost:8000`. If you open `index.html` directly from disk, problems with absolute paths and scripts can stay hidden.

You can also ask Grok to do this cleanup in the same session:

```text
Prepare this project for hosting outside grok.me.

1. Put index.html at the site root, or tell me the build command and output folder.
2. Keep all directories and relative paths.
3. Remove secrets, API keys, environment files, private prompts,
customer data, and local computer paths.
4. Replace any grok.me-only service with a placeholder and list each one.
5. List every file in the final output so I can compare it with the repository.
```

The agent must report missing or changed files. It must not quietly declare success.

## 4. Deploy to the new host

Choose one host. Connect it to the GitHub repository, so that every later commit deploys automatically.

- On Cloudflare Pages, go to **Workers & Pages**. Select **Create application > Pages > Connect to Git**, and choose the repository. Set the **Build command** and the **Build output directory**. For plain HTML, leave the build command blank. Select **Save and Deploy** ([Cloudflare docs](https://developers.cloudflare.com/pages/get-started/git-integration/)).
- On Vercel, open the New Project page. Connect GitHub. Select the repository, and then select **Deploy**. Vercel detects common frameworks and their build settings ([Vercel docs](https://vercel.com/docs/getting-started-with-vercel)).
- On Netlify, connect the repository. You can also skip Git and drag the built output folder onto the deploy drop zone of Netlify ([Netlify docs](https://docs.netlify.com/deploy/create-deploys/)). A drag-and-drop deploy does not connect the repository. For later updates, you must upload again.
- On GitHub Pages, you can publish plain HTML from the exported repository. Go to **Settings > Pages**. Set **Source** to **Deploy from a branch**. Choose the branch and the root folder, and then select **Save** ([GitHub docs](https://docs.github.com/en/pages/getting-started-with-github-pages/configuring-a-publishing-source-for-your-github-pages-site)). On GitHub Free, the repository must be public. The site is public in all cases.

For tests, use the host's own address (for example `your-project.pages.dev`). Do not move the domain yet.

## 5. Test static and single-page routing

A site with one HTML file for each path works as it is. A single-page app is an app in which JavaScript handles every route from one `index.html`. For this type of app, the host must send unknown paths to that file:

- Cloudflare Pages does this automatically when the project has no top-level `404.html` ([Cloudflare docs](https://developers.cloudflare.com/pages/configuration/serving-pages/)).
- Netlify needs a `_redirects` file in the published folder with the rule `/* /index.html 200` ([Netlify docs](https://docs.netlify.com/manage/routing/redirects/rewrites-proxies/)).
- GitHub Pages has no rewrite rules. For missing paths, it serves a custom `404.html`. For this reason, put a single-page app on one of the other hosts.

Open the new address in a private window. Then test these items:

- The homepage and every navigation link
- A direct reload on a nested path, such as `/about` or `/pricing`
- Images, fonts, icons, and styles
- Forms, buttons, and downloads
- Desktop and mobile layouts
- The browser console (look for errors)
- Every feature that the dependency check flagged

## 6. Choose who can see the new site

Publish the site publicly only if it is for a general audience. For client work or private reviews, set access control before you share the link:

- On Cloudflare Pages, add Cloudflare Access and use the one-time PIN login. This login sends a code by email to the addresses that you allow ([Cloudflare docs](https://developers.cloudflare.com/pages/platform/known-issues/)).
- On Netlify, basic password protection needs a Pro plan or higher ([Netlify docs](https://docs.netlify.com/manage/security/secure-access-to-sites/password-protection/)).
- On Vercel, use Deployment Protection with Vercel Authentication, or Password Protection on a paid plan ([Vercel docs](https://vercel.com/docs/deployment-protection)).
- GitHub Pages has no password option. Only GitHub Enterprise Cloud organizations can publish privately.

An unlisted URL (a link that you do not publish anywhere) is not access control. Our [Google test of Grok Build websites](/blog/are-grok-build-websites-public-and-indexed-by-google/) found many grok.me sites in search results.

## 7. Move the domain and retire the grok.me copy last

After the new site passes every test:

1. If the site used a custom domain in Grok, add the domain on the new host. Then update the DNS records there.
2. In Grok, set the visibility of the old site to only you.
3. Open the old grok.me URL in a private browser window. Make sure that it no longer shows the site.
4. Update shared links, bookmarks, and anything that pointed at the old address.
5. Send the new URL to the intended audience.

Keep a local copy of the last working release. If something breaks during the switch, you can deploy that copy again.

## The migration limit to remember

Static files move between hosts. Hosted backends do not. Server functions, databases, stored data, sign-in, scheduled jobs, connectors, and platform-only AI features each need separate work on the new host.

A reliable move follows this order: find the dependencies, export, deploy to a test address, and test. After that, set access, switch the domain, and retire the original.

A docs portal with Ask AI
and support tickets

Connect a repository, or describe your product to start. Each docs site has search, Ask AI, an API console, an MCP server and support tickets.

Publishes from GitHub on every push

Works with Mintlify repositories

API console from your OpenAPI file

MCP server and llms.txt for AI agents

Ask AI and support tickets

Analytics for people and AI agents

Start Free →

Questions? Ask AI in our docs
No card required.

## Frequently Asked Questions

### Can I keep using Grok to edit the site after the move?

Yes, you can work through the exported repository. xAI describes the GitHub export as a way to continue the work on the project in an editor or in Grok Build for the terminal. If you connect the new host to that repository, each commit that you push deploys a new version.

---

[View the canonical page](https://revdoku.com/blog/how-to-migrate-a-grok-build-website-to-revdoku/) · [Browse llms.txt](https://revdoku.com/llms.txt)
