My portfolio site has a desktop-metaphor UI with draggable windows, a taskbar, and interactive elements everywhere. It's the kind of design that makes Google's crawler deeply uncomfortable. All the actual content (project descriptions, blog posts, skills) lives inside JavaScript-rendered window components that a crawler might never meaningfully parse. I didn't want to compromise on the creative direction, but I also didn't want my site to be invisible to search engines and AI search tools. Here's how I solved it. ## The Problem: Content Trapped in JavaScript Windows The core issue is simple: my site's content isn't in semantic HTML that lives in the initial DOM. It's rendered inside React components that simulate desktop windows. A user opens a window, reads about a project, closes it, opens another. The content exists in component state and conditional renders. Google's crawler executes JavaScript, but it's not clicking around opening windows. It sees the initial render, a desktop background with a taskbar, and not much else. From a crawling perspective, my beautiful portfolio was a nearly empty page. ## The CrawlableSeoContent Pattern My solution was to create a parallel content layer: a `CrawlableSeoContent` component that renders the full semantic HTML version of all content, visually hidden from sighted users but fully accessible to crawlers and screen readers. ```tsx function CrawlableSeoContent() { return (

Wes Dieleman - Full Stack Developer

About

Full stack developer based in the Netherlands, specializing in Next.js, React, TypeScript, and Cloudflare Workers...

Projects

Triqai

Transaction enrichment API built on Cloudflare Workers...

{/* ... more projects */}

); } ``` The `sr-only` class (from Tailwind) uses the standard screen-reader-only CSS pattern: `position: absolute; width: 1px; height: 1px; overflow: hidden; clip: rect(0, 0, 0, 0)`. The content is in the DOM, crawlers read it, screen readers announce it, but sighted users see only the interactive desktop UI. The critical thing is keeping this content synchronized with what's actually displayed in the windows. I extract the content into a shared data layer that both the visual window components and the SEO component consume. When I update a project description, it updates in both places. ## Schema Markup Strategy I went deep on structured data to give search engines as much context as possible about who I am and what the site contains. The schema graph includes: **Person schema** for identity: name, job title, location, skills, social profiles. This grounds the site as a personal portfolio rather than a random JavaScript demo. **WebSite schema** with search action potential, establishing the site's identity and URL structure. **CreativeWork for each project** with technology stack, descriptions, and links. This tells Google "these are real software projects" rather than just page sections. **BlogPosting for each blog post** with proper author reference back to the Person entity, datePublished, and article sections. **BreadcrumbList** to establish navigation hierarchy even though the visual UI doesn't have traditional breadcrumbs. ```json { "@context": "https://schema.org", "@graph": [ { "@type": "Person", "@id": "https://wesdieleman.com/#person", "name": "Wes Dieleman", "jobTitle": "Full Stack Developer", "knowsAbout": ["Next.js", "React", "TypeScript", "Cloudflare Workers"], "address": { "@type": "PostalAddress", "addressCountry": "NL" } }, { "@type": "WebSite", "@id": "https://wesdieleman.com/#website", "url": "https://wesdieleman.com", "name": "Wes Dieleman", "author": { "@id": "https://wesdieleman.com/#person" } } ] } ``` I inject this as a single `@graph` array in a `

Wes Dieleman blog