SEO and public indexing plan¶

Document date: 2026-08-30
Status: planned; AndreaWeb remains intentionally noindex during private review
Canonical domain candidate: https://andreazambrano.co

Purpose and success criteria¶

This plan covers technical discoverability, bilingual page signals, portfolio and product content, image search, webmaster tools, and ongoing measurement. SEO helps search engines understand useful public content; it cannot guarantee rankings.

Success means that approved portfolio, project, product, category, contact, and future journal pages can be crawled, render meaningful HTML, declare one canonical URL, appear in the correct Spanish or English result, and attract relevant searches without exposing Admin, APIs, private data, duplicate routes, or thin placeholder content.

Current state and launch boundary¶

The live private-review configuration intentionally serves robots.txt with a site-wide disallow and adds X-Robots-Tag: noindex, nofollow, noarchive on public hosts. Search engines should not index the site in this mode.

Public launch is a coordinated configuration and content change, not simply deleting one header. Before removing the block:

Andrea approves every public biography, project, product image, price, contact method, policy, and placeholder.
Choose one canonical hostname. The current recommendation is the HTTPS apex; permanently redirect http and www variants to it.
Ensure every approved route returns a useful 200, every moved route a 301, every removed route a real 404/410, and no crawlable redirect chains.
Keep admin, api, cart/action endpoints, internal search/filter combinations, and non-public media out of the public index using the correct authentication, route, and indexing controls.
Generate and validate metadata, canonical links, language alternates, sitemaps, robots rules, and structured data before changing Nginx.
Remove noindex only from approved public portfolio/storefront hosts and routes. Keep an automated production check so it cannot return accidentally.

robots.txt controls crawling, not reliable removal from an index. A crawler must be able to fetch a public page to observe its noindex directive. Use authentication for genuinely private material; use page/header noindex for accessible pages that must not appear in search.

Canonical URL and bilingual design¶

Use stable, human-readable routes:

/portfolio                       Spanish portfolio index
/portfolio/<project-slug>        Spanish architecture project
/en/portfolio                    English portfolio index
/en/portfolio/<project-slug>     English translation
/cementos/co                     Colombia/COP storefront
/cementos/co/products/<handle>   Spanish product detail
/journal/...                     future Spanish articles
/en/journal/...                  future English translations

For every indexable page:

emit an absolute self-referential rel="canonical" using the chosen apex domain;
redirect alternate host/protocol/slash forms consistently;
do not canonicalize materially different Spanish and English pages to each other;
emit reciprocal hreflang="es-CO" and hreflang="en" links when both versions exist, plus an intentional x-default destination;
use the matching <html lang="es-CO"> or <html lang="en"> value for users and accessibility, while recognizing that search engines also infer language from the visible content;
list only canonical URLs in sitemaps.

If an English translation does not exist, do not invent a blank/thin translation or point hreflang at unrelated content. Add the alternate relationship when the real translation ships.

Crawlability and discovery¶

Generate a root sitemap index or a small set of application-owned sitemaps containing only public canonical 200 URLs. Use accurate lastmod values only when meaningful page content changes. Potential divisions are:

/sitemap.xml
/sitemaps/portfolio.xml
/sitemaps/store.xml
/sitemaps/journal.xml       # only after the journal exists

The apex robots.txt should allow approved public content, disallow only routes that should not be crawled, and include the absolute sitemap URL. A robots disallow is not a substitute for Admin authentication or API authorization.

All important pages must be reachable through ordinary HTML <a href> links with descriptive link text. Do not depend on client-only click handlers, internal search, or a submitted form for discovery. Render meaningful titles, headings, body text, prices/availability, and image descriptions in server/static HTML wherever possible.

Register and verify the domain in Google Search Console and Bing Webmaster Tools. Submit the sitemap, inspect representative live URLs, review coverage/indexing and rich-result reports, and use IndexNow for Bing only if update frequency later makes it worthwhile. Submission is a discovery hint, not a ranking guarantee.

Page metadata and content¶

Each public page needs:

a unique, concise title describing the page, Andrea, and location/topic where useful;
a unique Spanish or English meta description written for the visitor;
one clear primary heading and semantic section hierarchy;
visible original text that explains the architectural project, design process, material/product, dimensions, care, availability, or article subject;
descriptive internal links between related projects, products, categories, and articles;
Open Graph/social image metadata independent of search structured data;
an approved favicon, brand name, contact page, and accurate authorship/about page.

Do not create keyword-stuffed city pages, generated doorway pages, fake testimonials, fake reviews, or large numbers of near-duplicate tag pages. Original architecture case studies, process notes, concrete/cement craft guidance, and later astronomy work are more defensible search assets than generic filler.

Structured data¶

