Rendering Checks for SEO: Screenshots and Code Blocks

The Search Console screenshot in our AI visibility article loaded, but its left and right edges were cropped. That removed parts of the page URLs and impression counts—the information the screenshot was meant to show. The image file was intact; the display frame was the problem.

The fix was to preserve that screenshot’s proportions rather than make it fill the same frame as a decorative cover. These are the relevant rules in SeoGeo Tech’s stylesheet, reviewed on October 13, 2026, followed by a separate choice for long code lines.

The screenshot needed its edges, not a uniform frame

The AI visibility article uses a Search Console Pages screenshot as evidence. The original image is 2118 by 1192 pixels. Its URLs are on the left and impression counts on the right; cropping either side removes information the reader needs to compare the rows.

Our stylesheet has a general image rule with a fixed display ratio:

.content-image img {
  width: 100%;
  aspect-ratio: 16 / 10;
  object-fit: cover;
}

This is an excerpt of the actual rule; border and shadow declarations are omitted. A 16:10 frame is a different shape from that screenshot. With cover, filling the box can mean clipping the image. That can be acceptable for a decorative cover, but it was the wrong choice for a data table.

The live screenshot now sits in <figure class="content-image original-ratio">. Its image element includes width="2118" and height="1192". The corresponding override is:

.content-image.original-ratio img {
  height: auto;
  aspect-ratio: auto;
  object-fit: contain;
}

Here the automatic height and aspect ratio allow the image to keep its own proportions. The explicit dimensions give the browser an aspect-ratio hint that can help reserve space before loading; CSS still affects the final layout. I keep the figure caption in text so the reader does not have to decipher every label in a scaled-down screenshot.

There is a detail worth noticing in our code: a mobile rule already removes the fixed ratio from content images. That means a phone preview alone could miss a desktop crop. For evidence images, I check both widths and compare all four edges with the original file, rather than assuming the narrower screen is always the harder case.

A readable code block is not the same as a short line

The commands in the Technical SEO checklist can be wider than a phone. For these examples, I chose to preserve line structure and let the reader scroll inside the block. Our current styles put that scrolling on the container:

.article-body pre {
  max-width: 100%;
  overflow-x: auto;
}

.article-body pre code {
  display: block;
  min-width: min-content;
  white-space: pre;
}

These are selected declarations from the stylesheet, not a complete component. I removed a mobile override that used white-space: pre-wrap and overflow-wrap: anywhere. Wrapping is not inherently wrong, but for these Shell examples I wanted the visible line structure to match the command being copied.

To check your own implementation, scroll to the end of the longest line at phone width: the surrounding article should stay within the viewport. Copy the command into a text editor and compare line breaks, indentation, quotes, and backslashes. A visually tidy block can still contain altered text. If WordPress has inserted an embed into the code, that is a separate content-processing problem; the publishing walkthrough covers our fix.

These are display and usability corrections, not measured Core Web Vitals improvements; no before-and-after speed results are claimed here. For the underlying behavior, see MDN’s object-fit reference and web.dev’s explanation of image dimensions and layout shifts.