Technical SEO, Performance and Ops

Overview

v1 treated technical SEO as a ranking lever. v2 treats it as a legibility and reliability requirement — the floor you must clear so that everything else has a chance to work. The honest framing is that excellent technical work will not save displaced content, but poor technical work will sink good content.

The distinguishing feature of this course is that it measures performance with advertising in place. A vitals score taken with the ad slots empty is a fiction, and it is the most common self-deception in ad-monetised publishing.

5.1 What is crawl and render control?

What is it?

Ensuring that what a machine retrieves and renders matches what you intended to publish: reachable URLs, one canonical version of each, and content present without requiring script execution.

Why it matters

Answer engines and crawlers vary enormously in whether and how they execute JavaScript. Content that exists only after client-side rendering is content you are gambling on. A static architecture (Course 4) makes this mostly free — this lesson is about verifying it rather than assuming it.

How to do it

1. Fetch a representative page with scripting disabled and confirm the substantive content, headings and links are all present.
2. Compare source HTML against rendered DOM on your most complex page — usually a tool page — and list every difference.
3. Confirm one canonical URL per asset: no duplicate paths, no parameter variants indexed, no trailing-slash duplicates.
4. Check robots directives and the sitemap actually reflect the 12 assets, and that nothing important is excluded by accident.
5. Verify status codes: real 404s for missing pages, permanent redirects for moved ones, no soft-404 pages returning 200 with an error message.

Crawl & render audit — per representative page
  URL | Canonical present and self-referential?  | Status code
  Content visible with JS disabled?              | Y/N + what is missing
  Source vs rendered diff                        | list of differences
  In sitemap?  | Robots directive  | Duplicate paths found

Tools needed

Browser devtools with scripting toggled, curl or an equivalent fetch tool, your sitemap, and a search console for the property.

Lab 5.1

Audit five pages: a pillar, a money page, a tool, a data asset and a support page. Fix every difference where content is missing without JavaScript, then re-audit and record the before and after.

Artifact

Crawl & render report: 5 pages, before/after, list of fixes with dates

Common mistakes

• Assuming the static host guarantees crawlability, then shipping a tool whose entire output is script-generated.
• Indexing parameter variants of tool pages, creating dozens of near-duplicate URLs.
• Soft 404s that return 200, which quietly waste crawl budget and confuse reporting.

Pro astuces

• Tool pages should ship a meaningful static explanation and a worked example in the HTML. The interactive part enhances it; it should not be the only content.
• Test with scripting disabled at least once per quarter. Regressions here are silent and are usually introduced by a well-meaning enhancement.

5.2 How do you measure Core Web Vitals with ads in place?

What is it?

Measuring loading, interactivity and layout stability under the conditions real readers experience — with advertising loaded, on a mid-range device, on a constrained connection.

Why it matters

Advertising is the primary cause of layout shift and main-thread contention on publisher sites. A vitals report taken without it measures a page nobody visits. Since the whole point of this academy is ad-monetised assets, measuring honestly is non-negotiable.

How to do it

1. Reserve every ad slot's dimensions in CSS before any script runs. This is a component-level rule from Course 4, not a per-page fix.
2. Measure each template three ways: no ads, ad slots reserved but unfilled, and ads actually serving. Record all three.
3. Throttle to a mid-range mobile device and a slow connection. Your development machine is not the audience.
4. Identify the largest contentful element per template and make sure it is not competing with an ad for priority.
5. Collect field data over time, not just lab runs. Lab data finds causes; field data tells you whether real readers are affected.
6. Set a regression budget: a template that exceeds it does not ship, the same way a page that fails the legal gate does not publish.

Tools needed

A lab performance tool, device and network throttling, a field-data source for the property, and your ad configuration.

Lab 5.2

Measure one template under all three conditions and calculate the delta attributable to advertising. Then reduce that delta by at least one meaningful change — reserved dimensions, deferred loading, fewer slots — and re-measure.

Artifact

Vitals comparison record
  Template | Condition (none / reserved / serving) | Metric values | Date | Device profile
  Delta attributable to ads | Change made | Post-change values
  Regression budget adopted (with the source you took the thresholds from)

Common mistakes

• Reporting the ad-free score internally and wondering why field data disagrees.
• Adding slots until revenue per page peaks, ignoring the reader-loss cost that does not appear in the ad report.
• Optimising a template that carries 3% of traffic while the money-page template goes unmeasured.

