Why Your Google Site Says 404, and How to Fix Previews, Speed and Mobile
Google Sites is a quick way to get a small business or project online, but it hides most of the technical controls other platforms give you. When a published page shows a 404 error, a shared link has no proper preview, pages feel slow or the layout breaks on phones, the fix is often a setting in the editor rather than code. Some problems cannot be fixed inside Google Sites at all, and it helps to know which before you spend an afternoon on them. This guide explains why a Google Site says 404, how to diagnose it from the outside, and what you can realistically do about link previews, page speed and mobile usability.
- What you can and cannot change in Google Sites
- Why your Google Site says 404 error
- How to diagnose a Google Sites 404
- How to fix the link preview of a Google Site
- How to fix page speed on a Google Site
- How to fix mobile usability on a Google Site
- The fix, step by step
- Edge cases worth knowing
- Keeping a Google Site healthy
- Questions and answers
What you can and cannot change in Google Sites
Google Sites hosts your pages on Google's own servers and writes the HTML for you. You cannot edit the head of the page, upload files to the root, add server redirects or change response headers. That rules out a lot of the usual fixes, so start by knowing where the edges are:
| Area | You can change | You cannot change |
|---|---|---|
| Addresses | Site address, page names and the custom path of each page | Redirects from old paths to new ones |
| Publishing | Publish, unpublish, who can view, search engine request | Status codes or error pages |
| Domain | Connect a custom domain you own | Server or hosting settings |
| Head tags | Site name, page titles, favicon | Meta descriptions, Open Graph tags, canonicals, schema |
| Content | Text, images, embeds, layout blocks, page order | Theme code, scripts in the page itself |
| Measurement | A Google Analytics measurement ID in settings | Other tracking tags in the head |
Code you add with the Embed option runs inside a sandboxed frame on a separate Google domain, not in your page. Meta tags, verification tags or structured data pasted into an embed therefore do not affect how search engines or social apps see your page. If you need full control over any of the right-hand column, a different platform is the real fix, and the guide to improving website SEO explains what that control buys you.
Why your Google Site says 404 error
A 404 means the server was reached but has nothing at that address. On Google Sites the causes are nearly always one of these:
| Cause | What you see | Fix |
|---|---|---|
| Page never published | You can open it in the editor and preview, visitors get a 404 | Click Publish again; new pages are not live until you do |
| Page renamed or path changed | Old links and bookmarks 404, the new address works | Set the custom path back, or update every link to the new one |
| Page deleted | The address 404s for everyone | Restore it from version history or recreate it with the same path |
| Site address changed | Every old link under /view/old-name 404s | Change the site address back, or update links everywhere |
| Custom domain not set up fully | Your domain shows a Google error page | Fix the DNS record and finish the custom domain step |
| Site unpublished | Every page 404s for visitors | Publish the site again |
Two near misses look similar but are not 404s. If viewing is limited to people in your organisation, outside visitors are asked to sign in or told they need access. And if you are signed in as an editor, you may see pages that the public cannot, so always test in a private window.
Because Google Sites cannot redirect an old path to a new one, a renamed page leaves every link to the old address broken. Search results, social posts, printed QR codes and other websites all keep pointing at the old address. The safest rule is simple: once a page is published and shared, do not change its path. The wider guide to a website showing 404 errors covers the same problem on platforms that do allow redirects.
How to diagnose a Google Sites 404
Test from the outside, the way a visitor or Googlebot sees the page. First, open the address in a private browser window where you are not signed in. Then check the status code from a terminal:
curl -sI https://sites.google.com/view/example-bakery/wedding-cakes | head -1A line ending in 200 means the page is live. A 404 means the path does not exist on the published site. A redirect to a sign-in address means viewing is restricted.
Next, compare the address with what the editor says. In the Pages panel, open the menu next to the page, choose Properties and look at the custom path. The last part of the public address must match it exactly, including hyphens.
Custom domain checks
If the site uses your own domain, check the DNS record for the subdomain you connected. Google's instructions for Sites use a CNAME pointing to ghs.googlehosted.com:
dig +short www.example.com CNAME
# expected: ghs.googlehosted.com.If the record is missing, points elsewhere, or you connected the bare domain without a forwarding rule from your registrar, visitors land on a Google error page instead of your site. Also check that the domain is verified to the same Google account that owns the site, and that it is listed under Settings, then Custom domains.
How to fix the link preview of a Google Site
When you paste a link into WhatsApp, Facebook, LinkedIn or Slack, the app fetches the page and reads its Open Graph tags to build a card. On most platforms you set those tags yourself. On Google Sites you cannot: Google writes them for you, based mostly on the site name and page title. Check what it outputs with:
curl -sL https://sites.google.com/view/example-bakery/ | grep -io '<meta property="og:[^>]*>'That shows you exactly what social apps receive. What you can improve:
- Site name and page titles. Give each page a clear, specific title. That is the line people see in bold on the card.
- Public viewing. If the site is limited to your organisation, the app cannot read the page and shows a bare link or a sign-in card. Publish to the public if the link is meant for customers.
- The first image on the page. Some apps fall back to an image they find on the page when no image tag suits them. A clear header image at the top gives them something sensible to use, though this is not guaranteed.
- Stale cache. Social apps remember previews. After you change a title, the old card can persist. The preview cache guide shows how to refresh it for each app.
Use the social preview checker to see the card each app will build before you share. If you need a custom image, description and title on the card for every page, Google Sites cannot give you that, and the missing Open Graph tags guide shows what those tags look like on a platform that allows them.
How to fix page speed on a Google Site
You cannot change Google's servers, caching or scripts, so the speed you can gain comes from what you put on each page. Test the public address in PageSpeed Insights on mobile, and look at which elements the report names.
The usual causes on Google Sites, in rough order of impact:
- Embeds. Every embedded Google Map, Calendar, YouTube video, Form, Doc or Slides deck loads its own scripts in a frame. Three or four on one page can add megabytes. Keep embeds to the pages that need them, and consider linking to a Form or Calendar rather than embedding it.
- Large images. Phone photos uploaded straight from the camera are often 4,000 pixels wide or more. Resize to about 2,000 pixels wide at most, and compress them before upload.
- Image carousels and many images above the fold. Each one competes with the main image for bandwidth.
- Very long pages. A home page holding everything, from opening times to a gallery to a full menu, loads it all at once. Split it into pages.
A video embed is often the heaviest element. Replacing it with an image linked to the video on YouTube removes the player scripts from the first load. For background on the metrics, see the guide to checking page speed and the image speed guide.
How to fix mobile usability on a Google Site
Google Sites layouts are responsive: text and image blocks stack into one column on a phone. Problems come from content that does not resize. In the editor, click Preview and switch to the phone view to see the page at mobile width before publishing.
- Embedded code with a fixed width. An embed with
width="900"forces sideways scrolling. Use a percentage width, or let the embed block size itself. - Text inside images. Price lists, menus and posters saved as images become unreadable at phone width. Put the text on the page as text.
- Embedded Sheets and Docs. These show at desktop scale inside a small frame. Link to them instead, or copy the key content onto the page.
- Buttons and links too close together. Leave space between buttons in a row so a thumb can hit the right one.
Search Console's old Mobile Usability report was retired at the end of 2023, so do not expect it there. Lighthouse in Chrome DevTools, run in mobile mode, still flags small tap targets and content wider than the screen. The mobile Core Web Vitals guide covers how phone performance is measured.
The fix, step by step
Step 1
Test the page as a visitor
Open the failing address in a private browser window where you are not signed in to Google. Then run curl -sI on it and read the first line. A 200 means the page is live, a 404 means the path does not exist on the published site, and a redirect to a sign-in page means viewing is restricted. Note the exact address that fails, including the site name and page path, before changing anything.
Step 2
Publish the latest version
In the Google Sites editor, click Publish in the top right and confirm. New pages and renamed pages do not exist for visitors until the site is published again. In the publish settings, check who can view the published site and that it is not limited to your organisation if customers need it. Reload the address in the private window; if it now shows the page, the 404 was an unpublished change.
Step 3
Match or restore the page path
Open the Pages panel, click the menu next to the page and choose Properties. Compare the custom path with the address that fails. If the page was renamed, set the old path back so existing links work again, then publish. If the page was deleted, restore it from version history or recreate it with the same path. Confirm with curl -sI that the old address now returns 200.
Step 4
Fix the custom domain
If your own domain shows a Google error, run dig +short www.example.com CNAME and confirm it returns ghs.googlehosted.com. If not, add or correct the CNAME at your DNS provider. Check that the domain is verified to the account that owns the site and listed under custom domains in settings. Add a forwarding rule from the bare domain to www at your registrar. Allow time for DNS to update, then test again.
Step 5
Update links that point to old addresses
List every place that links to the page: menus inside the site, buttons, your Google Business Profile, social profiles, email signatures and other websites you control. Change each one to the live address. Because Google Sites cannot redirect, this is the only way to repair links you cannot restore with the old path. Run a broken link check on the site afterwards and confirm no internal link returns 404.
Step 6
Improve the link preview
Give each page a clear, specific title and make sure the site name reads well, because Google Sites builds the preview from them. Put a clear image near the top of important pages. Publish, then check the output with curl -sL and grep for og: tags, or use a social preview checker. If an app still shows the old card, refresh its cache using the app's own debugging tool before sharing again.
Step 7
Lighten heavy pages
Run the public address through PageSpeed Insights on mobile and note the heaviest elements. Remove embeds that are not essential, swap a video embed for an image that links to the video, resize photos to about 2,000 pixels wide and compress them before uploading, and split very long pages into several. Publish, test again and compare the Largest Contentful Paint and total page weight with the first run.
Step 8
Check the phone layout
Click Preview in the editor and switch to the phone view. Scroll every important page looking for sideways scrolling, text inside images, cramped buttons and embeds shown at desktop size. Replace fixed widths in embedded code with 100%, turn image text into page text, and link to Docs and Sheets rather than embedding them. Publish and confirm on a real phone, then run Lighthouse in mobile mode.
Edge cases worth knowing
- Search engine request. The publish settings include an option asking public search engines not to show your site. If your site is live but never appears in Google, check that this is switched off.
- Old classic Sites addresses. Sites built before the current editor used addresses under
/site/. If you rebuilt rather than converted such a site, links to the old addresses may no longer work. Update links you control and re-share the new address. - Workspace restrictions. An administrator can stop users publishing sites outside the organisation. If the public option is missing, ask whoever manages your Google Workspace.
- Bare domain. A CNAME cannot be used on the bare domain, so a site set up on www needs your registrar to forward
example.comtowww.example.com. Without it the bare domain fails. - Indexing takes time. A newly published page is not instantly in Google. Use URL Inspection to request indexing; the guide to checking if a page is indexed explains how to read the result.
Keeping a Google Site healthy
Most Google Sites problems come from changes made after a page was shared. A short routine prevents them:
- Fix paths before you share. Choose short, permanent custom paths when you create a page, and do not rename them after publishing.
- Publish after every change. Edits sit in draft until you click Publish. Check the live address in a private window afterwards.
- Check links monthly. Run a crawl or a broken link check across the site to catch links to deleted or renamed pages.
- Keep pages light. Before adding an embed, ask whether a link would do. Resize photos before every upload.
- Watch Search Console. New 404s in the Page indexing report usually mean a page was renamed or deleted.
1. Why is my Google Site saying 404 error?
Your Google Site says 404 because the published site has nothing at that exact address. The most common reasons are a new page that has not been published yet, a page whose name or custom path was changed after links were shared, a deleted page, a changed site address, or an unfinished custom domain set-up. Test in a private window, check the custom path in the page properties, publish the site again and compare the failing address with the live one.
2. Can I set up redirects on Google Sites?
No, Google Sites does not offer redirects from one page path to another, so a renamed or deleted page leaves old links broken. Your options are to set the old custom path back on the page, recreate a page at the old path with a link to the new one, or update every link that points to the old address. If you need proper 301 redirects, you will need a platform or host that lets you control them, or a custom domain set-up that routes through a service you control.
3. How do I fix the link preview for my Google Site?
You fix a Google Sites link preview mainly through the site name and page titles, because Google writes the Open Graph tags for you and the editor does not let you edit them. Make sure the site is published publicly, give each page a clear title and place a good image near the top. After publishing, refresh the social app's cache with its debugging tool. If you need full control over the preview image and text, Google Sites cannot provide it.
4. How do I make my Google Site load faster?
You make a Google Site faster by reducing what each page loads, because you cannot change Google's hosting. Remove embeds that are not essential, especially maps, calendars, videos and documents, resize and compress photos before uploading, avoid stacking many images at the top of the page and split very long pages into shorter ones. Test the public address in PageSpeed Insights on mobile before and after so you can see which changes helped.
5. Why does my Google Site look wrong on mobile?
A Google Site looks wrong on mobile when content inside it does not resize, because the layout itself is responsive. The usual culprits are embedded code with a fixed pixel width, text saved inside images, embedded Sheets or Docs shown at desktop scale, and buttons placed too close together. Use the phone view in Preview to find them, replace fixed widths with percentage widths, put text on the page as text and link to documents rather than embedding them.
6. Why does my custom domain show a Google error page?
A custom domain shows a Google error page when the DNS record or the custom domain step in Google Sites is incomplete. Check that the subdomain you connected, usually www, has a CNAME record pointing to ghs.googlehosted.com, that the domain is verified to the same Google account that owns the site and that it appears under custom domains in the site settings. A bare domain needs a forwarding rule at your registrar, because a CNAME cannot be set there.
7. Can a Google Site rank in Google search?
Yes, a public Google Site can be indexed and rank like any other site, but you have fewer tools to help it. You cannot add meta descriptions, structured data or canonical tags, so clear page titles, useful text on the page and links from other sites matter even more. Check that the publish setting asking search engines not to show the site is switched off, then use URL Inspection in Search Console to request indexing of key pages.
The site audit crawls your published Google Site, lists every link that returns a 404 and shows the preview tags each page sends, so you know exactly what to republish or relink.
Open Site Audit Fixes →