Diamond Stone Platform: Public Website

Date: 2026-11-11. Revision 2 (evaluation, products in search, journeys and the back office: sections 13 to 21). Status: draft for owner review. One of three customer-facing parts: this one, docs/PORTAL.md (client portal) and docs/STORE.md (store). Brand rules: docs/BRAND.md. Screens: the "Public website" section of docs/ui-shell-mockup.html.

It draws on the earlier website plans (this repository's docs/planning/01, 02, 06, 20, 21; the earlier repository's docs/experience/65, 69, 71, 81, 82 and docs/website) and on research done on 11 November 2026. Sources are in section 12. Items marked unverified come from a search summary or general practice, not a page read directly.

1. What the website is for

1. Be found by people looking for Omani marble, in search engines and in AI answers.
2. Convince an architect, designer, contractor or importer that the stone is right and the company is safe to choose.
3. Capture an enquiry or a sample request, with everything the visitor already told us attached, and hand it to sales with a timer running.

It does not sell slabs online. A slab order is always a quote. Only samples are bought online (docs/STORE.md).

Rules from the brand (docs/BRAND.md): lead with the photograph, origin and proof; never with price. The public sees "Oman", never a quarry or supplier name. No hollow luxury words. No project photograph the company cannot claim.

2. What a stone supplier's site needs

Compared against the sites of Polycor, MSI, Arizona Tile, Salvatori, Antolini and Stone Group (home pages read on 11 November 2026).

What the evidence supports. Architects rank physical samples first, then technical sheets, then photographs when choosing a material, and most expect technical data on the supplier's site (ArchDaily and NBS surveys, unverified, from search summaries). No stone-specific data was found linking any feature to enquiries. So samples, datasheets and real photographs come first; anything else must earn its place.

3. Pages

● drawn in the sketch · ◐ specified · ○ to draw.

About 30 pages at launch, growing to 70 to 100 as stones, answers and projects are added.

On every page

A header with the short logo, language switch, search and menu; a slim bar at the bottom with the word "WhatsApp" at the left and the page's one action at the right (the app's Omnibar is not used on the public site: see docs/SITE-DESIGN.md); and a footer with registration and tax numbers, address, hours and the legal links. No Halo, because nobody is signed in.

4. One record, many outputs

The site is not written page by page. Each stone, project, answer and person is one record in the staff app. Publishing a record produces everything that depends on it:

A value changed once changes everywhere at the next publish. Nothing on the site is typed twice, and structured data can never disagree with what the page shows, because both come from the same record.

5. Publishing

Drawn in the sketch: "Page editor" and "Publish checks".

What stays human: every technical value and claim; Arabic (a native reviewer, never machine translation alone); picture rights and consent; anything legal; prices.

What must not be attempted: Google's Indexing API is only for job and live-stream pages and must not be used for these pages.

6. Being found: search engines (SEO)

Technical base

• Every page is complete HTML before any script runs. This is what the static build gives, and it is also what AI crawlers need (section 7).
• Speed, at the 75th percentile on a phone: main content visible within 2.5 s, response to a tap within 200 ms, layout shift under 0.1. The main photograph is under 200 KB, in AVIF or WebP with a fallback and stated dimensions.
• One address per page; a redirect whenever an address changes; filter and search result addresses kept out of the index.
• English and Arabic as separate addresses (/ and /ar/), each naming the other and a default. A language pair is declared only when both pages really exist.
• A site map with dates, and an image site map. Photographs are real <img> elements with descriptive file names and a plain description; never stuffed with keywords.
• Private areas (/app, the portal) are closed to crawlers.

Structured data, generated from the records:

Not used: FAQ markup (Google stopped showing FAQ results in May 2026) and How-to markup; review stars for the company's own reviews (not eligible). Questions and answers are still written on the page, because people and AI engines read them; they are just not marked up for a result Google no longer shows.

Content

• Search phrases follow the pattern stone + finish + use + place: "Omani marble exporter", "beige marble for floors", "honed marble Oman", "marble supplier Muscat"; in Arabic, researched in Arabic, not translated.
• First markets, from the earlier plan: India, UAE, Saudi Arabia, plus Oman.
• A page for a combination (stone × finish × use) exists only when it has its own photographs, data or project. Otherwise it is a section of the stone page. Google's policies against mass-produced and doorway pages apply to templated pages with nothing unique.
• One marketing person can keep up about three or four English pages and two or three Arabic pages a month. The plan is sized to that.

Local and off-site

• Google Business Profile kept current: category, hours, photographs, products, replies to reviews. Reviews are requested from every customer, never filtered or rewarded.
• The same name, address and phone number everywhere: directories, trade listings, social profiles.
• Presence where specifiers look: YouTube, LinkedIn, Instagram, Pinterest, and architecture product directories later. No paid or exchanged links.

