Chapter 7: Page & Site Settings (3.A)
Exam topic 3.A: Manage indexing, visibility, metadata, and site-level controls.
Exam topic 3.A: Manage indexing, visibility, metadata, and site-level controls.
Key terms: Sitemap settings, indexing controls, Open Graph settings, custom code, SSL, staging subdomain.
Weight: 6% of the exam (about 3 questions)
Settings decide what search engines can see, what social platforms show, which code runs and how the site is served. This chapter maps out where each control lives (site level vs. page level) and what it actually outputs, so you can predict its effect on a live site.
7.1 Two levels of settings
| Level | Where | Scope |
|---|---|---|
| Site settings | Dashboard → site → Settings | The whole site: domains, publishing, SEO defaults, fonts, forms, integrations, custom code, backups |
| Page settings | Pages panel → gear icon next to a page | One static page or one Collection template (applied to every item) |
Rule of thumb: site settings set defaults and global behaviour; page settings set per-page metadata and exceptions.
7.2 Page settings in detail
General
- Name (Designer label) and Slug (URL). Changing a slug changes the URL, so add a 301 redirect.
- Parent folder: folders create nested URLs (
/services/web-design). - Password protection: protect a single page or folder (e.g. a client preview or an internal resource). Protected pages aren’t indexed.
- Site search: optionally exclude the page from Webflow’s on-site search results.
SEO settings
- Title tag (
<title>) and meta description. Unique per page. On CMS templates, bind them to fields. - Sitemap / indexing controls: exclude a page from the auto-generated sitemap and from search engine indexing (e.g. thank-you pages, internal utility pages, landing pages for paid ads only). After publishing, check the page source to confirm the result (
<meta name="robots" content="noindex">).
Open Graph settings
Open Graph (OG) tags control how a link looks when it’s shared on social platforms and in messaging apps:
<meta property="og:title" content="Webflow Grid Guide">
<meta property="og:description" content="Build two-dimensional layouts...">
<meta property="og:image" content="https://cdn.prod.website-files.com/.../og-grid.jpg">
- OG title and description can reuse the SEO title and description, or differ (social copy is often punchier).
- OG image: use a landscape image (commonly 1200×630). On CMS templates, bind it to an image field so every item has its own share image.
- After changing OG settings, platforms may still show cached previews. Use the platform’s debugger/inspector tool to refresh them.
Custom code (page level)
- Inside
<head>: page-specific meta tags, schema markup, preload hints. - Before
</body>: page-specific scripts. - On CMS templates, these fields can insert field values, which is useful for schema markup.
7.3 Site settings in detail
General
- Site name, Webflow subdomain (
yoursite.webflow.io), time zone (affects scheduled publishing and date output). - Site language sets the
langattribute on<html>, which matters for screen readers and SEO (Chapter 6). - Favicon and webclip (home-screen) icons.
SEO tab
| Control | Purpose |
|---|---|
| Disable Webflow subdomain indexing | Stops search engines indexing yoursite.webflow.io, preventing duplicate content with the production domain. Turn this on once the custom domain is live |
| robots.txt | Crawl rules for the whole domain, e.g. Disallow: /internal/. robots.txt blocks crawling, not indexing. A blocked URL can still appear in results if it’s linked. Use noindex to keep pages out of search |
| Auto-generate sitemap | Webflow builds /sitemap.xml with all indexable static and CMS pages. Optionally provide a custom sitemap instead |
| Global canonical tag URL | Tells search engines the preferred domain (e.g. https://www.example.com), consolidating duplicate URL variants |
| Google Search Console verification | Verify site ownership |
Publishing tab
- Domains: connect the custom domain, choose the default domain (www vs. root), with other variants redirecting to it (Chapter 11).
- SSL: HTTPS for the site. Webflow provisions and renews certificates automatically when DNS is set up correctly.
- Advanced publishing options: minify HTML, CSS and JS. Smaller files load faster, with no visual change (Chapter 12).
- 301 redirects: old path → new path, including patterns (Chapter 12).
Custom code tab (site level)
- Head code: runs on every page (analytics, verification meta tags, global preconnects, consent manager).
- Footer code: runs on every page before
</body>. Most scripts belong here so they don’t block rendering. - Custom code needs a paid site plan to publish. It doesn’t run in the Designer canvas, so test on the staging subdomain.
| Code placement | Use when |
|---|---|
| Site head/footer | Needed on every page |
| Page head/before body | Needed on one page or one template |
| Embed element | Needed at a specific spot in the layout (widget, iframe, inline SVG) |
Other tabs (overview)
- Fonts: Google Fonts, Adobe Fonts, and uploaded custom fonts. Upload only the weights you use.
- Forms: notification email addresses, reCAPTCHA keys (Chapter 9).
- Integrations: analytics IDs and similar (Chapter 8).
- Backups: restore points (Chapter 11).
- Apps & API access: API tokens and installed apps (Chapter 8).
7.4 Staging subdomain
Every site has a Webflow subdomain (yoursite.webflow.io):
- It’s the place to publish for review before going to production (Chapter 11). This matches the official sample question: publish to staging, request review, then publish to production.
- It must not compete with production in search. Disable subdomain indexing once production is live.
- It can be password-protected (whole site) on plans that support it.
- Staging and production can be published independently, so staging can run ahead of production.
7.5 Utility pages
Webflow provides special pages:
- 404 page: shown for missing URLs. Make it helpful (search, links to main sections) and keep it on-brand. Webflow serves it with the correct 404 status.
- Password page: the template used for password-protected pages.
- Search results page: for Webflow’s on-site search.
7.6 Visibility controls compared
| Goal | Tool | Effect |
|---|---|---|
| Hide a page from search results | Exclude from indexing (noindex) / exclude from sitemap |
Page still accessible by URL |
| Stop crawling a section | robots.txt Disallow |
Not crawled; may still be indexed if linked |
| Restrict access | Password protection | Requires password; not indexed |
| Hide from site search | Page setting for site search | Excluded from on-site results only |
| Hide the staging domain | Disable subdomain indexing | webflow.io copy not indexed |
| Remove an element | Display none / conditional visibility | Layout only, not a security feature |
Important for developers: display: none and conditional visibility don’t protect content. Anything in the HTML can be read in the page source. Use password protection (or keep it off the site) for anything sensitive.
Practice questions: Page & Site Settings
Q1 A production site at www.example.com is live, but Google also shows results from example.webflow.io. What should you do?
Show answer
Answer: b. The subdomain indexing setting tells search engines not to index the webflow.io copy, which removes the duplicate content. (a) you can’t delete it, and it’s useful for staging. (c) would block crawling of production. (d) blocks real visitors.
Q2 A “Thank you” page appears after form submissions and should not appear in search results. What’s the best setting?
Show answer
Answer: a. Exclude-from-indexing (noindex) plus sitemap exclusion keeps the page usable but out of search. (b) absurd. (c) hiding content doesn’t affect indexing of the URL. (d) obscurity isn’t an indexing control.
Q3 (Multi-select) A blog has 400 CMS posts. Every post should have unique social share previews. Which settings achieve this? (Choose two.)
Show answer
Answer: a and b. Binding template OG fields to CMS fields gives every item its own preview. (c) a single image for all 400 posts isn’t unique. (d) OG tags belong in the <head>, not in rich text.
Q4 What’s the key difference between robots.txt Disallow and noindex?
Show answer
Answer: b. robots.txt controls crawling, and noindex controls indexing. A page blocked from crawling can’t even show the crawler its noindex tag, so don’t combine them when your goal is to de-index a page.
Q5 A tracking script must load on every page without blocking rendering. Where should it go?
Show answer
Answer: a. Site-wide footer code runs on every page after content, without blocking rendering. (b) and (c) mean repeating it on every page. (d) rich text isn’t for scripts.
Q6 Custom code added in site settings doesn’t seem to run while you work in the Designer. Why?
Show answer
Answer: b. Custom code runs on the published site, not in the Designer canvas, so test on staging. (a) it needs a paid site plan, not specifically Enterprise. (c) and (d) aren’t the reason.
Q7 (Multi-select) Which are site-level (not page-level) settings? (Choose three.)
Show answer
Answer: a, b and c. Domains, SSL, the global canonical and robots.txt are site-wide. (d) template metadata bindings are page settings (of the template).
Q8 A client wants a confidential pricing page visible only to selected partners. What’s appropriate?
Show answer
Answer: b. Password protection actually restricts access. (a) content is still in the source. (c) still publicly accessible. (d) security through obscurity is not security.
Q9 After updating a page’s OG image, the old image still appears when the link is shared on social media. What’s the most likely reason?
Show answer
Answer: b. Social platforms cache previews. Use their re-scrape/debug tools after publishing. (a), (c) and (d) are false.
Q10 Why set the site language in site settings?
Show answer
Answer: b. The lang attribute is required for WCAG 3.1.1 and helps search engines. It doesn’t translate anything (a).
Q11 A site is reachable at both example.com and www.example.com with identical content. Which settings consolidate it? (Choose the best answer.)
Show answer
Answer: a. A default domain with redirects plus a global canonical consolidates everything onto one preferred host. (b) removes the homepage from search. (c) blocks crawling but doesn’t consolidate. (d) irrelevant.
Q12 Where should page-specific JSON-LD schema for every blog post be added?
Show answer
Answer: b. Template-level head code with CMS fields generates schema for every item from one configuration. (a) one hard-coded post on every page is wrong. (c) rich text doesn’t belong in the head and isn’t reliable for scripts. (d) robots.txt is for crawl rules.