How We Rebuilt Digital VisionWorks for Search and AI Discovery

Digital VisionWorks began as a React and Vite single-page application. It looked like a multi-page portfolio to a visitor, but its hash-based navigation meant crawlers often saw several logical views as variations of one document. Each case study needed its own stable URL, title, description, canonical, and share preview before it could stand on its own in search.

Motion created a second problem. Important sections entered the page with client-side visibility effects, which made the visual experience feel deliberate but made the initial HTML a weaker source of truth. We wanted to keep the motion identity while ensuring that the headline, supporting copy, links, and project details were present before browser JavaScript ran.

We migrated the site to the Next.js App Router because its route model matched the search problem directly. The homepage, Services, About, Work, Contact, and every case study became a real route with server-rendered content. Route metadata now produces a unique title, description, canonical URL, Open Graph record, and Twitter card for each important page.

The migration also gave us file-based robots and sitemap outputs, static generation for portfolio pages, and an image pipeline that could reserve layout space before media loaded. We preserved React, TypeScript, Tailwind, and the existing motion system, but moved search-critical text out of browser-only state and into the initial response.

Metadata is easy to add once and easy to break later. We centralized the canonical host, page metadata builder, case-study summaries, breadcrumb builder, and structured-data builders so the same facts drive visible pages and machine-readable output. That reduces the chance that a title, canonical, image, product name, or modification date drifts in one place while staying stale somewhere else.

The site now publishes Organization, Person, WebSite, WebPage, BreadcrumbList, Service, FAQPage, Article, and application data where each type matches visible content. Case-study Article entities use the Digital VisionWorks URL, while product entities point to the real product destination. JSON-LD is rendered on the server and serialized with HTML-significant characters escaped.

We did not treat a successful build or deployment as proof that Google could use the site. Search Console showed which URLs were indexed, which submitted pages were still waiting, which canonical Google selected, and whether crawled resources loaded. That evidence moved robots rules and canonical redirects ahead of cosmetic metadata tweaks.

One inspection exposed a rule that blocked Next.js assets from Googlebot even though the page HTML was available. We removed that block, kept private API and admin paths restricted, changed the apex host redirect to a permanent one-hop redirect, and resubmitted the canonical sitemap. Each repair was then checked against the live custom domain rather than a preview URL.

AI search did not require a second website or a layer of special markup. The useful work was the same work that helps people and conventional search: crawlable text, stable URLs, clear headings, accurate entity relationships, descriptive internal links, and original project details that a system can quote without guessing.

We also separated crawler policy from training policy. OAI-SearchBot is explicitly allowed to access public pages for ChatGPT search discovery. GPTBot is a separate control for potential model training, so we do not describe one choice as if it automatically makes the other. For Google AI features, the same indexed pages and normal Search controls remain the foundation.

The repository includes a focused SEO regression suite. It checks canonical metadata, case-study Article data, product identity, crawl rules, sitemap dates, published blog routes, descriptive headings, and the permanent host redirect. These tests run beside type checking, linting, formatting, the portfolio regression suite, and the production build.

The important part is not the number of checks. It is that each check protects a decision that has already failed or drifted in the real site. When the portfolio grows, a new case study must supply the same search contract as the existing work instead of relying on someone to remember a launch checklist.

Technical fixes make content eligible for discovery, but they do not make a page worth citing. The next durable advantage is deeper first-party evidence: the real problem behind a product, the constraints that shaped it, the implementation decisions, what shipped, and what we learned. That is why our case studies favor specific workflows over generic claims about innovation.

We will publish when we have a useful story to tell, not to fill a calendar. One detailed account of a real migration is more valuable than a batch of interchangeable search articles. That standard is slower, but it gives visitors, search engines, and AI systems the same thing: a clear source they can trust and understand.