Pro astuces

• Reserved dimensions are the single highest-return change available to an ad-monetised site, and it costs nothing but discipline.
• Measure the tool templates especially carefully — they are the pages people are most likely to bookmark and return to, which is the governing question in metric form.

5.3 What structured data actually matters now?

What is it?

Machine-readable statements of the things a reader would want to know about provenance: who published this, who wrote it, what their credentials are, who reviewed it, when it was last updated, and what organisation stands behind it.

Why it matters

Rich-result decoration is a diminishing return. Provenance markup is not, because answer engines assembling a response need to attribute it, and attribution requires a machine-readable author and publisher. This is the technical half of Course 4's disclosure architecture and Course 7's E-E-A-T work.

How to do it

1. Mark up the organisation once, consistently, on every site — including the common-ownership relationship between siblings.
2. Mark up every editorial page with a real, named author entity that resolves to an author page with verifiable credentials.
3. Include the reviewer where a reviewer was used, and the date the review happened, not just the publish date.
4. Mark up your original datasets so the data itself is discoverable, not only the article describing it.
5. Validate everything, then re-validate after any template change. Broken markup is worse than none because it misstates provenance.
6. Never mark up something that is not visibly present on the page for readers. Divergence between markup and page is a trust failure and a policy violation.

Provenance markup — priority order
1. Organization + common-ownership relationship   (site level, all 3 sites)
2. Author (Person) with sameAs to verifiable profiles, on every editorial page
3. Reviewer + dateReviewed on any page requiring expertise
4. dateModified that is TRUE (not touched on every deploy)
5. Dataset markup for your 2 original data assets
6. Everything else, only if it is genuinely present for readers

Tools needed

A structured-data validator, your author pages, the reviewer register, and the search-engine documentation linked in Sources.

Lab 5.3

Implement organisation, author and reviewer markup across one full template set, then validate. Deliberately introduce a mismatch between markup and visible page content, observe how indefensible it looks written down, and revert it.

Artifact

Schema implementation map: template -> types implemented -> validation status -> date
Plus: the rule you adopted for when dateModified may change

Common mistakes

• Bumping dateModified on every deployment, which converts a useful signal into noise and misleads readers.
• An "author" who is a brand name with no page, no credentials and no accountability.
• Marking up review scores or prices that do not appear on the page.

Pro astuces

• Dataset markup on your original data assets is underused and directly serves Course 6's citation objective.
• Treat the author entity as infrastructure: one canonical author page per person, referenced everywhere, updated once.

5.4 What is information architecture for 12 assets?

What is it?

The arrangement of a small, high-value asset set so that each asset is reachable, each one's relationship to the others is explicit, and internal links carry meaning rather than volume.

Why it matters

With twelve assets you cannot hide behind category pages and pagination. Every link is a deliberate editorial statement. Done well, the architecture itself communicates what the site is for — which is what a returning reader, and an answer engine, both need.

How to do it

1. Draw the 12 assets and the intended relationships before writing navigation. Pillars anchor, money pages convert, tools retain, data assets attract.
2. Keep every asset within two clicks of the home page. With twelve assets there is no excuse for depth.
3. Write internal links as sentences a human would say. Anchor text that reads like a keyword is a signal of low effort to everyone.
4. Link from tools to the relevant money page and from money pages to the supporting data asset. That triangle is where value concentrates.
5. Give the newsletter archive a real place in the architecture — it is a recurring dated asset, not an afterthought.
6. Re-draw the map whenever an asset is added or pruned, and keep the map in the repository.

Tools needed

A diagram or a plain table, your MVP asset specification from Course 4, and your analytics for observed paths.

Lab 5.4

Map the 12 assets and every internal link between them. Find the asset with no inbound internal links and either link to it deliberately or question why it is in the MVP at all.

Artifact

IA & internal link plan
  Asset | Type | Clicks from home | Inbound internal links | Outbound to
  Orphans found | Decision for each (link deliberately / remove from MVP)

Common mistakes

• Building navigation first and discovering the architecture afterwards.
• Keyword-stuffed anchor text that damages credibility with human readers for a marginal machine benefit.
• Orphaned tools that only the newsletter links to, so new readers never find them.

Pro astuces

