Overview
A technical SEO lab that grew in six steps. First a landing page built in the real Elementor editor on local WordPress and audited with a 15 check technical SEO script. Then keyword and AI answer visibility scripts that plan a page structure. Then a public six page WordPress.com sample site built from that plan. Then a written QA defect report from usability testing that site and a second sample site. Then the same audit run on a stock OpenCart 4 store, with an OpenCart extension that fixes what it found. Last, a WooCommerce shop priced live from a stand-in metals feed, measured and hardened.
The sites and the shops are samples with placeholder text and a sample organisation, and the footer of each site says so.
Key Features
A page built through the editor, then audited
- Built with the editor's own command API. A headless browser opens the Elementor editor and creates the five sections, then saves with the editor's publish command.
- A 15 check technical SEO audit. Status, titles, meta descriptions, headings, image alt text, canonical, viewport, Open Graph, structured data, broken links, response time and page weight. The first run scored 12 of 15, a small must-use plugin fixed the three misses, and the re-run scored 15 of 15.
A stock OpenCart store, fixed by an extension
- The same audit on a PHP store. A fresh OpenCart 4 in Docker, with a six product sample shop, scored 8, 10 and 10 of 15 on its home, category and product pages. The misses were the title, the meta description, the canonical link, Open Graph tags, structured data, heading order, and a default banner that linked to a product that returns a 404.
- An OpenCart extension, wired in with six events. No core file is edited. It adds canonical links that drop sort and limit parameters, noindex on cart, checkout, search and account pages, Open Graph tags, JSON-LD for the organisation, breadcrumbs and each product with its price and stock, a home page heading, a clean heading order and a title length rule. It also adds an XML sitemap, with robots rules beside it. All three pages then scored 15 of 15.
- A bug in my own audit. OpenCart sets a base address for its links, and the audit ignored it, so it called a working link broken. The audit now follows the base address, with a test.
A WooCommerce shop priced live from a metals feed
- A local shop in Docker. WooCommerce with twelve gold and silver products, priced from a stand-in metals feed written for this project, so the price is computed whenever WooCommerce reads it and the page, cart, markup and feed cannot disagree.
- A cached price reading in a must-use plugin. One saved reading is kept for a few seconds, one request at a time refreshes it, a reading that jumped more than 15 percent is thrown away, and a stale price is marked and then withdrawn along with the add to cart button, the offer markup and the feed line. That cut the shop page's server response from 1969 to 233 ms. Trimming the render blocking files Lighthouse named took the mobile score from 91 to 98 and the Largest Contentful Paint from 3.2 to 2.3 seconds.
- Product and Offer markup and a Google Merchant Center feed. The offered price is checked against the price printed on the page, and the offer's valid until time is the time the saved reading expires.
- Hardening. Security headers, XML-RPC refused, scanner probes refused, a closed users list, rate limits and a login limit took an outside probe from 1 of 13 checks to 13 of 13.
Keyword research and AI answer visibility
- Keyword and topic research. Seeds are expanded with question and modifier words, sent to Google, Bing and DuckDuckGo autocomplete, scored by how many sources agree, grouped under a shared phrase and turned into a page plan with a pillar page and internal links.
- AI answer visibility. Each question is asked of a local model several times and a name counts when it appears as a whole word, reported with a 95 percent interval. An engine error is an error and never a miss.
A public sample site and a written defect report
- A launched six page WordPress.com site on the free plan, built in the block editor, with its own audit and an edit and revert read back on the public page.
- Usability testing at two widths. All six pages, the search results page and the 404 page of that site, and all 34 pages of a second sample site, opened in headless Chromium at 1280 and 390 pixels wide.
- A QA defect report. 9 defects, each reproduced more than once and written with steps to reproduce, the expected and actual result, a screenshot and a suggested fix, plus a severity scale (6 minor and 3 cosmetic) and a list of what was checked and found clean.
What I Tested
On the bullion shop, 85 PHP checks cover the price rules and the markup, 32 Python checks cover the probes, and 79 deliberate breakages are each caught. Live checks run a dead feed, a feed that triples the gold price and one that answers with a maintenance page, and none of them reaches a customer. The speed figures are Lighthouse's simulated mobile numbers on a local test page. Offline checks cover the SEO audit, the keyword research, the AI visibility script (including both engine types against a stand-in server) and the PHP markup code, with a product name that tries to close the structured data block among the hostile inputs. A second script breaks 39 guards one at a time, in Python and PHP, and needs a test to go red each time. Its first run on the PHP guards caught 38 of 39: one test was too weak to notice a description cut in the middle of a word, and it was fixed. CI runs all of it, including the PHP syntax check.
What I Learned
A defect report is only useful if someone else can repeat it, so every defect here was reproduced more than once before it was written down, and the report says what was clean as well as what was wrong. I also learned to say where a test method is the limit and not the site: mobile browser identity strings from headless Chromium drew a bot check on WordPress.com, so the phone results use a 390 pixel touch screen with the browser's own identity string.
Tech Stack
CMS and Commerce: WordPress, Elementor, WordPress.com block editor, WooCommerce, OpenCart 4, Google Merchant Center Backend: PHP, an OpenCart extension and events, a WordPress must-use plugin, Product and Offer structured data Tooling: Docker, WP-CLI, Python, Playwright Research: Google, Bing and DuckDuckGo autocomplete, a local Ollama model Testing: offline Python checks, a guard-breaking script, GitHub Actions, usability testing, defect reports