FAQ on static SEO for US niche websites (no JavaScript)

Clean URLs are achieved through server-side configuration rather than client-side JavaScript. When you request a URL like /faq, the web server maps this request to the appropriate file, either faq.html in the root directory or /faq/index.html in a subdirectory structure. This mapping happens entirely on the server before any content reaches the browser.

For static hosting platforms like Netlify, Vercel, GitHub Pages, or traditional Apache and Nginx servers, you configure URL rewrites in platform-specific configuration files. On Apache, you use .htaccess rules with RewriteEngine directives. On Nginx, you configure try_files directives in the server block. Cloud platforms typically provide a _redirects file or vercel.json configuration for the same purpose.

The key principle is that clean URLs are a server routing concern, not a browser concern. Your HTML files can be named conventionally, and the server handles presenting them at user-friendly URLs. This approach requires no JavaScript and works identically for search engine crawlers and human visitors. For more details on URL structure best practices, consult the documentation for your specific hosting platform or review general guidance in resources like the Google Search Central structured data guidelines.

When implementing clean URLs, ensure your internal links use the clean format (e.g., /faq rather than /faq.html) for consistency. Also verify that your canonical URLs match the clean URL format to avoid duplicate content signals. You can learn more about our editorial approach on the About us page.

Semantic tables serve multiple critical functions for both accessibility and search optimization. First, tables provide a scannable format that allows users to quickly compare information across multiple dimensions. Research consistently shows that users scan web content rather than reading linearly, and well-structured tables support this behavior by organizing data into predictable rows and columns.

From an accessibility perspective, properly marked-up tables enable screen reader users to navigate data efficiently. The W3C WAI Tables Tutorial provides comprehensive guidance on implementing accessible tables. Key requirements include using <caption> elements to describe the table's purpose, <thead> and <tbody> to distinguish headers from data, and scope attributes on header cells to establish relationships between headers and data cells.

For search engines, tables represent structured data that can be parsed and understood programmatically. While tables alone do not guarantee rich results, they provide clear signals about the relationships between data points on your page. This structured presentation can improve how search engines understand and potentially feature your content.

The requirement for at least one table per page ensures that every page offers some structured, comparative, or reference information rather than consisting entirely of prose paragraphs. This constraint encourages content creators to think about what data would genuinely help users and present it in the most accessible format.

Achieving natural keyword density requires strategic placement rather than mechanical repetition. The most effective approach focuses on including your primary keyword in high-value positions: the H1 heading, the first paragraph of body content, one or two H2 subheadings, and the table caption if your page includes tabular data. These positions carry significant weight for search relevance while appearing natural to readers.

Beyond these anchor positions, use synonyms, related terms, and natural variations throughout your content. If your primary keyword is "static site SEO," related terms might include "no-JavaScript optimization," "semantic HTML for search," or "accessible web content." This approach satisfies search engines' understanding of topical relevance while avoiding the robotic repetition that characterizes keyword stuffing.

To calculate density, divide keyword occurrences by total word count and multiply by 100. For a 1,000-word page targeting 1.5% density, you would include your primary keyword approximately 15 times. However, this should never feel forced—if natural writing produces 12 occurrences or 18 occurrences, both are acceptable. The goal is a range, not a precise target.

Avoid common stuffing patterns: repeating keywords in every paragraph opening, creating unnatural lists of keyword variations, or hiding keywords in metadata that does not match visible content. Search engines have sophisticated detection for these patterns, and they can result in ranking penalties. For more guidance on content optimization, return to the homepage and review the workflow section.

Authority links are outbound links to sources that establish credibility and provide additional context for your claims. The most valuable authority sources include government websites (.gov domains like CDC, NIH, Census Bureau, or state agencies), educational institutions (.edu domains), established non-profit organizations (.org domains with recognized expertise), Wikipedia for general reference, and major news organizations with editorial standards.

For US-focused niche sites, particularly valuable sources include the Centers for Disease Control and Prevention (CDC) for health topics, the National Institutes of Health (NIH) for medical research, the US Census Bureau for demographic data, the Federal Trade Commission (FTC) for consumer protection guidance, and state-specific regulatory agencies for local compliance information.

The minimum requirements vary by page type: homepage and pillar content should include at least three authority links to establish site-wide credibility, while inner pages and supporting content should include at least two. These links should be contextual citations that support specific claims rather than generic link lists at the bottom of pages.

When linking to authority sources, use descriptive anchor text that indicates what the user will find. For example, "according to Wikipedia's JSON-LD documentation" is more useful than "click here for more information." The nofollow attribute is not required for authority links but is acceptable if your editorial policy prefers it. What matters most is relevance and genuine citation value.

The HTML5 <details> and <summary> elements provide native disclosure widget functionality without any JavaScript requirement. When a user clicks or activates a summary element, the browser automatically toggles the visibility of the details content. This behavior is built into all modern browsers and works identically for mouse, keyboard, and touch interactions.

For keyboard accessibility, users can focus on the summary element using Tab navigation and toggle it open or closed using Enter or Space keys. Screen readers announce the expanded or collapsed state, allowing users to understand the current status and available interaction. This native accessibility support exceeds what many JavaScript accordion implementations provide.

Styling details and summary elements requires attention to the default disclosure marker (typically a triangle). You can customize or replace this marker using the ::marker pseudo-element or by hiding it and creating custom indicators with CSS. Focus states should use :focus-visible to provide clear visual indication for keyboard users without affecting mouse users.

For users who have enabled reduced motion preferences in their operating system, avoid animated transitions when expanding or collapsing details content. Use the prefers-reduced-motion media query to disable or minimize animations for these users. A simple approach is to use instant visibility changes rather than height transitions when reduced motion is preferred.

Schema.org structured data helps search engines understand your content's type and purpose. For a typical niche site, recommended schema types include Organization for the homepage (establishing your site's identity), FAQPage for FAQ content (enabling potential rich results), and AboutPage for your about section (clarifying your site's purpose and editorial standards).

The standard implementation method for schema is JSON-LD (JavaScript Object Notation for Linked Data) placed within a <script type="application/ld+json"> tag in the document head. However, since this site prohibits all script tags to maintain a truly static, no-JavaScript approach, we cannot embed JSON-LD in the conventional manner.

As an alternative, we provide JSON-LD code in visible <pre> blocks that you can copy and paste into your own implementation if your constraints differ. This approach documents the recommended schema while respecting the no-script requirement. If you control your hosting environment and can use script tags, simply copy the JSON-LD from the pre block into a properly typed script element.

For validation, use Google's Rich Results Test or Schema.org's validator to verify your JSON-LD syntax before deployment. Common errors include missing required properties, incorrect nesting, and mismatched types. The Google Search Central structured data documentation provides detailed guidance on implementation and testing.