• The tool → money page → data asset triangle is the highest-value internal structure you can build. Make it explicit on all three pages.
• If an asset needs a forced link to be reachable, that is evidence about the asset, not about the architecture.

5.5 Why is accessibility infrastructure, not compliance theatre?

What is it?

Building pages that work with a keyboard, a screen reader, a magnifier and a poor colour environment — and that never contain elements which are invisible but still focusable or clickable.

Why it matters

Three reasons, in order of how often they are admitted: it is the right thing to do; accessible markup is the same markup that machines parse reliably; and inaccessible interactive elements are a legal exposure in many jurisdictions. For an ad-monetised site there is a fourth — hidden clickable elements near ad slots are an invalid-traffic risk.

How to do it

1. Navigate every template with the keyboard alone. Every interactive element must be reachable, in a sensible order, with a visible focus indicator.
2. Confirm nothing is invisible-but-focusable. Anything hidden must be hidden with display:none or the hidden attribute, never with opacity or off-screen positioning.
3. Check colour contrast for body text, muted text, links and buttons in both themes, including text over ad-adjacent backgrounds.
4. Give every image a purposeful alt attribute, and mark decorative images as decorative rather than describing them.
5. Label every form control properly, and make error messages programmatically associated with their inputs.
6. Test one full task with a screen reader — signing up for the newsletter is the right task, because it is the one that matters commercially.

Tools needed

Keyboard, an automated accessibility checker, a contrast checker, and a screen reader.

Lab 5.5

Run a keyboard-only audit of one full template and a screen-reader run of the newsletter signup. Record every element you could not reach, and every element you reached that you could not see.

Artifact

Accessibility audit record
  Template | Keyboard-reachable? | Focus visible? | Invisible-but-focusable count (target: 0)
  Contrast failures (element, ratio, theme) | Alt text gaps | Form label gaps
  Screen-reader task result: could the task be completed? where did it break?

Common mistakes

• Hiding menus with opacity or off-screen positioning, leaving dozens of focusable links a keyboard user must tab through blindly.
• Removing focus outlines for aesthetics.
• Trusting an automated checker alone — it cannot tell you whether a task can actually be completed.

Pro astuces

• "Invisible but focusable count must be zero" is a testable, unambiguous rule. Add it to your launch gate.
• Accessible tools are more likely to be linked and recommended, which serves Course 10 directly.

5.6 What is the technical ops routine?

What is it?

A fixed, scheduled set of technical checks with named owners, so that regressions are caught by a calendar rather than by a traffic collapse.

Why it matters

Across three sites, technical debt accumulates silently. The ops routine is what converts "we should check that sometime" into something that either happened on a date or did not. It also feeds the leading indicators in your risk register.

How to do it

1. Define checks at three cadences: weekly (uptime, errors, index coverage anomalies), monthly (vitals with ads, broken links, schema validation), quarterly (no-JS render, accessibility, full crawl).
2. Give every check an owner and an expected duration. An unowned check does not happen.
3. Define the alert condition for each check — what value or observation triggers action, decided in advance rather than in the moment.
4. Log every run with a date and a result, even when the result is "no change". The log is what makes a trend visible.
5. Connect the routine to the risk register: each check should be the leading indicator for at least one registered risk.
6. Review the routine at each pruning gate. Checks that never find anything can be reduced; areas that keep breaking need more.

Technical ops routine — skeleton
WEEKLY     uptime & error rate            owner: __  alert if: __
           index coverage anomalies       owner: __  alert if: __
MONTHLY    vitals WITH ads, 3 templates   owner: __  alert if: __
           broken internal/external links owner: __  alert if: __
           structured data validation     owner: __  alert if: __
QUARTERLY  render with JS disabled        owner: __  alert if: __
           accessibility audit            owner: __  alert if: __
           full crawl & canonical review   owner: __  alert if: __
Every run logged with date + result, including "no change".

Tools needed

A calendar, a simple log in the repository, your monitoring of choice, and the risk register.

Lab 5.6

Write the routine, assign owners, and run one full monthly cycle across all three sites. Time it. If the monthly cycle takes more than half a day, cut checks until it is sustainable — an aspirational routine that is skipped is worse than a small one that runs.

Artifact

Technical ops runbook: checks, cadences, owners, alert conditions, first cycle log with timings

Common mistakes

