Contact, about, and the trust surfaces nobody audits

Every audit checks the pages that rank. Almost none check the pages that say who is behind them: the about page, the contact page, the editorial policy, the author pages, the legal and policy pages. These are the pages a careful reader opens to decide whether to believe the rest of the site. They are also the pages where a company’s name, address, and phone number quietly drift apart over years of redesigns.

Call them trust surfaces. They rarely earn traffic, and they rarely appear in an answer themselves. What they do is back up the claims made everywhere else on the site: who wrote this, who stands behind it, and how to reach them. This post covers what each surface should contain, why consistency across them matters, and how to audit them by hand and across a site. It sits under Citability and entity signals: a GEO guide.

What counts as a trust surface?

A trust surface is any page or template element whose job is to identify who is responsible for the site and how to reach them. The core set:

Google’s guidance for evaluating content points straight at these pages. Among its self-assessment questions: does the content present information “in a way that makes you want to trust it, such as clear sourcing, evidence of the expertise involved, background about the author or the site that publishes it, such as through links to an author page or a site’s About page?” (Google Search Central). The same page says that of the E-E-A-T qualities, “trust is most important.”

That is guidance about Google’s ranking systems, not a statement about any assistant. The reason it still applies here is simpler. A page that is quoted without its context loses everything except its words and its source. Whether the source holds up is decided on these pages.

What should an about page contain?

An about page should state facts a reader could check, not adjectives. The test is whether a stranger could answer “who is this?” in one sentence after reading it. That sentence would cover the legal or trading name, what the organization does, where it is, when it started, and who leads it.

Write it the way you would write an answer block. The first paragraph states the organization in plain terms: “Acme Robotics is a manufacturer of industrial robot arms, founded in 2014 and based in Columbus, Ohio” (a fictional example). The rest supports that sentence with names, dates, and numbers that have sources. Link out to things that corroborate it: registrations, professional bodies, press coverage, profiles. Linking out as a trust signal covers why outbound links help here rather than hurt.

Google’s Organization structured data documentation recommends placing that markup “on your home page, or a single page that describes your organization, for example the about us page” (Google Search Central). So the about page is where the visible facts and the marked-up facts should sit together.

What should a contact page contain?

A contact page should list every real way to reach the organization, plus the business details that identify it. Google’s 2021 guidance on customer support gives the checklist directly (Google Search Central):

• Provide a contact or support page “that can be easily located by both visitors and Googlebot,” for example linked from the footer.
• “List all support methods”: email, chat, social media, telephone, or others.
• “Make it clear who is authorized to provide support,” including whether third parties are.

A form alone fails the first test a reader applies, which is whether a human will ever answer. Add at least one direct channel and state the response time you actually keep. Put the legal name and address on the page as text, not only in a map embed, which carries no text at all.

Why do organization details have to match everywhere?

They have to match because every copy of a fact is a claim, and claims that disagree undermine each other. If the footer gives one phone number, the contact page another, and the Organization markup a third, then at least two of them are wrong, and a reader or a system has no way to know which.

Drift happens in predictable ways:

• Rebrands. The visible name changes; the legalName in markup and the copyright line do not.
• Moves. The contact page gets the new address; the footer partial, a PDF, and the markup keep the old one.
• Template forks. The blog runs on a different template from the main site, with its own footer that nobody updated.
• Per-page markup. A plugin emits Organization markup on every page with values typed in years ago.

Policy pages drift against commercial pages the same way. A refund window in the terms that differs from the one in the pricing FAQ is the same fault with money attached. Pricing pages on answer surfaces covers that FAQ.

The structured data rule is the anchor. Google’s policy says “don’t mark up content that is not visible to readers of the page” (Google Search Central). So the markup should never be the only place a fact lives, and it should never disagree with the page. Google’s Organization documentation has no required properties. It recommends “an indication of real-world presence (for example, address or telephone) and online presence (for example, url or logo),” with contactPoint for support channels. Organization schema and sameAs covers the markup itself. This post’s concern is that the markup and the visible pages say the same thing.

What do author and editorial pages add?

Author pages give a byline somewhere to point. Google’s helpful-content guidance asks: “Do bylines lead to further information about the author or authors involved, giving background about them and the areas they write about?” A byline with no page behind it answers half the question. Author bylines and Person schema covers the byline and the markup. The trust-surface audit only checks that each byline resolves to a real page.

An editorial policy says how content is made: who reviews it, how sources are chosen, how corrections are handled, and what “updated” means on this site. It is the page that makes the visible dates believable. If you show “Updated” dates, the policy is where you say what triggers one. Freshness signals and honest dateModified gives the rules worth writing down. Keep the policy short and specific enough to be checked against your own pages.

How do you audit trust surfaces by hand?

Work through the surfaces once, with a spreadsheet open:

1. Find them from the home page. Can you reach about, contact, and the policy pages in one click from the header or footer? Note any you had to search for.
2. Write down the facts. For each surface, record the organization name, legal name, address, phone, email, and founding date exactly as written. One row per source: about, contact, footer, each policy page, the markup.
3. Read the markup. Open the home page and about page in a structured-data validator, and add the Organization values to the sheet as their own rows.
4. Compare columns. Any cell that differs from the others in its column is a finding. Decide which value is true, then fix every other copy.
5. Check the people. Click three bylines. Each should land on an author page with a name, a role, and background.
6. Check the dates. Note the last-updated date on each policy page. A privacy policy that refers to a product you retired has a stale date, whatever it says.

This takes under an hour for most sites, and the output is a short list of exact edits.

How do you audit them across a site?

Without a terminal, use a crawler’s custom extraction to check that every template carries the same facts. Add rules for:

• Footer phone: a regex against the rendered text such as \+?[0-9][0-9 ().-]{7,}[0-9], scoped to //footer if your crawler supports it.
• Footer address line: the XPath to your address element, for example //footer//address.
• Contact link present: count(//a[contains(@href,'/contact')]).
• About link present: count(//a[contains(@href,'/about')]).
• Markup values: regexes against the source for "telephone"\s*:\s*"([^"]+)" and "legalName"\s*:\s*"([^"]+)".

Export, then in the sheet run =COUNTIF(C:C, C2) on each extracted column. The value with the most matches is your current fact. Every row with a different value is a template that drifted. Sort by URL path to see which section it belongs to. A zero in the contact-link column is a template with no route to contact.

In a terminal, the same check for one URL:

curl -s "$URL" | grep -oE '"(telephone|email|legalName|streetAddress)"\s*:\s*"[^"]+"'

Run it over a sample of URLs from each template and compare the output.

GEOBee’s GEO lens scores two of these surfaces per URL. Trust (10 of 100) checks HTTPS, valid schema, and a visible way to make contact. Entity clarity (15) checks for Organization or Person schema with sameAs links. The three lenses lists both. It reports presence, not agreement: it can see that a page links to contact and carries Organization markup, but not that the phone number in that markup is out of date. The comparison in the sheet stays a person’s job.

To find the templates on your site that carry no contact route or no Organization markup, download GEOBee and crawl the site. The trial exports every finding with its fix.