Use JSON-LD generated from the same authoritative data displayed to the visitor:

Page	Candidate schema	Boundary
Andrea biography/about	`ProfilePage` with `Person`	include only approved public facts and profiles
Site/brand	`Organization`	use real logo, URL, and contact details
Contact/location	suitable `LocalBusiness` subtype if accurate	do not invent a public address, hours, or walk-in location
Portfolio project	`CreativeWork` or a more specific truthful type	describe actual authorship and project facts
Product detail	`Product`; potentially `Offer` data	price and availability must match Medusa and visible content
Navigation hierarchy	`BreadcrumbList`	must match visible navigation
Future article	`Article`/`BlogPosting`	real author and publication/modified dates

The current storefront accepts inquiries but does not complete an online purchase. Do not claim merchant-listing purchase eligibility, shipping, return terms, ratings, or payment capabilities that do not exist. Product information can still be marked up truthfully and evaluated under the applicable Product snippet rules. Reassess merchant listing markup and Merchant Center only after the purchase/fulfillment model meets the then-current requirements.

Validate representative pages with Google's Rich Results Test and schema validation, then monitor Search Console reports. Valid markup makes a page eligible for supported features; it does not guarantee a rich result.

Images and portfolio assets¶

Architecture, product, and astrophotography images are central discovery assets:

publish sharp originals in responsive modern formats and appropriate dimensions;
avoid upscaling weak workshop images merely to meet a nominal resolution;
place each important image near relevant visible text;
write concise contextual alt text; use empty alt text for purely decorative images;
use stable descriptive filenames and public canonical media URLs;
provide width/height or aspect ratio to prevent layout shifts;
generate image sitemap entries where normal page discovery is insufficient;
preserve ownership, consent, license, credit, and AI-assistance records;
remove EXIF/GPS or other private metadata when it should not be public.

Do not expose Garage bucket listings. Search discovery should originate from public pages and sitemaps, not object-storage enumeration.

Performance and mobile quality¶

Search-oriented performance work overlaps user experience:

test mobile first, including navigation, language switching, cart, and large images;
track Core Web Vitals and PageSpeed results for representative templates;
cache immutable media, compress text, limit JavaScript, and prevent layout shift;
keep server-side rendering/static output useful when optional browser JavaScript fails;
monitor crawler-facing 5xx, timeouts, redirect loops, and Nginx/Next rendering load;
never let analytics, a CMP, or future ads block core content or navigation.

Performance targets should be measured from Colombia and likely audience regions, not only from the VPS or a fast local network.

Local presence, reputation, and discovery¶

If Andrea has a real customer-facing business location or service-area eligibility, evaluate a Google Business Profile and keep its name/contact details consistent with the site. Do not publish a home address or claim a storefront that customers cannot visit. Professional profiles, Universidad de los Andes credentials, exhibitions, publications, project collaborators, and reputable architectural directories may provide useful corroborating links when accurate and approved.

Earn links through work worth citing: original project case studies, material/process guides, public talks, collaborations, exhibitions, and later architecture/astronomy articles. Do not buy links, automate spam outreach, or treat raw backlink counts as a goal.

Measurement and recurring operations¶

Search Console and Bing Webmaster Tools are the SEO sources of truth for crawl/index diagnostics. Consent-gated audience analytics is a separate decision described in Publishing, audience analytics, consent, and advertising.

Review monthly at first:

indexed versus submitted canonical URLs and excluded-reason changes;
crawl errors, 5xx, DNS/TLS failures, and accidental noindex;
queries, landing pages, countries, devices, and click-through patterns;
Core Web Vitals and slow/heavy templates;
sitemap freshness and orphan pages;
structured-data errors/warnings;
broken links, redirects, missing images, and stale product availability;
content that answers genuine searches versus thin pages that should improve or go.

Record deployments that change routes, canonicals, metadata, rendering, structured data, or indexing policy. CI should test these signals before production.

Implementation sequence¶

Choose apex canonical behavior and define the public/private route matrix.
Add per-page metadata, canonical URLs, bilingual hreflang, semantic HTML, and crawlable navigation to portfolio and storefront templates.
Generate application sitemaps and a root sitemap/robots response.
Add truthful Profile/Organization, breadcrumb, project/article, and Product markup.
Add automated checks for response status, redirects, robots headers, canonical and hreflang reciprocity, sitemap membership, metadata uniqueness, and JSON-LD parsing.
Complete content, accessibility, mobile, image, policy, and performance review.
Change Nginx from private-review blocking to the approved public indexing policy.
Verify live responses and rendered HTML before submitting sitemaps.
Register Search Console and Bing Webmaster Tools, submit, inspect, and monitor.
Improve content and internal navigation from real query/user evidence; do not manufacture pages merely to target keywords.