• A routine designed for a team of five, run by one person, abandoned in month two.
• Checks with no predefined alert condition, so every result is debated instead of acted on.
• No log, so nobody can tell whether a problem is new or has been there for six months.

Pro astuces

• Deciding the alert condition in advance is the whole value. In the moment, every number looks explainable.
• Run the routine across all three sites in one sitting. Comparing siblings is the fastest way to spot which problems are site-specific and which are template-wide.

Scenario assessment: the site that passed every test and lost every reader

The SMB cybersecurity site reports excellent lab performance scores and a clean technical audit. Field data tells a different story: mobile readers are leaving before the page is usable. Investigation finds that the audit was run with an ad blocker active, four ad slots were added after the last audit, two have no reserved dimensions, and the largest contentful element on the money-page template is now an ad. Separately, the newsletter signup cannot be completed with a keyboard because the consent checkbox is styled with a hidden input that never receives focus.

Final project: an honestly measured, machine-legible site

Prove the site is legible without JavaScript, fast with advertising, correctly attributed, reachable by keyboard, and monitored on a schedule.

Deliverable
1. Crawl & render report for 5 page types, with fixes applied and re-audited
2. Vitals comparison across 3 conditions for at least 2 templates, with an ad-attributable delta and one improvement
3. Regression budget adopted, with the primary source and date recorded
4. Schema implementation map: organisation, author, reviewer, dataset — all validated
5. IA & internal link plan for the 12 assets, orphans resolved
6. Accessibility audit with an invisible-but-focusable count of zero
7. Technical ops runbook with owners, alert conditions, and one completed cycle logged

Pass standard: your vitals evidence was captured with ads serving, and your accessibility audit records zero invisible-but-focusable elements across every template.

Course 5 checklist

• Substantive content present with JavaScript disabled on all 5 page types
• One canonical URL per asset; no parameter or trailing-slash duplicates indexed
• No soft 404s returning status 200
• Every ad slot has reserved dimensions in the component
• Vitals measured with ads actually serving, on a throttled mobile profile
• Ad-attributable delta calculated and reduced by at least one change
• Regression budget written down with its source and date
• Organisation, author and reviewer markup implemented and validated
• dateModified rule defined; it is not bumped on every deploy
• Nothing is marked up that is not visible to readers
• All 12 assets within two clicks of home; no orphans left unresolved
• Keyboard audit passed with a visible focus indicator everywhere
• Invisible-but-focusable count is zero
• Newsletter signup completed successfully with a screen reader
• Ops routine has owners, alert conditions and a logged first cycle

AI-agent prompt for Course 5

Act as a technical SEO and performance auditor for a three-site static publishing portfolio that carries display advertising.

I will paste: my template list, my ad slot configuration per template, my current measurements, and my asset map.

Do this:
1. For each template, list what must be verifiable with JavaScript disabled, and flag any element whose content would be missing.
2. Design a three-condition performance measurement plan (no ads / slots reserved / ads serving) and specify the device and network profile to hold constant across runs.
3. Identify, per template, the likely largest contentful element and flag any template where an ad is competing with it.
4. Produce a provenance-first structured data plan: organisation with common-ownership relationship, author, reviewer, dateModified rule, dataset. Mark anything I should NOT mark up because it is not visible to readers.
5. Audit my asset map for orphans and for missing tool -> money page -> data asset links.
6. Produce an accessibility check list specific to my components, with an explicit "invisible but focusable must equal zero" test.
7. Build a weekly/monthly/quarterly ops routine with an owner slot and a PREDEFINED alert condition for every check, and estimate the monthly cycle duration.

Rules:
- Do not state Core Web Vitals thresholds, crawl budget figures, or any platform limit as facts. Output each as a claim row: claim, why it matters, primary source to check, owner, 90-day expiry.
- Assume all measurements must be taken with advertising serving; explicitly reject any plan that measures with ads blocked.
- Never recommend marking up data that is not visible on the page.
- If my monthly ops cycle would exceed half a day for one person, cut checks and say which ones you cut and why.
Output as tables.

Primary sources

• Search Essentials and SEO starter guide
• Introduction to structured data markup
• Core Web Vitals — current metric definitions
• WCAG accessibility standards

Metric definitions, thresholds and markup requirements are revised over time. Read them live at the moment you implement, and log whatever you adopt in the claim register with a 90-day expiry.