Ever get that itch? You're scrolling through a site that’s absolutely crushing it on Google Discover—maybe it’s a flashy Verge article or a clean niche blog—and you just want to know what’s under the hood. You want to see the bones. Honestly, learning how to look at the code of a website is the closest thing we have to a digital superpower. It’s not just for the guys in hoodies writing C++. If you’re into SEO or design, it’s basically mandatory.
Most people think "View Source" is some ancient relic. It’s not. It is a live map of why Google likes a page. When you see a site ranking for a competitive keyword, they aren't just "writing good content." They are checking boxes in the HTML that the average user never sees.
Getting Past the F12 Wall
First off, let’s talk about the shortcut. On a Mac, it’s Cmd + Option + U for the raw source, or Cmd + Option + I for the Inspector. Windows folks, just hit F12 or Ctrl + Shift + I.
But wait. There is a massive difference between "View Page Source" and "Inspect Element."
If you view the source, you’re seeing the raw file the server sent to your browser. It’s static. It’s the "before" picture. If you use the Inspector (Developer Tools), you’re seeing the DOM—the Document Object Model. This is the "after" picture. It’s what the browser did with the code after running all the JavaScript. If you're trying to figure out how a modern React or Next.js site works, the raw source will look like a desert. You need the Inspector to see the actual content.
It’s kinda messy at first. You’ll see a wall of blue and purple text. Don’t panic. Most of it is junk you don't need right now. We are looking for the signals that tell Google "this page is important."
What Google Discover Sites Do Differently
If you want to appear in Google Discover, your code needs to be tight. Discover is picky. It’s not like standard search where you can sometimes rank with a slow, bloated site. Discover is mobile-first.
🔗 Read more: The Hunt for Zero Point: Why We’re Still Obsessed With Anti-Gravity and Vacuum Energy
When you are learning how to look at the code of a website that hits Discover, look for the Open Graph tags. Look for og:image. Is the image massive? Google specifically wants high-resolution images—at least 1200 pixels wide—for Discover. If you see a site constantly appearing in your feed, I bet you my morning coffee their code has a specific meta tag setting the max-image-preview to large.
<meta name="robots" content="max-image-preview:large">
I've seen so many publishers miss this. They wonder why their traffic is flat. Then you look at the code, and that one tiny line is missing. Without it, Google might just show a tiny thumbnail, or nothing at all.
Hunting for Schema Markup
This is where it gets nerdy but profitable. Schema.org markup is like a cheat sheet for Google’s crawlers.
While you’re poking around the <head> of the HTML, search for "ld+json."
This is usually where the "Article" or "Product" schema lives. It tells Google: "Hey, this isn't just a bunch of words; this is a Review written by John Doe on January 12, 2026." Real experts like Lily Ray often point out that E-E-A-T (Experience, Expertise, Authoritativeness, and Trustworthiness) isn't just a vibe—it's often codified here.
Does the code link to an author profile?
Does it use the sameAs attribute to link to the author’s LinkedIn or Twitter?
If you see that, you’re looking at a site that understands modern SEO. They are making it easy for Google to connect the dots.
The CSS Secrets and Layout Shifts
Ever visit a site and the text jumps around while it loads? That’s a "Cumulative Layout Shift" (CLS). Google hates it. Your users hate it.
When you use the Inspector, you can click on any element—say, a big hero image—and see the CSS in the right-hand pane. Look for aspect-ratio or explicit width and height attributes.
Sites that rank well almost always reserve space for their images. If you don't see height and width in the code, the browser has to guess. While it’s guessing, the text jumps. Boom. Your Core Web Vitals score just tanked. By looking at a competitor's code, you can see exactly how they styled their containers to stay stable.
JavaScript Bloat: The Silent Killer
Sometimes you’ll open a site's code and see fifty different <script> tags. This is usually where things go south.
High-ranking sites are getting better at "lazy loading." Search the code for the word async or defer. These little words tell the browser: "Hey, don't stop everything to load this tracking pixel. Get the text on the screen first, then worry about the marketing stuff."
If you’re trying to figure out how to look at the code of a website to improve your own, this is the first thing to check. If your scripts aren't async or deferred, you're making your visitors wait at the door.
📖 Related: Where Is Mark Zuckerberg Now: The Truth About the 2,300-Acre Bunker and Meta’s Massive Pivot
Why Mobile View Matters More
In the Developer Tools, there is a tiny icon that looks like a phone and a tablet. Click it.
Suddenly, you’re seeing the site exactly how a mobile user does. This is huge. Google uses mobile-first indexing. If your code hides important text on mobile to "save space," Google might not count that text for ranking.
I’ve seen "SEO experts" get baffled why they aren't ranking for a specific term, only to realize their mobile CSS had display: none; on the very paragraph they were trying to rank. It was in the code, but it was invisible to the user. Google noticed.
Analyzing the Heading Hierarchy
It sounds basic. It is basic. But people still mess up H1s and H2s.
Use the "Find" function (Cmd + F) in the source code. Type in <h1. There should be one. Just one.
If you see three H1 tags, the developer was probably using them for styling instead of structure. That’s a red flag. Check the H2s. Do they follow a logical flow? If the code jumps from an H2 to an H4, it’s a sign of a sloppy template. The sites that dominate Google Discover and Search usually have a very clean, "nested" outline in their code.
Actionable Steps for Your Next Audit
Don't just stare at the code. Use it.
Next time you see a competitor ranking for a keyword you want, do this:
📖 Related: Why the Apple Store in Roseville MN is Busy Every Single Tuesday
- Right-click and Inspect their main headline. Is it an H1? Does it contain the exact keyword or a variation?
- Open the Network tab in DevTools and refresh the page. Look at the "LCP" (Largest Contentful Paint) image. How big is it? Is it a WebP or a chunky old JPEG?
- Search the source for "canonical." Make sure they aren't accidentally pointing Google to a different version of the page.
- Look for "hidden" text. Use the Inspector to see if there are links or keywords stuffed in
divblocks that are moved off-screen. (Note: Don't do this yourself; Google’s spam filters are smarter than they used to be). - Check the "Console" tab. If it's a sea of red error messages, the site's code is broken in ways that might be hurting its crawl budget.
Basically, the code is the truth. Marketing copy can say whatever it wants, but the HTML tells you exactly how a site treats its visitors and how it talks to search engines.
If you want to move from "guessing" to "knowing," start hitting F12. You'll realize pretty quickly that the best sites aren't doing anything magical—they're just doing the basics with incredible discipline. Look for the alt text on images. Look for the way they handle internal links. It’s all there, hiding in plain sight.
Next Steps: Open your own website and a top competitor's website side-by-side. Use the "Compare" mindset. Look specifically at the <head> section of both. If they have metadata or schema types that you don't, that is your immediate to-do list for the afternoon.