Google Sites will build a page in an afternoon, which is exactly why it gets chosen. Then the contact page comes up, the Insert panel gets opened, and there is no form in it. There are images, text boxes, buttons, tables of contents, YouTube videos, calendars and maps, and no way to ask a visitor for their email address.
That is not an oversight. Google Sites is a page builder, and the form belongs to a different product. The question is which of the three available routes to take, because they differ in how the page looks, who can see the responses, and what breaks after the site is published.
What the Insert panel actually offers
The Insert panel in Google Sites has a section at the bottom for Google files: Docs, Slides, Sheets, Forms and Charts. Choosing Forms opens a picker of the Google Forms in your Drive and drops the selected one into the page. Above that sits Embed, which takes either a URL or a block of code. Google documents that the code option accepts HTML, CSS and JavaScript, with JavaScript inside script tags and CSS inside style tags. The same embed can be made into a whole page rather than a block, through Pages, then hovering over Add, then Full page embed. All of it is described on the Google Sites help page for adding content.
So three routes exist, and every contact form on a Google Sites page is one of them.
| Route | What the visitor sees | Where responses land | Main risk |
|---|---|---|---|
| Insert a Google Form | A Google Form in a frame, Google styling | Google Forms, then a Sheet if linked | Permissions and the publish switch |
| Embed a form from another tool | That tool's form in a frame | That tool's response list | Frame height on a phone |
| Embed code with your own markup | Your markup | Wherever the action points | No server unless you add one |
None of these puts a form into the page as native Google Sites content, because that does not exist. Every one of them is a frame with something else inside it.
Route one: insert a Google Form
This is the path of least resistance and the one most sites take. Build the form in Google Forms, then in the site editor click Insert, choose Forms, pick the form, and publish the site.
Two things have changed here recently enough that old instructions are wrong about them, and both produce a form that appears to work in the editor and fails for visitors.
The first is publishing. A Google Form now has its own publish state, separate from the site's. Google's documentation is blunt about it: if the form is unpublished, responders with the link cannot access it. Building the form, embedding it, and publishing the site is three of the four steps. The form itself has a Publish button at its top right, and until it is pressed the embedded frame turns visitors away. The Google help page on publishing a form covers the settings that sit alongside it, including whether responses can be edited afterwards and what the confirmation message says.
The second is sharing. Anything embedded from Drive carries its own permissions, and those permissions are not inherited from the site. Google's guidance is to share file access with site viewers when the site is published, and the editor will warn that not all collaborators can reach the embeds. A form restricted to one organisation, embedded on a public site, shows a sign in wall to everyone outside it.
There is also a limit worth knowing about in advance. Google describes a File indexing issue error that appears when an embedded file has reached its share limit because it is embedded in too many sites, and the suggested fix is to make a copy of the file and embed the copy. Anyone reusing one enquiry form across a dozen department sites will meet this.
What the inserted form gives you
Validation, required fields, question types including choices and dates, conditional sections, and a response list with a summary view and a per person view. Responses can be sent to a Sheet with Link to Sheets, or downloaded as a CSV. Access can be closed on a date or after a set number of responses. For a contact page on a small site, this is genuinely sufficient.
What it does not give you
Any control over how the form looks. It is a Google Form in a frame, with Google's typography and spacing, and it will not match the page around it beyond the colour and font choices available inside Forms. On a phone the frame is a fixed height set in the site editor, so a form taller than the frame scrolls inside the page rather than with it.
It also puts a condition on attachments that catches out anyone collecting documents. Google states plainly that to answer a file upload question, responders need to sign in to a Google Account, and that the question type is unavailable when the form is stored in a shared drive or when an administrator has turned on Data Loss Prevention. Uploaded files land in a new folder in the form owner's Drive. For a public contact page this is a real obstacle: a visitor with a photograph of a broken part or a copy of an invoice hits a sign in wall before they can attach it, and a proportion of them leave instead. The details, along with the file type and size settings, are on the Google page about question types.
Route two: embed a form built somewhere else
If the form needs to look like the rest of the site, or needs file uploads that do not force respondents to sign in to a Google account, or needs the responses managed rather than just collected, the form comes from another tool and arrives through Insert, then Embed.
Most form tools give two snippets for this: a plain iframe and a script that resizes the frame to match its contents. Google Sites accepts both, since the embed code option allows JavaScript inside script tags. Use the resizing version. A fixed height iframe holding a form of unknown length produces a scrollbar inside a scrollbar, which is the most reliable way to lose a visitor on a phone. Tools that show one question per screen avoid the problem outright, because the frame never has to be tall.
There is one constraint that catches people. Google Sites renders embeds in a sandboxed frame, so a form that needs to read the parent page, set cookies on your domain, or redirect the top level window after submit may behave differently inside Sites than on an ordinary page. Test the submit itself on the published site rather than in the editor preview, and test it on a phone, because that is where frame height problems show up.
An alternative to embedding is not embedding. A button on the page pointing at the form's own hosted URL sends the visitor to a page built for the purpose, at full width, with no frame at all. It costs one click and solves every layout problem in this section. For a contact page, whether that click matters is a real question rather than an obvious one, and the honest answer is that it matters much less than a form that scrolls badly.
Route three: your own markup in an embed
Insert, Embed, Embed code accepts raw HTML, so a hand written form can go straight into a Google Sites page. This gives exact control of the markup and nothing else. An HTML form has no ability to send email or store anything, so the action has to point at a server or a form backend service, and until it does the submit button reloads a frame.
This route makes sense in one situation: the form has to post into a system you already run, and the markup is the simplest way to do that. Otherwise it is more work than route two for a result that is harder to change, since editing the form later means editing code in a text box in a site editor.
Notifications, and the two fields they do not carry
Whichever route is taken, the next question is who finds out when someone writes in. In Google Forms the setting is under Responses, then the More menu, then Get email notifications for new responses, described on the page about managing form responses. It is a per form switch, on or off, for the people it is enabled for.
That switch does two useful things and stops. It tells the watchers that something arrived, and it gives them a link. What it does not carry is the two pieces of information that make a shared contact page workable.
The first is an owner. When notifications go to three people, nothing in the notification says which of the three is answering. Everyone reads it, most assume someone else is on it, and the two familiar failures follow: the enquirer who receives two different replies within the hour, and the enquirer who receives none.
The second is a status. New, waiting on the enquirer, and finished are different states, and a response list that cannot tell them apart forces a weekly read through the whole list to find out what is still open. Teams paper over this by adding a column to the linked Sheet and filling it by hand. That works at twenty enquiries a month. At two hundred, the column is behind the reality and nobody trusts it.
Neither gap is a Google Forms defect. Forms is built to collect answers, and it collects them well. The work of replying and keeping track of who replied belongs to whatever comes next, and on most small sites what comes next is a shared inbox and a good memory.
A form tool that keeps an owner and a status against each response closes both gaps in the same place the answers already are, and the reply goes out from the same screen rather than from a separate mailbox. The difference shows up in the ordinary questions: who is handling the enquiry from Tuesday, what was promised to the person who wrote in March, and how many enquiries are still open right now. Seeing that on a real list is faster than reading about it, and the worked examples show which kinds of enquiry justify it and which are fine on a spreadsheet column.
What to change first
Get the form live on the page today by the shortest route, which is Insert, then Forms, and remember to press Publish on the form itself as well as on the site. Then check one thing before the enquiries arrive: whether more than one person is going to answer them. If so, the owner and the status need somewhere to live that is not a colour in a spreadsheet, and a response list that already has both is the cheapest way to get them, priced by how many people use it rather than by how many enquiries come in.
Q1. Does Google Sites have a built in contact form?
No. The Insert panel has text, images, buttons, embeds and Google files, but no form element. Every contact form on a Google Sites page is either an inserted Google Form, an embedded form from another tool, or hand written markup added through the embed code option, and all three appear inside a frame.
Q2. Why does the embedded form show a sign in screen to visitors?
Almost always permissions. An embedded Drive file keeps its own sharing settings, which are not inherited from the site, so a form restricted to one organisation will ask everyone else to sign in. Check the form's own publish state too, since an unpublished Google Form turns away anyone holding the link.
Q3. Can the form be made to match the site's design?
Only within the limits of whatever is inside the frame. A Google Form can change colour and typeface but stays recognisably a Google Form. A form embedded from another tool follows that tool's theming options. Exact control of markup and styling requires writing the HTML yourself and pointing it at a server or a form service.
Q4. Why does the form scroll inside the page on a phone?
Because the embed is a fixed height frame and the form is taller than it. Most form tools ship a script alongside the plain iframe that resizes the frame to fit its contents; Google Sites accepts JavaScript inside script tags in the embed code option, so use that version. A form showing one question per screen never needs a tall frame.
Q5. How do responses get to more than one person?
Google Forms can email notifications to the people it is enabled for, and the response list can be shared or linked to a Sheet that others can open. What none of those carry is which person is answering a given response, so a shared contact page needs an owner recorded somewhere, whether that is a hand filled column or a tool that holds the field itself.