What You Should Know About Site Layout, Frames and Tables

Frames Versus Tables: What Really Matters for SEO and Usability

When building a website in the early days of the web, frames appeared as a clever shortcut. They let you lock a navigation column or header in place while swapping content in the main area. That seemed convenient at first glance, but the reality quickly became a headache. Search engines struggle to crawl framed content because the main page only loads the frame container, and the actual page data lives in a separate document. As a result, crawlers often index the frame container and miss the vital content inside the frames, pushing your site down in search rankings. Users encounter another problem: the browser must issue a separate HTTP request for each frame, adding latency and potential for broken links if a frame source changes.

In contrast, using a single HTML document or a minimal set of tables keeps the content accessible to both crawlers and users. Tables - despite their original intent as data grids - provide a reliable way to arrange elements on the page without fragmenting the content. Because the whole page is delivered in one go, search engines see all links, headings, and text together, which improves indexing. The user experience is also smoother; a single page loads faster and feels cohesive, which is crucial for keeping visitors on your site long enough to convert.

Beyond technical implications, frames can break accessibility. Screen readers often treat frames as separate documents, confusing users who rely on assistive technologies. The same issue arises with mobile devices; many smartphones ignore framed content entirely, forcing users to navigate a broken layout. Tables, when coded properly, remain accessible and responsive. The structure is transparent, and you can leverage CSS to adapt the table to different screen sizes without altering the underlying markup.

In short, the pain of using frames outweighs the perceived gains. If you do choose to experiment with frames, you must create a no‑frame fallback version of each page, which doubles development time and maintenance. Most of the time, you can achieve the same layout with a single table or a combination of tables and Server Side Includes. These approaches preserve SEO, accessibility, and user experience while keeping your code base simpler.

Tables and Server Side Includes: A Practical Alternative

Tables are often labeled as “bad” in modern web design, but that stigma originates from the misuse of nested tables for layout. When used appropriately - primarily for organizing data or creating a grid of content - tables are both reliable and predictable. They allow you to place elements in specific cells and maintain the spatial relationship across browsers. Because tables are parsed as part of the same document, crawlers index every cell’s content, and screen readers can navigate the table structure logically.

Server Side Includes (SSI) amplify the power of tables by letting you insert reusable content into a table cell. Think of a navigation bar or a footer that appears on every page. With SSI, you store that snippet in a separate file and reference it with a simple directive like . The server replaces the directive with the file’s content before sending the final HTML to the browser. This means you maintain one source for shared elements, and any change is reflected site-wide without editing each page manually.

Using SSI within table cells keeps the page structure intact for crawlers. Search engines see the final output as a single page, so all links, headings, and images are captured. At the same time, you keep your code DRY (don’t repeat yourself), reducing the chance of errors and easing future updates. Many free tutorials explain how to set up SSI on popular web servers, such as Apache or Nginx. For instance, the National Center for Supercomputing Applications hosts a comprehensive guide at http://hoohoo.ncsa.uiuc.edu/docs/tutorials/includes.html, and the Open Research Alliance provides a step‑by‑step walkthrough at