Google Sites for Business: Intranets and Internal Sites

Google Sites is a Google Workspace tool for creating team sites, project spaces, internal portals, and informational pages without building a custom application. Its main advantage is integration with the Workspace ecosystem and a visual editor that non-technical users can maintain.

It is not a replacement for every type of website. It works especially well when the goal is to organize and share information.

What you can build

Common business use cases include:

• Intranet.
• Onboarding portal.
• Project site.
• Knowledge base.
• Internal manual.
• Training center.
• HR portal.
• Event site.
• Procedure library.
• Internal directory.

The tool is appropriate when the priority is publishing information and resources rather than implementing complex transactional logic.

How a site is created

Google Sites can start from a blank site or a template.

The editor allows you to:

• Create pages.
• Organize navigation.
• Add text.
• Insert images.
• Add buttons.
• Embed Google resources.
• Change themes.
• Preview the result.

Changes are saved automatically, while the site remains unpublished until you publish it.

Google Workspace integration

One of the main benefits is the ability to embed Workspace content.

Examples include:

• Docs.
• Sheets.
• Slides.
• Forms.
• Charts.
• Calendar.
• YouTube.
• Maps.
• Drive files.

This allows a portal to organize information that already exists.

Instead of copying a procedure into a second location, you can link or embed the original source.

File permissions still matter

Embedding a document does not automatically make it visible to everyone.

If a Drive file has restricted access, visitors still need the appropriate permissions.

Before publishing an intranet, review both site permissions and embedded-document permissions.

This is one of the most important operational details.

Who can view the site

Google lets you control who can view a published site.

Options may include:

• Restricted.
• Public.
• Additional organization-specific choices.

For work or school accounts, administrators may limit some options.

For an intranet, restricted access to the correct people or groups is usually appropriate.

Editors versus viewers

It is also important to separate:

**Editors:** can modify the site.

**Viewers:** can read the published version.

Do not grant edit rights simply because a person needs to read content.

Fewer editors reduce accidental changes.

Preventing editors from changing permissions

Google Sites can restrict whether editors may publish, change permissions, or add new people.

For an important business portal, the owner can limit those capabilities.

This helps maintain control of access administration.

Simple intranet structure

An initial navigation might be:

**Home**

• News.
• Quick access.
• Announcements.

**People**

• Contacts.
• Organization information.
• HR resources.

**Processes**

• Procedures.
• Manuals.
• Forms.

**Projects**

• Documentation.
• Calendars.
• Status.

**Training**

• Materials.
• Video.
• FAQs.

Do not create 50 pages before understanding what users actually need.

Home page

An intranet home page should answer:

• What is important today?
• Which links are used most?
• Where are procedures?
• How do I contact a department?
• What changed recently?

A page full of banners may be less useful than a simple information structure.

Single source of truth

Google Sites works best when it organizes official sources.

For example, instead of copying a policy from Docs into Sites, embed the original document.

That avoids maintaining two versions.

For critical information, explicitly define which location is the official source.

Internal forms

Google Forms can support:

• Requests.
• Surveys.
• Incident intake.
• Feedback.
• Registration.

The page can combine the form with instructions and contacts.

Calendars

Embedded calendars can show:

• Events.
• Training.
• Project dates.
• Meetings.
• Deadlines.

Review calendar permissions so users see only appropriate information.

Onboarding

An onboarding portal can include:

• Welcome.
• First steps.
• Policies.
• Tools.
• Contacts.
• Forms.
• Training.
• FAQs.

A central portal reduces the number of separate links that must be sent to every new employee.

Project sites

For internal projects, Sites can collect:

• Objective.
• Team.
• Timeline.
• Documents.
• Status.
• Risks.
• Meetings.
• Forms.

Google recommends Sites for project information and integration with calendars, spreadsheets, and documents.

Design

Google Sites does not provide the same customization as a custom application.

That can be an advantage when the priority is fast publication.

Focus on:

• Clear headings.
• Short navigation.
• Readable typography.
• Reasonable page length.
• Descriptive buttons.
• Visual consistency.

Mobile

Sites provides preview options for different layouts.

Before publishing, review:

• Phone.
• Tablet.
• Desktop.

Pay attention to embedded documents and large elements.

Maintenance

An intranet loses value when content becomes outdated.

Define:

• Owner.
• Editors.
• Review frequency.
• Validity dates.
• Department owner.
• Archiving process.

Critical pages can include a “Last reviewed” field.

Search and navigation

As the site grows, architecture becomes more important.

Use names people recognize.

“Resources” may be too generic.

“HR Forms” is easier to find.

Privacy

Do not publish sensitive information simply because the site is internal.

Apply controls appropriate to the data type.

Take special care with:

• Personal information.
• Financial data.
• Credentials.
• Medical data.
• Contracts.
• Customer information.

Google Sites does not replace an information-classification policy.

When Google Sites is not enough

It may be the wrong tool when you need:

• Ecommerce.
• Custom backend.
• Complex business logic.
• Custom authentication.
• Highly specific roles.
• Transactional workflows.
• Advanced custom integrations.
• Fully custom design.
• SaaS application behavior.
• Heavy processing.

A custom web application may be more appropriate in those cases.

Google Sites versus Drive

Drive organizes files.

Sites organizes the experience of accessing them.

They complement each other.

A company can store documents in Drive and use Sites as the navigation layer.

Publishing

Google lets you preview the site before publishing.

The owner then defines the site address and who can view it.

For internal portals, test access using a normal user account rather than only the administrator account.

Official sources

See Google's official guides for creating a Google Site, publishing and permissions, and embedding Google files.

Intranet checklist

Before publishing:

1. Define the purpose.

2. Build simple navigation.

3. Limit editors.

4. Review viewers.

5. Check permissions on embedded files.

6. Test mobile.

7. Define owners.

8. Mark critical content.

9. Review privacy.

10. Establish maintenance.

11. Test with a real user.

12. Confirm official information is not duplicated.

Google Workspace in SG Hub

If you are planning an intranet in Google's ecosystem, see the Google Workspace for business guide and the Google Drive guide.

Google Sites creates the most value when it works as an entry point to reliable information. The technology is simple; the real work is structure, permissions, and maintenance.