SEO Code

SEO code is the HTML, CSS, JavaScript, and structured data that search engines read when they visit your page. If this code is broken, bots cannot parse the page correctly, and your content stays out of the index. The HTML provides the basics: a title tag, headings, paragraphs, and internal links. The CSS and JavaScript control layout and interactivity — but if those files are blocked by robots.txt or a noindex directive, Googlebot may see a blank page. Structured data, typically JSON-LD, acts as a cheat sheet to tell Google what the page is about. I think of SEO code as the instruction manual for bots. If the manual is missing pages or written in a language the bot cannot parse, the bot leaves without indexing anything. For instance, if your schema markup defines a product but the page body never mentions price or availability, Google may ignore the schema or flag it as spam. The rule: the code must match the visible content and the page must be technically accessible.

This matters most at four points: when launching a new site, after a redesign or CMS migration, when pages are not appearing in search, and during regular [technical SEO](/technical-seo/) audits. At launch, every important page must be crawlable and indexable from day one. After a redesign, templates change and canonical tags or robots directives can get lost or overwritten — I always run a full [SEO audit](/seo-audit/) to catch those issues. If pages stop showing up, the first thing I check is whether robots.txt blocks them or a noindex meta tag is present. Regular audits catch problems like blocked JavaScript or CSS, which prevent Google from rendering the page correctly. I once saw a site where the CSS was blocked; Google saw a plain text page with no layout. It still indexed, but rankings tanked because the page looked broken. Another edge case: if you use JavaScript to load critical content, make sure Googlebot can render it by not blocking your JS files in robots.txt. I test this with Google's URL inspection tool. A [sitemap](/sitemap/) helps discovery, but only if the URLs listed return 200 and are not blocked. The decision rule: every template change should trigger a technical check.

I once blocked a whole section of a site with [robots.txt](/robots-txt/) thinking it would save crawl budget. But I also put noindex on those pages. Google could not see the noindex directive because it could not crawl the page at all. The pages stayed indexed for weeks because old cached versions persisted. Another mistake: I added canonical tags pointing to a URL that itself redirected. Google ignored the canonical because the destination did not resolve to a 200. Now I always verify that canonical targets return 200, are indexable, and are not redirected. A third lesson: I assumed a page in a sitemap would be indexed quickly, but the page had a noindex tag in the HTML. Google saw the directive and dropped it from the index despite the sitemap. I also once had two pages with similar content and used [canonical tags](/canonical-tag/) on both pointing to the wrong one. The duplicate content was not resolved and both pages lost ranking. The takeaway: directives control indexing only if they are reachable, and canonical tags work only when both the source and destination are correctly configured.