Day: September 10, 2026

September 10, 2026

Domain Related

Reading Time: 56 minutes

Not deprecating it. Not reducing its features. Removing it. Google emailed users to say Assistant is being discontinued on compatible Android phones and tablets, with Wear OS devices, headphones, and Android Auto following. The rollout runs over several weeks, and once a device switches, there is no going back. Gemini becomes the assistant experience on Android. Assistant launched in 2016; ten years later, the product that most "voice search optimization" advice was written about is being decommissioned while that advice sits unrevised on hundreds of agency blogs. This matters more than a product retirement usually would, because Google Assistant was not incidental to voice search SEO. It was the mechanism. The specific technical recommendations that circulated for the better part of a decade — mark up your content with speakable structured data, add FAQPage schema to win the spoken answer, optimise for the featured snippet Assistant reads aloud — were all recommendations about how one product retrieved and read one answer. Two of those three recommendations no longer apply to anyone. The third applies to a product that is being turned off. So this is a reasonable moment to rebuild the topic from the ground up. What follows is not a refresh of the standard voice search checklist. It is an attempt to establish what is actually true about spoken and conversational search in 2026, what a Canadian business can genuinely act on, what cannot be measured, and where the real constraints sit. Some of those constraints turn out to be in your hosting infrastructure rather than your content, which is not where most of this conversation usually goes. A warning about the rest of this article: it will contradict a great deal of what you have read on this subject. Where it does, the reasoning and the source are given so you can check. What "voice search" actually means in 2026 The phrase has always been sloppy, and the sloppiness is the root of most bad advice about it. Three genuinely different things get bundled under one label, and they behave differently enough that treating them as one topic guarantees you optimise for the wrong one. Path one: voice...

September 10, 2026

Hosting Related, Security, Security Related

Reading Time: 49 minutes

There is a particular kind of conversation that happens when a small business gets breached. Somebody asks where the firewall was. And the honest answer, increasingly, is that there wasn't one, because there was nothing left for it to sit in front of. The business runs on a website it doesn't host, email it doesn't run, a payment processor it doesn't operate, and a laptop that connects to all of them from a kitchen table. There is no network edge. There is no inside. The thing everybody spent twenty years learning to defend simply isn't there any more. That is the shape of the problem, and it is why the security industry keeps announcing that the perimeter is dead. But the perimeter is not dead. It moved, it fragmented, and it multiplied. For a business whose most exposed asset is a public website, the new perimeter is small enough to write on a single page — which is precisely what makes it defensible, and precisely why so few businesses have done it. This guide is about drawing that page. Not a zero trust architecture programme. Not a reference model written for an organisation with a security team. An actual inventory of the things that, if someone else controlled them, would end your ability to operate — and what to do about each one. What the ‘perimeter’ used to mean, and what actually changed The traditional model was physical before it was digital. Your computers sat in your building. They talked to each other over cable you owned. Anything from outside had to pass through one controlled point, and you put your defences at that point. Castle and moat, as the metaphor goes, though the more accurate comparison is a factory with one gate and a security desk. It worked because two assumptions held. The first was that everything valuable sat inside a boundary you could draw. The second was that traffic crossing that boundary was rare enough and slow enough to inspect. Both assumptions have now failed, and they failed for ordinary commercial reasons rather than security ones. The three shifts that dissolved the boundary Software moved off your premises....

September 10, 2026

Domain Related

Reading Time: 50 minutes

Two things are worth establishing before any discussion of how to scrape a website. The first is legal, and it is the reason most guidance on this subject is unsafe reading for a Canadian business. Almost every web scraping article, tutorial and vendor page assumes American law. In the United States, fair use is an open-ended standard that courts apply case by case, and several recent decisions have gone in favour of large-scale data collection. Canada has no equivalent. Fair dealing under the Copyright Act is a closed list of specific purposes, and Canada has no text and data mining exception at all. The federal government has consulted on introducing one; it has not done so. A Canadian business scraping copyrighted material for a commercial purpose that does not fall within the enumerated categories is on considerably weaker ground than an American business doing the same thing, and no amount of "web scraping is legal" content written in California changes that. The second is about the word "better." A large part of the scraping industry defines better as harder to detect: rotate through residential IP addresses, spoof browser fingerprints, defeat the CAPTCHA, make your bot indistinguishable from a person. That is the business model of several of the tools you will find recommended, and this article does not cover it. Not out of squeamishness, but because it is a bad engineering strategy as well as a legally exposed one. It produces systems that are expensive, fragile, permanently one step from breaking, and dependent on infrastructure of dubious provenance. The better ways are duller and they work. Check whether the data is already available in a form you are welcome to take. Read the terms before you write the code. Identify yourself honestly. Make fewer requests. Cache what you already have. Fail gracefully. Store less than you could. These practices are more reliable, cheaper to maintain, and far less likely to end in a letter from someone's lawyer. This guide covers both, because for most readers here both apply. The first half is about collecting data from other people's sites. The second half is about the other side of the same...