7. Being cited: answer engines (AEO) and AI search (GEO)

AEO means being the source a search engine quotes when it answers directly. GEO means being the source an AI assistant (ChatGPT, Perplexity, Gemini, Copilot, Claude, Google's AI Overviews) uses and names. What is actually known, as of November 2026:

Answer pages are the main AEO and GEO tool, and they are fed by real questions:

1. A customer asks something in WhatsApp, chat or email. Staff tag it as a question worth answering publicly.
2. Marketing writes the answer: two lines first, then the data table, the source, the related stone.
3. Whoever holds the facts reviews it; it goes through the same publish checks.
4. It appears on the site, on the related stone page, and in the help centre. One record, three places.

This is drawn in the sketch as "An answer page".

Letting the right crawlers in. The site wants to be read and cited, so:

A Cloudflare trap, specific to this site. Cloudflare now has switches for AI bots by category. Setting the "Training" category to Block also blocks Googlebot and Bingbot, which would remove the site from search. And its managed robots.txt option, if switched on, adds blocks for several AI crawlers. Both are checked on the zone before launch and written into the launch checklist. The setting to use, if training is to be refused, is "Disallow AI training", not "Block".

Making the company a known entity: the same name, address and phone everywhere; Organization data linking to every official profile; a complete Business Profile; a Wikidata entry when the company qualifies for one.

8. Measuring

One screen in Reach, "How we are found", fed automatically.

No outside tool can see inside Google's AI systems; any "AI visibility score" sold by a third party is an estimate.

9. What is never done

• Pages written in bulk by AI, or near-identical pages for combinations.
• Text hidden for search engines or AI, or different content served to bots.
• Bought links, arranged mentions, fake or filtered reviews.
• Structured data that says something the page does not show.
• Machine-translated Arabic published without a native review.
• Words the brand forbids, or a price used as the lead.

10. Build stages

11. Decisions

1. Arabic at launch, or English first. The earlier decision log reopened this.
2. AI training crawlers: allow or refuse.
3. Visit statistics provider (the earlier plans left this open), and the cookie notice that follows from it.
4. Showing an indicative price range on stone pages. The earlier documents disagree; this plan and the brand research say no.
5. Who releases a page: the owner only, or a named publisher.
6. Whether customer names appear on project pages by default, or only with written consent each time (this plan: consent each time).

12. Sources

Read directly on 11 November 2026:

• Google Search documentation: AI features and the AI optimisation guide; structured data gallery, product, review and FAQ pages; spam policies; localised versions; images; Indexing API scope; API limits; the June 2026 note on generative AI reports (developers.google.com/search).
• Core Web Vitals thresholds: web.dev/articles/vitals.
• Aggarwal and others, "GEO: Generative Engine Optimization", 2024: arxiv.org/abs/2311.09735.
• Ahrefs, AI Overview citations and the top ten, 2026: ahrefs.com/blog/ai-overview-citations-top-10.
• Crawler documentation from OpenAI, Perplexity, Anthropic, Apple and Common Crawl.
• Cloudflare: blocking AI bots and managed robots.txt (developers.cloudflare.com/bots).
• IndexNow documentation: indexnow.org/documentation.
• Home pages of polycor.com, msisurfaces.com, arizonatile.com, salvatoriofficial.com, antolini.com, stonegroup.gr.

From search summaries only (unverified): the architect surveys; the studies on brand mentions, freshness and llms.txt; the report that AI crawlers do not run scripts; Bing's AI performance report; Arabic search guidance.

Revision 2: evaluation, products in search, journeys, the back office

Added 11 November 2026 after a full review of sections 1 to 12 and a second round of research. Drawn in docs/website-map.html; new screens in the mockup under "Website: learning, products and arrivals" and "Website: managing it from the staff app". Articles, facts and history have their own plan: docs/EDITORIAL.md. Where this revision differs from the sections above, it is the plan.

13. What the first plan got wrong or left out

14. Page by page: what each lacks

What each kind of buyer wants first:

New pages: Journal (the library); guides and articles; facts; history (two pages); words (glossary); for architects; for traders and importers; for home owners; how buying works; our numbers; markets (one per country, only with its own content); authors; your list.

15. Appearing as products in search

What is true as of November 2026 (Google's documentation, read directly):

Google's merchant rules name this exact case: where a product is sold only in bulk but samples can be bought, list the sample, at the sample's price, with a title beginning "Sample". So the plan is:

1. The sample is the listed product. Each stone and finish has a sample product with its price, photographs, delivery time and returns. Title: "Sample: Desert Rose marble, honed, 10 × 10 cm".
2. The sample's page is the stone's page. Someone arriving from a product result sees the stone, the sample offer with its price, and "slabs and tiles are quoted for your project". Drawn in the mockup.
3. Slab pages carry no price and no invented range. They are described to search engines as products without an offer, which is honest and brings no product result by itself.
4. A merchant account (Google's, and Microsoft's where it serves the region) receives a nightly list made from the same records, and the pages carry the same data, so the two can never disagree.
5. Details the rules require: delivery cost and time, and the returns policy, as pages and as data; our own stock code for each sample; "no manufacturer code exists" declared, since natural stone has none; finish and size mapped onto the kinds of variant search engines recognise.
6. Other Gulf countries. To be listed in the UAE and Saudi Shopping tabs, the sample must be priced in dirhams and Saudi riyals on its own address for each currency, with delivery to those countries. A decision (section 20): it changes the store, which today charges in rials only.

Also for product visibility: the company's Business Profile with its stones as products where the feature is offered in Oman (to check in the profile itself); a listing in Microsoft's places service, imported from Google's; and the image rules in section 18, since most stone discovery is visual.

16. Journeys: every way in, and where it leads

Ten ways people arrive. Each has its own landing, and the same three rules: say where they are, offer the one next step, and remember what they did.

The path from first visit to customer, the same for all:

1. Arrive on the page that matches the need, wherever they came from.
2. Judge: photographs, values, an answer. Add to the list.
3. Hold: order a sample, or send the list. The first point of contact, and the moment a named person and a reply time appear.
4. Wait well: a message with the sample's tracking; the sample arrives with a code that leads back to the stone.
5. Ask: a quote for the stone in hand. Everything already chosen is attached.
6. Become a customer: the reply carries a link into the portal, opened on that quote. The website's job is done.
7. Return: the site greets a known visitor with their list and, for a customer, a way into the portal.

Where people fall out, and the answer to each:

17. Beyond the site

Research on AI answers (2025 and 2026) finds they draw more on what third parties say about a company than on the company's own pages, and that mentions of a brand across the web go with visibility far more strongly than links do. This is correlation, and Google states that manufactured mentions do not help and that trying to manipulate AI answers is spam. So only real presence:

18. Technical points to add

19. Running it from the staff app

Under Reach → Website. Nothing on the site is typed twice, and everything is managed as records with states, not as pages.

The records

Screens (six drawn): the website manager, with everything by state; what to write next, from real questions and failed searches; the article editor, where no claim passes without a fact; the facts library; product listings and their problems; arrivals by touchpoint through to enquiry. Still to draw: the calendar; the links checker; redirects; the off-site checklist.

What is automatic

What stays with people: every fact and its source; Arabic; photographs and their rights; what is worth writing; anything said about a customer's project.

Capacity. One marketing person can keep up three or four English pieces and two or three Arabic ones a month. The library in docs/EDITORIAL.md is sized to that, and the manager shows what is overdue so the list does not silently grow.

20. Decisions added

7. Samples priced in dirhams and Saudi riyals as well as rials, to be listed as products in the UAE and Saudi Arabia. It changes docs/STORE.md and docs/CURRENCY.md.
8. Home owners: served (small quantities, a list of fitters) or pointed elsewhere. It decides whether "for my home" exists.
9. "Our numbers" on the site (on-time deliveries, slabs inspected), taken from the system. Proposed: yes, owner approves each figure.
10. Which directories to join. None was verified; to choose after looking at where enquiries actually come from.
11. "Available now" on stone pages. Depends on the open question of whether stock is held.

21. Sources added in revision 2

Read directly: Google's documentation on product results, merchant listings, product variants, organisation data, articles, images, AI features and its AI optimisation guide, spam policies, site maps, filtered navigation, localised versions; Merchant Center help on prices and samples, free listings, countries and currencies, product identifiers and unit pricing; Business Profile guidelines and review policy; the crawler documentation of OpenAI, Perplexity and Anthropic; IndexNow; Cloudflare's AI crawl control; the GEO paper (Aggarwal and others) and Chen and others 2025 on AI search and earned media; Ahrefs on brand mentions and AI Overviews; Polycor's resources page. From summaries only (unverified): architect surveys; Bing's AI report and places service; Microsoft's merchant service in the Gulf; changes to Cloudflare's defaults; all directories and marketplaces; the features of competitors' sites other than Polycor.

22. The home page and landing pages (added 11 November 2026)

Planned in docs/LANDING.md: the home page in eleven parts with the evidence for their order; fourteen blocks; six kinds of landing page meant to be found, four for campaigns and codes; what may be personalised; and how to find out what works at low traffic. One change to section 14 above: the home page does not lead with "three ways in by need". Research finds audience choosers a mistake as a lead; stones and uses lead, and the "For…" links come lower.

23. Stone names (added 11 November 2026)

A stone has one page. A market name has an address that leads to that same page, presented under the name the person used; there is no separate public page per name and no public "which stone?" page. The mapping to our stone is shown on staff screens only. The page under our own name may keep one quiet "Also sold as ..." line; a visitor arriving under a market name sees no such line. The plan is docs/CATALOGUE.md "Revision 2", which replaces its sections 4 and 5 on this point. Every stone is shown with what the rock is, its colour and its origin beside its name.

24. The site's own look (added 11 November 2026)

The public site no longer uses the staff app's parts. Its look is set out in docs/SITE-DESIGN.md and drawn, page by page, in docs/ui-shell-mockup.html: photographs to the edges, type and space instead of boxes, square and flat, one quiet action bar. That document also proposes a layout for wide screens, and says who on the team keeps each part of the site current.

25. After reading 37 other stone companies' sites (added 11 November 2026)

The evaluation is docs/COMPETITORS.md. Pages added because of it, all drawn: slabs available by lot; a lot; a stone's variation range and finish guidance; care and similar stones; a visit or video call; a project as evidence; sourcing and environment; origin; downloads (a catalogue and profile made from the records); a guide for the Gulf; the price question answered in Arabic. Also drawn from earlier plans: compare, an enlarged slab, projects, how we match, quality, our numbers. (A "which stone?" page was also drawn; it is withdrawn: docs/CATALOGUE.md "Revision 2".) Catalogue filters show a count beside each choice, and a filtered view has an address that can be shared. Deliberately not copied: a visualiser, courses, quarry pages, anything behind a login that a buyer needs.

26. Lead magnets (added 11 November 2026)

Fourteen, ranked by evidence, in docs/MARKETING.md section 5. The rule for the site: everything that is knowledge stays open; contact is asked for only when something made for the visitor is delivered.

27. WhatsApp, contact and chat (added 11 November 2026)

On every page, the word "WhatsApp" in the action bar opens it directly with a message that names the page. Chat (only while someone is on duty; whether it is on at launch is an open decision), a call and a visit are under Contact, always in view. No floating bubble; no supplier's script. Planned in docs/SITE-DESIGN.md section 21.

28. Tiles and slabs that match (added 11 November 2026)

The site's main promise is now matching, not inspection: one lot, a range approved first, the job laid out and approved before it ships, spare kept. No blocks are offered. The opening becomes the heading "Omani marble and limestone" and the line "Tiles, slabs and cut-to-size stone, supplied from Oman."; the home page gains a part for it; a stone's page leads its photographs with the range; "How we work" becomes "How we match". Planned in docs/MATCHING.md.

29. Settled by recommendation (12 November 2026)

From docs/SETTINGS.md section 10: the site launches in English and Arabic; the headline is "Omani marble and limestone" with each stone called what it is; the sample is a range set of three, priced per set, payable by card; reply and quote times are shown only once our own records meet them; website chat is off at launch; a link opens one thing and needs a code only to accept or pay.

30. Stones lead; a page for everyone (12 November 2026)

The owner looked at the site and said: "we are too much into match. Understand how clients will want to see and what they will want, and have enough content for everyone and everything."

He was right. After MATCHING.md the home page opened on a laid-out floor under "Tiles and slabs that match", repeated it in the second part, in the figures and in the buying steps. A visitor comes for stone. Consistent supply is why they should trust the company; it is not what they came to look at.

This section replaces the opening and the order of the home page in sections 3, 22 and 28, and the first row of MATCHING.md section 7. It draws on the competitor and luxury-site studies already in COMPETITORS.md and SITE-DESIGN.md, and on judgement; no new research was done for it.

What a visitor comes for, in order

The opening

Heading: "Omani marble and limestone". Line: "Tiles, slabs and cut-to-size stone, supplied from Oman." The photograph is stone in a room. The action is "Request a quote".

The home page, in order

1. The opening, and the four links.
2. Stones: six, with "All stones".
3. Uses: floors, walls, bathrooms, kitchens, stairs, outdoors.
4. Supplied as: tiles, slabs, cut to size, finished pieces, finishes.
5. Projects: two, with "All projects".
6. Why Diamond Stone: five points of equal weight: Omani stone; consistent supply; tested; delivered; documented.
7. For: architects, contractors, homeowners, traders.
8. How buying works: four steps.
9. Journal: three entries.
10. Contact: a named person.
11. Footer.

Where matching now sits

The promise itself (MATCHING.md) is unchanged. Only its volume on the public site is.

A page for everyone and everything

Drawn in full under "Website: the main pages, in full".

Still to draw at full length: a single use (Floors), a single project, a Journal article, and each of these in Arabic and at a desk.

Content each page needs before it can go live

Until these exist the drawings use sample names, figures and generated stone pictures.