Shinnynos

Most "technical SEO" you can buy in India is keyword research with a different invoice. We are not that.

What Shinnynos is, in one sentence

We build search-engine-first web architectures β€” the kind where every page is a typed entity, every relationship is a verifiable @id graph, every identity claim is provable to a crawler, and every lifecycle transition is auditable. Then we wire your business into that architecture and let the engines crawl what is structurally true.

The five phases we run on every engagement

Every Shinnynos site, including this one, goes through the same five phases. Nothing ships to a domain until all five are complete. There are no exceptions β€” and no shortcuts dressed up as "MVPs."

Phase A β€” Prove the schema graph on one real page

Before we publish anything, we build exactly one page β€” usually the home page β€” with the complete Tier-2 schema.org graph it will live with for years. Organization @id, LocalBusiness subtype, Person for the founder, WebSite with SearchAction, WebPage with mainEntity, all bound to canonical @id values that will never change. We validate it in Schema Markup Validator, Rich Results Test, and our own runtime validator. Only when that one page is structurally bulletproof do we proceed.

Phase B β€” Multiply across every page type

Once the schema graph proves out on one page, we cookie-cutter it across every page type the site will ever have: services, locations, serviceΓ—location matrix cells, blog posts, case studies, author profiles, static pages. Same @id discipline, same validation gates. By the end of Phase B we have one page per type β€” not one per row β€” passing every validator.

Phase C β€” Lock identity

This is where most agencies stop, and it is the difference between a website and an entity. We anchor the business to a Wikidata Q-ID, harden the sameAs graph across every authoritative directory and social profile the entity owns, and flip a single boolean β€” Locked = true β€” that means: no more identity drift. From this point forward, the canonical NAP, the founder identity, the knowsAbout graph, and the legal entity name are immutable except through a documented identity-change ritual.

Phase D β€” Real content volume

Only after identity is locked do we let content scale. Services, locations, the cross-product matrix, blog posts, case studies. Every row inherits identity from the locked anchor. Every page emits validated Tier-2 schema by construction. Every relationship is a real graph edge, not a <link rel> written by an intern.

Phase E β€” Launch surface

The boring layer most agencies forget: robots.txt, sitemap.xml, rss.xml, llms.txt (yes, the LLM-discovery contract β€” we ship this on every site), 404 page, OG image defaults, AI-bot stances configured per client, JSON-LD on every route. Only after Phase E does the domain bind.

Identity-first architecture

The first artifact we build for any client is the Site Config β€” one Notion row that owns every canonical identity field the brand will ever have. Brand name. Legal name. NAP. Q-ID. Founder. knowsAbout concept graph. AI-bot stances. OG image. Theme color. The Site Config is the source of truth; every page on the site reads identity values from it at build time, never hardcodes them.

This sounds boring. It is the single highest-leverage decision in local SEO. Identity drift β€” the gap between what the website says about the business and what Google's Knowledge Graph believes about the business β€” is the silent killer of every local SEO program we have ever audited. We engineer the gap to zero.

Schema graph as code, not as a plugin

We do not install a JSON-LD plugin. We do not let your CMS theme guess. We write a typed graph in TypeScript β€” one Tier-2 node per page type (Article, CaseStudy, Service, Offer, Person, LocalBusiness) β€” with explicit @id conventions, validated at build time, and emitted as a single connected graph object per page. The graph is a build artifact. It is reviewable. It is diffable. It is testable. It is in version control.

Every Concept the brand has expertise in is a first-class entity with a Wikidata Q-ID, a sameAs graph of its own, and a slug-stable @id. When the brand knowsAbout Core Web Vitals or areaServed Bhilai, that is not a string in a JSON file β€” it is a typed reference to a Concept entity whose identity is locked.

Lifecycle discipline

Every content row in the system flows through a seven-state lifecycle: Draft β†’ In Review β†’ Stub β†’ Published β†’ Retired β†’ Cascaded β†’ Removed. Retired pages emit HTTP 410 and a tombstone, not a soft 404. Removed pages have their @id values permanently burned and added to an id-registry so they can never be silently revived. Cascaded retirements are detected by the loader: when a Service is retired, every ServiceΓ—Location cell that depended on it auto-flips to Cascaded. None of this is manual. It is built into the schema contract.

For local SEO specifically, we maintain a Citations database that tracks every external citation of the brand β€” GBP, directories, social profiles, press. A scheduled worker fetches each citation URL and byte-matches the observed NAP against the canonical NAP. The moment any directory drifts a character, we know β€” and we know which page, which authority weight, which remediation owner.

Build vs runtime boundary

Sites we build are static. The whole site renders at build time into a directory of HTML files and assets. Notion is our authoring CMS β€” your team writes in Notion, our build pipeline reads Notion, validates the row against a typed schema, mirrors any uploaded files to R2, and emits the page. Cloudflare Pages serves the result globally with zero origin requests. There is no runtime CMS. There is no PHP. There is no database to keep secure. There is no admin dashboard to patch every Tuesday.

The advantages compound. Page load is sub-second from any geography. The attack surface is approximately zero. Hosting costs are approximately zero. Search engines crawl HTML that does not change between crawl and user-visit. Generative engines crawl the same HTML and find a typed entity graph instead of a JavaScript blob.

Observability

Every build emits an Identity Audit report. The report compares the canonical Site Config against the live site, every NAP citation against its expected byte-string, every Concept against its Wikidata anchor, every Tier-2 schema graph against its validator output. If anything is wrong, the build fails. If everything is right, the report is dated and the row is marked green.

Drift workers run on a schedule independently of the build. They catch the slow drift β€” a directory editor changing your street address, a Wikidata vandal rewriting your founding year, an LLM hallucinating a service area you no longer cover.

When this isn't for you

If you want a β‚Ή300/month SEO package that promises 100 keyword rankings on month one, we are the wrong firm. We do not do content farming. We do not do PBNs. We do not do guarantees on ranking positions because nobody who actually understands the algorithm offers them. We work with businesses that intend to exist in five years and want their digital identity to be structurally honest about who they are.

If that is you β€” we should talk.