DEV Community: Ryan VerWey

The Decision Tax: When More Options Make an Interface Worse

Ryan VerWey — Tue, 08 Sep 2026 14:34:44 +0000

Originally published on ryanverwey.dev.

Choice overload is not the presence of many options. It is the point where an interface asks a person to do more comparison work than the decision feels worth.

That distinction matters. A catalog with 10,000 products can feel manageable when search, filters, categories, recommendations, and comparison tools reduce the active decision to a useful set. A pricing page with four plans can feel overwhelming when the names are vague, features are inconsistent, and every card claims to be the best value.

The design problem is not simply quantity. It is decision work: how much effort users must spend understanding the choice, comparing alternatives, predicting consequences, and feeling confident enough to act.

I call that accumulated effort the decision tax. Every option adds potential value, but it can also add discovery, comparison, uncertainty, and regret. Good choice architecture preserves meaningful agency while reducing the tax required to use it.

This second entry in my Applied Design Theory series explains when choice overload is likely, why it is related to but different from Hick's Law, and how I use the SCOPE review to design better pricing pages, filters, onboarding flows, settings, and product selections.

Choice Overload Is a Mismatch, Not a Number

Choice is usually valuable. It lets people express preferences, adapt a product to their situation, and avoid being forced into an unsuitable default. Removing all choice is not simplicity. It is control taken away from the user.

Overload begins when the demands of the decision exceed the support provided by the interface. The same set of options can be easy for one person and exhausting for another because the user, task, consequences, and presentation have changed.

Consider three people choosing a camera:

A professional photographer arrives with a specific mount, sensor requirement, and budget. A large catalog helps because their preferences are already formed.
A first-time buyer knows they want better family photos but does not understand lenses, sensor formats, or stabilization. The same catalog creates a vocabulary problem before it creates a product decision.
A traveler needs a replacement before a flight. Even with strong product knowledge, time pressure makes a large comparison set expensive.

The number of cameras did not change. The decision did.

This is why rules such as "never show more than seven options" are attractive and unreliable. They convert a contextual design problem into an easy checklist. The interface may pass the checklist while leaving the actual work untouched.

The overload threshold moves with the context. More options can improve fit until comparison cost and uncertainty begin to reduce confidence.

What the Famous Jam Study Actually Tells Us

The most repeated choice-overload story comes from Sheena Iyengar and Mark Lepper's 2000 paper, When Choice Is Demotivating. In the field experiment, shoppers encountered a display of either 24 jams or six. The larger display attracted more attention, but nearly 30 percent of people exposed to the smaller set purchased a jar, compared with about 3 percent in the larger-set condition.

The paper included two additional experiments. Students were more likely to complete an optional essay when choosing from six topics instead of 30, and participants choosing chocolates from a smaller assortment reported better experiences after the decision. Together, the studies challenged the assumption that more choice always produces more motivation and satisfaction.

The useful lesson is not that six is a perfect interface number. Jam samples, essay prompts, and chocolates share particular conditions: options are similar, the ideal choice is uncertain, comparison consumes time, and choosing the wrong item is easy to imagine after the fact.

The result is also a warning about product metrics. The large display won attention while the small display won purchasing. An interface can look engaging at the top of a funnel while making commitment harder at the bottom. Counting impressions, card opens, or time on page without measuring completion can reward the very friction the product should remove.

The Research Does Not Support a Universal Limit

Choice overload became a popular design explanation because it feels immediately true. Anyone who has stared at a wall of nearly identical televisions or compared a dozen software plans recognizes the experience. Research after the original studies, however, makes the conclusion more precise.

Scheibehenne, Greifeneder, and Todd's 2010 meta-analysis of choice-overload experiments examined 63 conditions from 50 published and unpublished experiments with 5,036 participants. The average effect was close to zero, while the variation between studies was substantial. In some contexts, larger assortments harmed decisions. In others, they helped or made little difference.

That is not evidence that choice overload is imaginary. It is evidence that assortment size alone is an incomplete explanation.

Chernev, Böckenholt, and Goodman's later conceptual review and meta-analysis analyzed 99 observations involving 7,202 participants and identified four conditions that reliably shape overload risk:

Choice-set complexity: Options contain many attributes, attributes are difficult to compare, or alternatives are very similar.
Decision-task difficulty: The user faces time pressure, incomplete information, uncertain consequences, or a demanding evaluation process.
Preference uncertainty: The user does not yet know which attributes matter or how to trade one benefit against another.
Decision goal: The user wants to minimize effort rather than invest deeply in finding an optimal result.

This gives designers a stronger model. The question is not "How many options are too many?" It is "How much unresolved decision work have we placed in front of this person?"

Choice Overload and Hick's Law Are Related, Not Interchangeable

Choice overload is often paired with Hick's Law, but they describe different outcomes.

W. E. Hick's 1952 experiments on the rate of information gain studied choice reaction time. As the uncertainty among possible stimulus-response pairs increased, reaction time increased in a predictable relationship. In interface language, selecting one item from a larger set of equally plausible actions generally takes longer than selecting from a smaller set.

Choice overload reaches beyond reaction time. It can involve postponing the decision, abandoning it, feeling less satisfied afterward, or continuing to wonder whether an unchosen option was better.

This difference changes how I apply the concepts:

Hick's Law helps evaluate selection speed among visible actions.
Choice overload helps evaluate motivation, confidence, completion, and satisfaction across a decision.
Hick's Law is most direct when options are known and the task is to select.
Choice overload becomes especially relevant when users must first understand what the options mean and decide what they value.

A navigation menu with twelve familiar destinations may slow scanning without creating meaningful overload. Three health-insurance plans can create overload because the consequences are important and the tradeoffs are difficult. Counting options without examining the decision hides that difference.

The Decision Tax

The decision tax is the total work an interface transfers to the user before they can choose with confidence. I break it into five costs.

Discovery Cost

What must the user inspect before they can form a reasonable shortlist?

Discovery cost rises when every option receives equal visual weight, labels are vague, categories reflect the company's organization instead of the user's goal, or important differences are buried in detail pages.

Search and filters can lower discovery cost, but only when their vocabulary matches what people know. A filter labeled "deployment topology" may be technically precise and useless to a buyer who thinks in terms of "works with my existing server."

Comparison Cost

How much work is required to compare the remaining options on the same dimensions?

Comparison becomes expensive when cards describe different attributes, units change, features appear in inconsistent orders, or the user must remember facts while moving between pages. A side-by-side table is useful because it externalizes memory and aligns differences. It does not help when the table contains 80 undifferentiated rows.

Interpretation Cost

Does the user understand why a difference matters?

Technical products often expose implementation details before translating their consequences. Storage, requests, seats, integrations, response time, and support levels matter only after the user can connect them to a real need. Good content gives the attribute a job instead of presenting it as a number.

Consequence Cost

How difficult or risky is it to be wrong?

Choosing a playlist theme has a low consequence cost. Selecting a billing plan, deleting data, changing permissions, or configuring a deployment has a higher one. High-consequence choices need clearer previews, stronger comparison, confirmation, reversibility, and honest explanations of what changes.

Regret Cost

How much does the interface keep unchosen alternatives psychologically active after the decision?

When every option claims a unique advantage, users can imagine a benefit they sacrificed no matter what they select. Clear tradeoffs, a transparent default, easy plan changes, and a reversible trial reduce the pressure to make a permanently perfect choice.

The decision tax explains why simply deleting options is an incomplete fix. A team can reduce six plans to three and still leave every cost in place. Better design removes unnecessary work while preserving options that represent real differences.

A Catalog Is Not a Decision Surface

One of the most useful distinctions in interface design is the difference between how many options a system supports and how many it asks the user to evaluate at once.

An online store may need a large catalog. A developer tool may support dozens of integrations. A dashboard may expose hundreds of reports. The product does not need to flatten that inventory into one visual decision.

The interface can stage the work:

search when the user knows the target
categories when the user recognizes a goal
filters when attributes are understood
guided questions when preferences are still forming
recommendations when the reason can be explained
comparison when a shortlist exists
progressive disclosure when detail becomes relevant later

This is not hiding choice. It is sequencing choice while keeping the broader catalog reachable.

Comparison Is an Interface, Not a Spreadsheet Dump

When options are genuinely different, comparison is necessary. The design responsibility is to make those differences legible.

Pricing pages expose this problem clearly. Teams often add plans over time, write each card independently, attach multiple badges, and list whichever features make that tier sound strongest. The cards become advertisements rather than a comparison surface.

A useful comparison aligns the options around shared questions:

Who is this for?
What limit changes?
Which capability becomes available?
What remains the same?
What happens if the user outgrows the choice?

The better surface does not pretend the other choices do not exist. It gives users common criteria, an explainable recommendation, and a path to full detail.

The recommendation deserves special care. A "Most Popular" badge may reduce effort, but it can also become a dark pattern when it exists only to steer buyers toward the most profitable tier. An honest default states the reason: "Best for teams that need approvals" is more useful than "Best Value." The recommendation should help the user map a plan to a situation, not borrow authority the interface has not earned.

Preserve Agency While Reducing Work

Choice architecture becomes manipulative when simplification quietly removes meaningful alternatives or preselects the outcome that benefits the business. The goal is not to make users choose faster at any cost. The goal is to make the decision understandable.

I use five principles:

Prefer Meaningful Differences

Options should represent real tradeoffs. If two plans differ only because the product team wants another price anchor, the interface inherits comparison work without adding meaningful agency.

Before designing cards, ask whether each option deserves to exist. Information architecture cannot permanently repair a weak product architecture.

Give the User a Starting Point

A featured option, saved configuration, sensible default, or short guided question can reduce the blank-page problem. The starting point should be transparent and reversible.

Defaults are especially powerful, which means they require restraint. Use them to express a safe, common choice, not to sneak consent, upgrades, or recurring charges past the user.

Make Tradeoffs Comparable

Use consistent labels, units, order, and levels of detail. Keep the attributes people use to decide visible together. Move secondary specifications behind expansion only after the primary differences are clear.

Let People Narrow Before They Compare

Filtering is not merely a catalog feature. It is a decision-making tool. Good filters remove irrelevant options based on criteria the user understands and preserve the state so the user can revise the shortlist without starting over.

This is one reason I prefer semantic, URL-backed filters for substantial content and product collections. They make the current decision state visible, navigable, and shareable. When implemented server-side, they can also preserve crawlable source content while keeping filtered utility URLs out of the index through deliberate canonical and robots behavior.

Keep the Full Set Reachable

Progressive disclosure should reduce immediate demand without creating a dead end. "Show all," "Compare features," and removable filter chips give people control over how much complexity they want to take on.

The interface should support both the person who wants guidance and the expert who already knows what they need.

The SCOPE Review

Before I ship a decision-heavy interface, I review it through five questions: Set, Compare, Organize, Progressively reveal, and Enable narrowing.

SCOPE is not a rule for making every interface smaller. It is a review for making the user's decision clearer.

S: Set the Decision

What is the user actually choosing?

This sounds obvious, but interfaces often mix several decisions in one surface. A checkout may ask the user to select shipping speed, insurance, gift options, payment method, account creation, and marketing consent without separating their purposes.

Write the decision as one sentence: "Choose the plan that supports your team size and approval needs." If the sentence needs several unrelated clauses, the interface may need stages.

C: Compare Consistently

Can alternatives be evaluated on shared dimensions?

Normalize the data before designing the cards. If one product lists capacity, another lists speed, and a third lists compatibility, visual polish will not make them comparable. Define the decision attributes, units, missing-value behavior, and display order as part of the product model.

Consistency also matters for accessibility. Repeated structures should preserve heading order, label controls clearly, and avoid making color or position the only signal for a difference.

O: Organize Meaningfully

Can users recognize useful groups before inspecting every item?

Group by user goal, task, compatibility, or another distinction that helps eliminate irrelevant options. Avoid categories that exist only because they mirror internal departments or database fields.

Organization should reduce scanning without implying false exclusivity. A tool can belong to more than one useful category when the underlying model supports it.

P: Progressively Reveal

What information is required for this stage of the decision?

Show enough to understand the tradeoff, then provide detail on demand. Progressive disclosure fails when essential costs, restrictions, or consequences are hidden behind interaction. It also fails when the collapsed label is too vague to predict what it contains.

The right test is not whether content fits above the fold. It is whether the user can make the next decision without carrying unnecessary information in working memory.

E: Enable Narrowing

Can users reduce the set using criteria they understand?

Search, filters, sort controls, guided questions, and comparison trays serve different forms of intent. Search supports a known target. Filters support known attributes. Guided questions help form preferences. Comparison supports a shortlist.

Do not force one control to perform every job. A search field cannot replace a useful category system, and dozens of filters cannot help someone who does not know what the attributes mean.

Building Choice Architecture in the Front End

Choice overload is not solved only in a design file. The implementation determines whether the support survives real content, responsive layouts, assistive technology, and changing product data.

Model Options Around Comparable Attributes

Use structured data for the facts that drive comparison. A pricing tier should not store its entire meaning in an arbitrary marketing paragraph. Team size, limits, included capabilities, support level, and upgrade behavior should be fields that can be rendered consistently.

Structured attributes also make it possible to test missing values, prevent contradictory claims, generate accessible tables, and reuse the same source across cards, comparison views, and metadata.

Keep Filter State Understandable

The selected state should survive navigation, refresh, and sharing when the task benefits from it. URL parameters are often appropriate for filters, but they need deliberate SEO handling. The canonical collection remains the indexable source while utility combinations can be noindex, follow when they do not represent distinct search destinations.

This avoids solving a UX problem by creating an indexing problem.

Use Native Controls

Native selects, checkboxes, radio groups, buttons, and links provide semantics and keyboard behavior that custom clickable containers must rebuild. A plan card can be visually rich while its selection control remains a real radio input with a visible label.

For progressive disclosure, the trigger needs an accessible name, an expanded state, and predictable focus behavior. For comparison tables, row and column headers need semantic relationships. For recommendations, the reason must be available as text, not only a colored badge.

Design the Small Screen as a Decision Sequence

A desktop comparison table cannot simply shrink until it becomes unreadable. On mobile, preserve the shared criteria and let users compare a small number of options at a time. Sticky option headers, a two-item comparison tray, or criterion-by-criterion sections can maintain context without forcing horizontal memory.

Responsive design should change the presentation, not erase the information needed to choose.

How to Measure Choice Overload

Overload is easy to label after a design review and harder to prove. I look for a pattern across behavior rather than one metric.

Useful signals include:

Time to first meaningful action: How long does it take to begin narrowing or comparing?
Decision completion: Do people finish, postpone, or abandon the choice?
Backtracking: How often do users reopen options or repeat the same comparison?
Selection volatility: How frequently does the choice change before commitment?
Support-tool use: Are filters, comparisons, recommendations, or guided questions helping?
Errors and reversals: Do people immediately undo, downgrade, cancel, or contact support?
Confidence: Can users explain why their selected option fits their needs?

In moderated research, I ask participants to state their decision criteria before they begin. If they cannot, I watch whether the interface helps them form those criteria or simply makes them inspect more cards.

The experiment should compare decision support, not only assortment size. Test a raw set against grouped options, aligned comparison, guided narrowing, or a transparent default. That tells the team which form of support reduces the tax without removing needed choice.

When More Choice Is the Better Design

Large assortments can be a feature when the interface and context support them.

More choice is useful when:

users arrive with clear preferences or a known target
meaningful variation exists across the audience
search and filters quickly remove irrelevant options
experts need precision or control
the task is repeated and users can build fluency
alternatives are easy to compare on stable attributes
choosing incorrectly is inexpensive or reversible

The right move is often layered access: a strong default for common needs, guided controls for developing preferences, and complete control for experts.

That is the same principle I use in The Novelty Budget. Familiar structure creates a stable core. Product-specific capability can live at the edge. Here, the stable core is a comprehensible decision, and the edge is the breadth of choice the product genuinely needs to support.

A Practical Team Review

Before release, I ask the team to answer these questions together:

Product: Which options represent meaningful differences, and which exist for internal reasons?
Design: Can a user identify the decision and the primary tradeoffs without opening every option?
Content and engineering: Are labels clear and attributes structured consistently enough for comparison?
Accessibility: Can people compare without relying on pointer precision, color, or visual memory?
Research and analytics: Are we measuring confident completion, reversals, and abandonment instead of attention alone?

This keeps choice overload from becoming a cosmetic diagnosis. A confusing surface may expose inconsistent tiers, missing content strategy, or weak data modeling. The interface is often where organizational ambiguity becomes visible.

Final Takeaway

More choice is not automatically empowering, and less choice is not automatically usable.

Choice overload appears when the interface presents more unresolved comparison, interpretation, consequence, and regret than the user can justify for the task. The threshold moves with the person, the options, the stakes, and the support built around the decision.

Do not chase a magic number. Define the decision. Align the differences. Organize around user goals. Reveal detail when it becomes useful. Give people tools to narrow the set, and keep the broader choice reachable when it represents real value.

The goal is not to choose for the user. It is to stop charging them unnecessary work for the right to choose.

References

Chernev, A., Böckenholt, U., & Goodman, J. (2015). Choice overload: A conceptual review and meta-analysis. Journal of Consumer Psychology, 25(2), 333-358.

Hick, W. E. (1952). On the rate of gain of information. Quarterly Journal of Experimental Psychology, 4(1), 11-26.

Iyengar, S. S., & Lepper, M. R. (2000). When choice is demotivating: Can one desire too much of a good thing?. Journal of Personality and Social Psychology, 79(6), 995-1006.

Scheibehenne, B., Greifeneder, R., & Todd, P. M. (2010). Can there ever be too many options? A meta-analytic review of choice overload. Journal of Consumer Research, 37(3), 409-425.

Toffler, A. (1970). Future shock. Random House.

FAQ

What is choice overload in UI/UX design?

Choice overload is the decline in motivation, confidence, completion, or satisfaction that can occur when a decision requires more comparison work than a user can comfortably manage. It depends on the complexity of the options, the task, the user's preferences, and the consequences, not only the number of choices.

Is choice overload the same as the paradox of choice?

The terms are often used interchangeably. Both describe situations where additional options can make choosing harder or less satisfying. In interface work, "choice overload" is useful because it focuses attention on observable decision behavior and the conditions producing it.

How is choice overload different from Hick's Law?

Hick's Law describes how decision time changes as uncertainty among possible responses increases. Choice overload concerns broader outcomes such as deferral, abandonment, confidence, regret, and satisfaction. A selection can take longer without becoming overload, and a small high-stakes set can create overload even when it contains few options.

How many options should an interface show?

There is no universal limit. Show enough options to represent meaningful differences, then reduce decision work through grouping, consistent comparison, progressive disclosure, defaults, search, and filtering. Test whether users can explain and complete the decision confidently.

Do filters solve choice overload?

Filters help when users understand the attributes and can identify what matters. They are less useful when preferences are still forming or labels use unfamiliar language. In those cases, guided questions, recommendations with reasons, and clear categories may provide a better starting point.

What is the SCOPE review?

SCOPE is my five-part review for decision-heavy interfaces: Set the decision, Compare consistently, Organize meaningfully, Progressively reveal detail, and Enable narrowing. It is designed to reduce unnecessary decision work without removing meaningful user choice.

The Novelty Budget: Why Good Interfaces Borrow Before They Invent

Ryan VerWey — Tue, 01 Sep 2026 14:34:24 +0000

Originally published on ryanverwey.dev.

Familiar interfaces are not successful because designers lack imagination. They are successful because users arrive with experience already installed. A cart icon, an underlined link, a Back action, a visible form label, and a predictable checkout sequence let people act before they have studied the product.

Novel interfaces are not automatically brave, innovative, or better. Every unfamiliar behavior asks the user to stop, inspect, predict, test, and remember. That learning can be worthwhile, but only when the product returns more value than the interaction costs to understand.

My working rule is simple: every interface has a novelty budget. Spend it on the part of the experience that makes the product meaningfully different. Borrow the rest from patterns people already know.

This first entry in my Interface Tensions series explains how I decide what to preserve, what to challenge, and what evidence I want before an unfamiliar pattern ships.

Familiarity Is Stored Work

When a user recognizes a pattern, they are not beginning from zero. They are applying prior practice from other products, physical objects, and repeated tasks. The designer benefits from work that someone else already paid for.

That is the useful core of Jakob's Law: people spend most of their time using products other than ours, so their expectations are shaped elsewhere. Megan Chan's discussion of mental models describes those expectations as beliefs people use to predict what a system will do. The belief does not have to be technically accurate to guide behavior. If an interface looks like a search field, people expect it to search. If a logo sits in a site header, many people expect it to return them home. If Back looks available, they expect it to reverse the last navigational step.

This is why familiarity is more than a visual preference. It is stored work. It carries four practical advantages:

Faster orientation. People can identify where they are and what they can do without reading instructions.
Lower memory demand. Visible, recognizable options reduce the need to recall commands or hidden rules.
More confident prediction. People can estimate what will happen before they act.
Faster recovery. Familiar error messages, undo actions, and Back behavior help people recover when something goes wrong.

Raluca Budiu's explanation of recognition versus recall matters here. Recognition gives memory more cues. A visible list of options is easier to work with than a blank field that expects the user to remember a command. A labeled icon is usually easier to interpret than an icon whose meaning must be learned. A recent-history list is easier than reconstructing where you were from memory.

The strongest interfaces often feel obvious not because they are simple underneath, but because they preserve enough familiar cues that the underlying complexity does not become the user's first problem.

The novelty budget treats unfamiliarity as a real product cost. The cost is justified only when the benefit survives beyond the first moment of surprise.

Novelty Is a Cost Before It Becomes a Capability

Design teams experience a product differently from the people using it. We see the same screens for weeks or months. We know the vocabulary, the edge cases, the roadmap, and the logic behind every exception. Familiarity can make a working interface feel stale to the team long before it feels stale to the user.

That imbalance is dangerous. A redesign can solve the team's boredom while creating the user's confusion.

Nielsen Norman Group's article on the power law of learning makes the underlying tradeoff clear: a common pattern benefits from practice accumulated across many products, while a new pattern begins at the steep end of its learning curve. The new design may eventually become more efficient, but the user has to remain engaged long enough to reach that point.

This does not mean novelty is bad. It means novelty has an invoice.

An unfamiliar pattern may require:

additional explanation or contextual guidance
clearer system feedback after each action
a fallback for users who do not discover the new behavior
stronger error recovery because prediction is weaker
accessibility testing across keyboard, touch, zoom, and assistive technology
repeated exposure before the interaction becomes efficient

Those costs are reasonable when the new behavior unlocks something meaningful. They are wasteful when the change exists mainly to make a common task look distinctive.

Replacing a conventional checkout flow with a radial gesture menu is novelty attached to a high-risk commodity task. Giving a data analyst a new way to manipulate a complex relationship directly on a canvas may be novelty attached to the actual value of the product. Both interactions can look original. Only one has a credible reason to ask the user to learn.

The Difference Between Visual Novelty and Behavioral Novelty

One reason teams argue past each other is that "novel" can describe several different things.

Visual novelty changes how the experience feels. It can come from typography, illustration, color relationships, composition, rhythm, photography, or motion. A page can look unmistakably original while its links, forms, menus, and controls remain conventional.

Structural novelty changes where information lives or how the experience is organized. A product may replace a familiar top navigation with a persistent workspace rail, reorganize content around objects instead of pages, or introduce a new hierarchy.

Behavioral novelty changes what actions mean and how the user performs them. This is the most expensive form because it changes prediction. The same gesture may produce a different result, a familiar control may behave in an unfamiliar way, or a task may require a sequence the user has never practiced.

These forms should not be treated as equally risky. Visual expression can create a memorable brand without forcing the user to relearn basic operation. Structural change requires stronger orientation. Behavioral change needs the strongest justification, feedback, and testing.

That separation gives a team more room than the familiar-versus-novel debate usually suggests. We do not have to choose between a generic interface and an experimental one. We can keep the interaction contract familiar while making the experience visually specific to the product.

Three Layers of Interface Change

I use three layers to decide where invention belongs: safety, product, and expression.

The safest approach is not uniform conservatism. It is assigning a different level of freedom to each layer of the experience.

1. The Safety Layer: Preserve the Contract

The safety layer includes the actions people rely on to move, understand consequences, submit information, and recover. It covers navigation, form labels, focus behavior, destructive actions, confirmation, undo, status, and error messages.

This layer should usually be boring in the best possible way. A destructive button should look and behave like a destructive action. A keyboard user should encounter controls in a meaningful order. A required field should be identified before submission. A Back action should not secretly jump to an unrelated hierarchy level.

Consistency here is also an accessibility concern. The W3C guidance for WCAG 2.2 Success Criterion 3.2.3 explains that repeated navigation in a consistent relative order helps people predict where functions will appear. That predictability is particularly important for users working through screen magnification, sequential screen-reader output, cognitive limitations, or limited motor input.

Novelty in the safety layer can make the product memorable for the wrong reason. If a person has to learn your unique meaning for Save, Close, Back, Delete, Search, or Submit, the interface is spending attention on infrastructure instead of value.

2. The Product Layer: Challenge Selectively

The product layer is where the application performs its defining work. This is the most defensible place for behavioral novelty because a better interaction can become a real capability.

An AI-assisted editor may need a new pattern for reviewing proposed changes before they are applied. A spatial planning tool may need direct manipulation that has no close equivalent in a document interface. A collaboration product may need a new way to show presence, ownership, or branching work. A complex audit product may need to turn hundreds of findings into a prioritized repair plan instead of another flat report.

This is where I am willing to challenge convention, but I still want familiar anchors around the new behavior. The user should recognize the objects, labels, state changes, and recovery options even if the core workflow is new.

While building Optimize, for example, the distinctive value was not inventing a strange new way to click through a report. The value was in turning SEO, AEO, GEO, crawler, structured-data, and accessibility findings into a clearer decision surface. Familiar report organization provided the foothold. The product logic supplied the difference.

The same principle shapes design-system work. In building an Angular design system, I found that consistency at the component and token level creates room for teams to solve higher-order product problems. If every button, form field, spacing decision, or responsive pattern is reinvented locally, the organization spends its novelty budget before it reaches anything customers value.

3. The Expression Layer: Differentiate Deliberately

The expression layer includes typography, imagery, pacing, transitions, tone, editorial composition, and moments of delight. This layer can carry far more novelty because it can create distinction without changing the meaning of basic actions.

A portfolio, cultural story, game, campaign, or product launch may benefit from visual surprise and exploration. An operational dashboard used throughout a workday usually needs more restraint. The right amount of expression depends on context, but expression is generally a safer place to be bold than navigation or error recovery.

The important distinction is that visual originality should support comprehension, not compete with it. Motion can show a relationship, reveal state, or guide attention. It can also delay access and make the user wait for the designer's performance to finish. Typography can establish a strong voice. It can also reduce readability. An unusual layout can create a memorable sequence. It can also hide the next action.

Novelty becomes useful when it clarifies the product's identity or content while leaving the interaction contract intact.

Familiarity Is Not the Same as Sameness

Following conventions does not require cloning competitors. A familiar pattern describes an expectation, not a finished appearance.

Consider a card. The convention is not a particular shadow, border radius, or color. The convention is that related information is grouped into a recognizable unit, often with a clear hierarchy and an action that belongs to that unit. A team can express that relationship through editorial spacing, a dense utility row, a bordered region, an image-led layout, or no visible container at all.

The same is true for navigation. Familiarity means users can identify where navigation is, understand the available destinations, perceive the current location, and operate it with the inputs they use. It does not require every site to share the same typography or visual composition.

This is where design systems are often misunderstood. A design system should not flatten every product into one visual template. It should stabilize the decisions that benefit from repetition so designers and developers can spend their attention on context. Tokens, accessible controls, interaction states, and semantic patterns create a dependable grammar. Products still decide what to say with it.

The goal is not sameness. The goal is transferable confidence.

When Novelty Earns Its Place

Novelty has the strongest case in four situations.

The Existing Pattern Cannot Express the Capability

Sometimes a product does something that familiar controls do not represent well. Forcing a new capability into an old metaphor can create more confusion than teaching a new pattern.

The test is whether the innovation changes the user's power, not merely the presentation. If a new interaction lets people see relationships, compare alternatives, automate a repeated task, or collaborate in a way the old pattern could not support, the learning cost may have a durable return.

Repetition Will Repay the Learning

An interaction used once must be immediately understandable. An interaction used dozens of times a day can justify a short learning curve if it becomes significantly faster or clearer with practice.

This is why expert tools can support shortcuts, direct manipulation, command palettes, and dense controls that would be inappropriate in a one-time consumer flow. The user has repeated opportunities to convert learning into fluency.

Frequency does not excuse a bad first experience. It changes the return calculation. The product still needs clear onboarding, visible feedback, and a path back to safety.

Exploration Is the Task

Some experiences are built to encourage discovery rather than rapid completion. Interactive storytelling, data exploration, creative tools, and games may use surprise as part of the value.

In those cases, a completely predictable sequence can work against the purpose. The interface should still communicate what is interactive, maintain keyboard and touch access, and protect the user from dead ends. Exploration is not a license to remove orientation.

The Pattern Creates Real Differentiation

A product may need a recognizable interaction of its own, especially when the workflow is central to its identity. The strongest signature interactions become shorthand for the product because they are useful first and distinctive second.

That order matters. If the only defense is "nobody else does it this way," the design has demonstrated difference, not value.

Where Familiarity Should Usually Win

Familiarity should dominate when the cost of error is high, the task is infrequent, the user is under pressure, or the interaction is only supporting infrastructure.

That includes:

authentication and account recovery
payments, checkout, and subscription changes
consent and privacy decisions
destructive operations
navigation and wayfinding
form completion and validation
accessibility controls
system status and error recovery

These are poor places to demand interpretation. A user who is trying to recover an account or understand a failed payment is not looking for a signature interaction. They need clarity, predictability, and a safe next step.

Familiarity should also win when novelty is being used to hide weak information architecture. A dramatic menu cannot repair unclear labels. Motion cannot compensate for missing hierarchy. A tutorial cannot permanently solve a control that does not explain itself.

If the design needs a paragraph of instruction before the first click, the problem may not be insufficient onboarding. The problem may be the interaction.

The FUSE Test

Before shipping an unfamiliar pattern, I use four questions. Together they form the FUSE test: Familiar anchor, User benefit, Safe failure, and Evidence.

A novel interaction should not ship on enthusiasm alone. Each part of FUSE reduces a different kind of risk.

Familiar Anchor

What does the user already know that gives them a foothold?

The anchor may be a recognizable object, label, spatial relationship, or sequence. A new canvas interaction might still use familiar selection handles, undo, zoom controls, and keyboard shortcuts. An AI workflow might still present a visible plan, explicit approval, progress status, and a reviewable result.

If nothing is familiar, the product is asking the user to learn the domain and the interface at the same time.

User Benefit

What durable value justifies the learning cost?

"It feels fresh" is not enough. The change should improve speed, comprehension, control, capability, or expression in a way that matters to the intended user. The benefit should still exist after the novelty wears off.

This is the question that protects a team from confusing attention with usefulness.

Safe Failure

What happens when the user's prediction is wrong?

Can they undo the action? Is lost work restored? Does the interface explain the result? Is there a conventional alternative? Does keyboard navigation reach the same outcome? Can a user leave the experiment without being trapped?

Unfamiliarity increases the chance of incorrect prediction. Recovery is part of the design, not a later edge case.

Evidence

What did people actually do?

Ask participants what they think will happen before they act. Watch for hesitation, repeated scanning, accidental activation, Back behavior, abandonment, and recovery. Compare completion time and error patterns against the conventional alternative. Test with people who did not sit through the design process.

The most revealing question is often not "Do you like it?" It is "What would you do next, and what do you expect to happen?"

Preference can reward visual novelty. Prediction reveals whether the interaction has become understandable.

A Practical Review for Design and Engineering Teams

The familiar-versus-novel decision should not live only in a design critique. It affects implementation, content, accessibility, analytics, and support.

Before committing to an unfamiliar pattern, I would ask the team to review it from five angles:

Product: What user problem requires a different interaction?
Design: Which existing mental model are we preserving, extending, or replacing?
Engineering: What additional state, feedback, fallback, and recovery does the new behavior require?
Accessibility: Can the same intent be perceived and operated through keyboard, touch, zoom, and assistive technology?
Research: What observation would cause us to revise or remove the pattern?

This review changes the conversation. Instead of debating whether a concept is exciting or boring, the team discusses where the interaction spends attention and what return it creates.

It also makes implementation more honest. Novel interactions are rarely just a front-end flourish. They create new states, new explanations, new failure modes, and new testing responsibilities. If the team is unwilling to fund those responsibilities, it has not funded the interaction.

The Familiar Core, Novel Edge Principle

The strongest balance I have found is a familiar core with a novel edge.

The familiar core helps people enter, navigate, understand state, perform common actions, and recover. The novel edge gives the product its particular advantage, expression, or way of working. It is noticeable because the rest of the interface is not competing for the same attention.

That balance is especially important as interfaces absorb AI-generated suggestions, autonomous actions, spatial tools, richer collaboration, and more adaptive behavior. New capability will require new patterns. It does not require us to discard every convention around those patterns.

An AI system can propose a new kind of plan while still using familiar approval controls. A design tool can introduce a new manipulation model while preserving undo and visible selection. A research experience can invite exploration while keeping location, progress, and exit clear.

Innovation works better when users have somewhere stable to stand.

Final Takeaway

Familiarity is not the enemy of creativity. It is the infrastructure that lets creativity matter.

Use conventions for the parts of an interface that should disappear into competence. Use novelty where the product creates a capability, expression, or experience worth learning. Separate visual originality from behavioral change. Protect high-risk tasks with predictable controls. Give unfamiliar patterns a familiar anchor, a durable benefit, safe recovery, and evidence.

The goal is not to make every interface feel like everything that came before it. The goal is to avoid charging users for differences that do not improve their experience.

Borrow the instincts people already have. Invent where the product has earned it.

References

Budiu, R. (2024, January 15). Memory recognition and recall in user interfaces. Nielsen Norman Group.

Chan, M. (2024, January 26). Mental models and user experience design. Nielsen Norman Group.

Budiu, R. (2016, October 30). The power law of learning: Consistency vs. innovation in user interfaces. Nielsen Norman Group.

World Wide Web Consortium. (n.d.). Understanding Success Criterion 3.2.3: Consistent navigation. Web Accessibility Initiative.

Zajonc, R. B. (1968). Attitudinal effects of mere exposure. Journal of Personality and Social Psychology, 9(2, Pt. 2), 1-27.

FAQ

What is the difference between familiar and novel interface design?

Familiar interface design uses patterns people already recognize, which lowers learning and prediction costs. Novel interface design introduces a new visual, structural, or behavioral pattern. Novelty is most defensible when it enables a capability or experience that familiar patterns cannot express as well.

What is a novelty budget in UI/UX design?

A novelty budget is my way of treating unfamiliarity as a limited product resource. Every new interaction asks users to spend attention and learning effort. A team should reserve that cost for the parts of the product that create durable value and keep commodity tasks predictable.

When should a designer break a familiar UI convention?

Break a convention when the existing pattern cannot support the product's core capability, repeated use will repay the learning cost, exploration is part of the task, or the new pattern creates useful differentiation. The change should still include clear feedback, recovery, accessibility, and evidence from user behavior.

Does following conventions make every product look the same?

No. Conventions define expectations about meaning and behavior, not a single visual style. Typography, composition, motion, imagery, pacing, and brand voice can create a distinct experience while navigation, forms, and recovery remain familiar.

How can teams test an unfamiliar interaction?

Ask users what they expect before they act, then observe hesitation, errors, recovery, abandonment, and repeated use. Compare the unfamiliar pattern with a conventional alternative. The FUSE test adds four gates: a familiar anchor, a meaningful user benefit, safe failure, and evidence.

Full Sail, Finished: We Did It

Ryan VerWey — Sat, 29 Aug 2026 14:31:14 +0000

Originally published on ryanverwey.dev.

Full Sail University's Web Development Bachelor of Science program changed how I build by forcing me to connect software decisions to product outcomes. It was not only a sequence of classes about HTML, CSS, JavaScript, APIs, databases, security, and deployment. It was a long pressure test of whether I could keep improving the way I plan, ship, explain, and maintain real web projects.

I completed the Web Development Bachelor of Science degree at Full Sail University in July 2026. Along the way, I was named Valedictorian for the Web Development Degree Program, received Full Sail's Advanced Achievement Award, earned four Course Director's Awards, and was recognized by the National Society of Collegiate Scholars for scholarship, leadership, and service.

Those distinctions matter to me, but not because they make the work complete by themselves. They matter because they reflect the same thing I was trying to build throughout the program: consistent execution, clear thinking, and the ability to turn a requirement into something real.

What I Earned

The final academic outcome was straightforward:

Bachelor of Science in Web Development from Full Sail University, awarded July 31, 2026.
Valedictorian, Web Development Degree Program.
Advanced Achievement Award, Web Development Degree Program.
Course Director's Award for Server-Side Languages.
Course Director's Award for Project and Portfolio III: Web Development.
Course Director's Award for Project and Portfolio IV: Web Development.
Course Director's Award for Project and Portfolio V: Web Development.
National Society of Collegiate Scholars recognition for scholarship, leadership, and service, presented November 2, 2024.

The degree represents completion of the program. Valedictorian represents academic standing. The Advanced Achievement Award means more to me because it is broader than grades. Full Sail describes it as a graduating-class distinction tied to overall effort, dedication, energy, sacrifice, skill, leadership, and program-wide performance.

The Course Director's Awards sit somewhere different. They are course-level recognition, and I am proud of where they landed. Server-Side Languages validated the backend work that helped push me from frontend implementation into application architecture. Project and Portfolio III, IV, and V validated the larger pattern I was trying to build: take what the program teaches, apply it under deadline pressure, and produce portfolio-grade work that can be explained after the assignment is over.

I do not see any of these as participation awards. I see them as evidence that I showed up consistently, took the work seriously, and improved in ways that were visible to the instructors evaluating the work.

Degree and Award Images

The images below are the degree and award records behind the academic honors referenced in this reflection.

<img src="/images/blog/full-sail-bachelor-degree.webp" alt="Full Sail University Bachelor of Science degree awarded to Ryan VerWey for the Web Development Degree Program">
<figcaption>
  Bachelor of Science, Web Development Degree Program
</figcaption>



<img src="/images/blog/full-sail-valedictorian-award.webp" alt="Full Sail University Valedictorian certificate awarded to Ryan VerWey for the Web Development Degree Program">
<figcaption>
  Valedictorian, Web Development Degree Program
</figcaption>



<img src="/images/blog/full-sail-advanced-achievement-award.webp" alt="Full Sail University Advanced Achievement Award certificate awarded to Ryan VerWey for the Web Development Degree Program">
<figcaption>
  Advanced Achievement Award, Web Development Degree Program
</figcaption>



<img src="/images/blog/full-sail-course-director-server-side-languages.webp" alt="Full Sail University Course Director's Award certificate awarded to Ryan VerWey for Server-Side Languages">
<figcaption>
  Course Director's Award, Server-Side Languages
</figcaption>



<img src="/images/blog/full-sail-course-director-project-portfolio-3.webp" alt="Full Sail University Course Director's Award certificate awarded to Ryan VerWey for Project and Portfolio III Web Development">
<figcaption>
  Course Director's Award, Project and Portfolio III
</figcaption>



<img src="/images/blog/full-sail-course-director-project-portfolio-4.webp" alt="Full Sail University Course Director's Award certificate awarded to Ryan VerWey for Project and Portfolio IV Web Development">
<figcaption>
  Course Director's Award, Project and Portfolio IV
</figcaption>



<img src="/images/blog/full-sail-course-director-project-portfolio-5.webp" alt="Full Sail University Course Director's Award certificate awarded to Ryan VerWey for Project and Portfolio V Web Development">
<figcaption>
  Course Director's Award, Project and Portfolio V
</figcaption>



<img src="/images/blog/full-sail-nscs-scholarship-leadership-service.webp" alt="National Society of Collegiate Scholars recognition for Ryan VerWey for scholarship leadership and service at Full Sail University">
<figcaption>
  National Society of Collegiate Scholars recognition
</figcaption>

The Program Was Not Just About Learning Syntax

It is easy to describe a web development degree as a list of technologies. That would be accurate, but incomplete.

The program did cover technical fundamentals. I worked through HTML structure, CSS layout, JavaScript logic, interface design, application state, backend routes, database models, authentication, deployment, testing, content management, security, and project delivery. Those topics matter. A web developer needs technical range.

But the more valuable shift was how those topics started connecting.

An interface is not separate from data modeling. A database decision affects the forms people use. Authentication affects the way a page should explain itself. Search engine optimization affects headings, routing, metadata, and content structure. Security affects input handling, deployment, secrets, and user trust. A portfolio is not just a gallery. It is a product surface that has to be usable, discoverable, credible, and maintainable.

That was the real growth for me. I stopped seeing web development as a collection of isolated skills and started seeing it as a system of tradeoffs.

Coming Into the Program With Real-World Pressure

I did not experience Full Sail in a vacuum.

I was already bringing a professional background into the program: military experience, geospatial intelligence work, contractor work, business ownership, team coordination, and the kind of operational habits that come from needing work to survive contact with real requirements. That background made the degree feel different.

When a course asked for a user interface, I was thinking about whether a user could actually make a decision from it. When a course asked for backend logic, I was thinking about where the data came from, who trusted it, and what would happen if it failed. When a course asked for a deployment, I was thinking about environment variables, hosting behavior, search visibility, and whether I could repeat the process later.

That professional context made school more valuable, not less. The assignments gave structure to things I had already started caring about. They forced me to slow down, name the decisions, and build a cleaner technical foundation underneath instincts I had picked up through work.

Full Sail did not erase what I already knew. It gave me a more disciplined way to express it as web development.

The Personal Cost Was Real

The clean version of this story is easy to write: I earned the degree, finished with honors, built a stronger portfolio, and moved into a clearer developer path.

That version is true, but it is not the whole truth.

For most of the program, I was not just a student. I was working at least two jobs, raising children, trying to keep my household moving, and still carving out enough focus to finish assignments at a standard I could be proud of. There were plenty of weeks where school did not fit neatly into life. It had to be wedged into late nights, early mornings, lunch breaks, weekends, and whatever quiet space I could find between work and family responsibilities.

That kind of pace takes a toll. It cost time. It cost rest. It cost energy I did not always have. At points, it cost pieces of my personal health because I kept choosing the long-term goal over short-term comfort. I do not want to romanticize that. Sacrifice sounds cleaner after the fact than it feels while you are living through it.

There were days when the work felt heavier than the assignment in front of me. A project deadline was not just a project deadline. It was stacked on top of work pressure, parenting, finances, fatigue, and the constant mental load of trying not to drop anything important. Finishing the degree required more than technical ability. It required endurance.

That is part of why the awards matter to me. They are not only academic decorations. They represent a period where I kept showing up while carrying a lot at once. They represent nights where I could have done the minimum and chose to push for better. They represent the discipline it took to build a new professional direction without being able to pause the rest of life.

In the end, it was worth it because the program gave me more than a credential. It gave me the start of a new life and a real career path as a developer. It gave shape to work I already cared about. It gave me a portfolio, a stronger technical foundation, a clearer professional identity, and proof that I could keep building even when the circumstances were not easy.

That is the part I will remember most.

Graduation Day

Graduation day made the sacrifice feel visible. The degree was mine, but getting there was never only an individual effort. My family lived through the long schedule with me: the work hours, the school deadlines, the late nights, the stress, and the constant balancing act it took to keep everything moving.

That picture matters because it shows what the program was really attached to. It was not just a career move on paper. It was a decision to build a different future while still being present for the people depending on me. That made the process harder, but it also made the outcome mean more.

The Early Courses Built the Mental Model

The first stretch of the program mattered because it established the mental model underneath everything else.

Introduction to Web Architecture made the browser feel less like a black box. HTML and CSS became structural tools instead of files that happened to make a page appear. Interfaces and Usability pushed that further by making design feel less subjective. Layout, hierarchy, spacing, contrast, and responsive behavior became part of how a product communicates.

The early JavaScript courses were where logic became more practical. Conditionals, loops, arrays, objects, functions, and classes are easy to describe academically. They become more meaningful when they start controlling actual behavior in the browser. The program gave me repetition there, and repetition matters. You do not become useful with JavaScript by watching someone else explain it. You become useful by writing it, breaking it, debugging it, and understanding why it broke.

Those early courses did not produce my most advanced projects, but they made the later projects possible. They built the habits that make larger systems easier to reason about.

The Portfolio Courses Changed the Standard

The Project and Portfolio courses were the backbone of the program for me.

Those courses changed the standard from "complete the assignment" to "produce something you can stand behind." That distinction matters. A normal class assignment can disappear after grading. A portfolio project has to explain what you can do.

Project and Portfolio I helped pull the early fundamentals together. Project and Portfolio II pushed deeper into React, API integration, data, and application behavior. Project and Portfolio III was where a fuller application started to emerge through authentication, profiles, blog features, project boards, and sprint planning.

Project and Portfolio IV raised the bar again by requiring more serious attention to access control, audit trails, cloud services, deployment, discovery, and postmortem work. Project and Portfolio V and Project and Portfolio VI became the launch path for Our Heritage Kitchen, moving it from product idea to beta planning, launch planning, search engine optimization, analytics, maintenance documentation, and handoff.

That sequence changed my expectations for my own work. By the end, I was not satisfied with a demo that technically loaded. I wanted clean user flows, readable content, meaningful metadata, deployment clarity, version history, maintainable structure, and enough written context that another person could understand what I built without a private walkthrough.

That mindset now shows up across my project portfolio, especially in the way I present live products, case details, technical stacks, and business context.

Backend Work Made Me Think in Systems

The backend courses were important because they moved me past interface-only thinking.

Server-Side Languages was one of the courses that stuck with me most. It helped make API design, routing, testing, MongoDB, Docker, and Node.js feel like part of ordinary product development. That Course Director's Award meant a lot because it marked a point where backend work was no longer just something sitting behind the interface. It became a core part of how I thought about building.

Advanced Server-Side Languages expanded that by pushing cleaner API architecture, TypeScript patterns, Express structure, WebSockets, and better service thinking. Database Systems added another layer by making persistence, backups, permissions, and database operations more explicit.

The practical lesson was simple: full-stack development is not frontend plus backend as separate piles of work. It is the ability to design the boundary between them.

That boundary affects performance, validation, security, user experience, analytics, and maintainability. It affects how clearly a feature can be tested. It affects whether the next developer can understand what the system is doing. It affects whether the user sees a coherent product or a collection of technical compromises.

Those courses strengthened the systems side of my work, and I still feel that influence when building tools, dashboards, design systems, and business-facing applications.

Security Changed How I Look at Ordinary Code

The security-related coursework helped me become more skeptical in a useful way.

Application Integration and Security introduced security pressure in a broader application context. Secure Application Development made it more direct: browser trust, cross-site request forgery, command injection, secrets management, JSON Web Tokens, deployment risk, and the responsibilities that continue after code leaves the local machine.

I do not market myself as a dedicated cybersecurity specialist. That is not the point. The point is that a full-stack developer cannot treat security as someone else's future cleanup task. The developer is often the person deciding how input is handled, where secrets live, how authentication works, how routes change data, how tokens move, and how deployment environments are configured.

That course changed the way I look at normal development decisions. When I see a request parameter, I think about validation. When I see a key or token, I think about storage and rotation. When I see a form that changes state, I think about intent. When I see a production deployment, I think about what the system is trusting.

That is not glamorous, but it is professional.

Content, Discovery, and Presentation Became Part of the Work

One of the more useful lessons from the later program was that software does not speak for itself.

Developers sometimes want the code to be enough. It rarely is. A project needs to be explained. It needs a purpose, an audience, a clear interface, useful metadata, and enough documentation that someone can evaluate it quickly.

That lesson has shaped this portfolio heavily. I care about search engine optimization, answer engine optimization, generative engine optimization, structured content, internal links, evidence, page hierarchy, and readable project summaries because discoverability is part of the work. If a recruiter, business owner, hiring manager, or AI search system cannot understand what a project demonstrates, then the project is not doing its job as a portfolio artifact.

My Full Sail retrospectives became part of that process. Each article helped package a piece of the program into something searchable and explainable. The goal was not to turn schoolwork into filler content. The goal was to document growth in a way that connects coursework to real capability.

That is why the Full Sail University learning journal exists. It gives the program a narrative arc instead of leaving it as a line item on a resume.

The Work Started Turning Into Real Products

By the end of the program, the work was not confined to class deliverables.

I was building and improving my own portfolio as a living system. I was building project pages that explain technical choices instead of just showing screenshots. I was writing articles that package decisions, constraints, and lessons learned. I was building tools through Echo Effect, experimenting with AI-assisted portfolio discovery, and turning design system work into something reusable.

That matters because professional growth is not only measured by the complexity of the code. It is measured by whether the code becomes useful.

Our Heritage Kitchen became a full product case study. CorvaUI became a design system direction with documentation and framework demos. Optimize became a website audit product focused on search, answer engine optimization, generative engine optimization, crawler access, accessibility, and prioritized repair planning. Rupert became a grounded AI assistant for helping visitors understand my portfolio. These projects are not all the same kind of work, but they share the same pattern: interface, logic, content, data, deployment, and communication all have to support the same outcome.

That is what Full Sail helped reinforce. Build the thing, but also make it understandable. Make it work, but also make it maintainable. Finish the assignment, but turn the learning into a reusable professional asset.

What Valedictorian Means to Me

Valedictorian is easy to explain from the outside: highest academic standing in the program.

From the inside, it feels more personal than that. It represents consistency. It means I kept the work moving across a long program while also carrying real life, real professional pressure, and a growing set of projects outside the classroom.

I am proud of the academic result, but I am more proud of the pattern behind it. Showing up every week matters. Reading the requirements carefully matters. Asking whether the work is actually good matters. Taking feedback seriously matters. Revising things that technically pass but do not meet your own standard matters.

That is the part I want people to understand when they see the word Valedictorian on my profile. It is not just a grade-point detail. It is shorthand for sustained execution.

What the Advanced Achievement Award Means to Me

The Advanced Achievement Award means something different.

Valedictorian is academic. The Advanced Achievement Award is broader. It recognizes the kind of student Full Sail views as standing out across the graduating class through performance, effort, leadership, skill, sacrifice, and the overall way they moved through the program.

That matters because software work is rarely judged on one dimension. Good grades are valuable, but professional trust comes from more than grades. It comes from communication, ownership, judgment, follow-through, and the ability to keep making progress when a problem is messy.

That is why this award hit differently for me. It felt like recognition of the whole pattern, not just the transcript. The late nights, the rewrites, the overbuilt first drafts, the cleaner second drafts, the projects that had to be shipped, the feedback I had to absorb, and the effort to keep raising the bar all counted.

Receiving that award alongside Valedictorian and multiple Course Director's Awards made the end of the program feel complete in a way I did not expect.

Course Director's Awards Were Signals Along the Way

The four Course Director's Awards gave me mile markers.

Server-Side Languages showed that the backend side of the program had clicked. That course required more than making buttons respond. It required routes, requests, responses, data, tests, and a clearer understanding of how applications behave away from the browser.

Project and Portfolio III showed that I could pull multiple disciplines into a real full-stack project. It was not just a technical checkpoint. It was a delivery checkpoint.

Project and Portfolio IV showed that I could revise and mature a project through access control, audit trails, cloud services, deployment thinking, and postmortem reflection.

Project and Portfolio V showed that I could move a larger product idea toward beta with business viability, metrics, compliance, security posture, versioning, release planning, and a stronger sense of product ownership.

Those awards do not replace the work. They point back to it. They mark moments where the work was strong enough to stand out.

How Full Sail Contributed to My Professional Growth

The biggest professional change was not that I learned a few more frameworks.

The biggest change was that I became more deliberate.

I became more deliberate about requirements. I started reading the assignment, project brief, or business need as a product contract instead of a checklist. What does the user need to do? What does the system need to prove? What does the page need to communicate? What will be hard to maintain later?

I became more deliberate about interfaces. A component is not just a styled block. It is a decision about hierarchy, state, accessibility, responsiveness, and user confidence.

I became more deliberate about backend logic. An API is not just a route. It is a boundary where trust, validation, persistence, and errors have to be handled clearly.

I became more deliberate about deployment. A deployed application is not finished if the environment is fragile, the metadata is weak, the handoff is unclear, or nobody can tell what changed.

I became more deliberate about writing. The ability to explain technical work is part of the work. A project without context is harder to evaluate, harder to trust, and easier to misunderstand.

That is the professional growth I value most. Full Sail gave me structure, deadlines, repetition, feedback, and a progression that pushed those habits into place.

What I Would Tell Someone Starting the Program

If I were talking to someone starting the Full Sail Web Development program, I would tell them not to treat the degree like a checklist.

The assignments matter, but the artifacts matter more. Every course can become something useful if you treat it as part of a larger portfolio. Write down what you learned. Keep the work. Improve it after the grade. Connect the course to a real project. Ask what the assignment is actually trying to teach, not just what needs to be submitted by Sunday night.

I would also tell them to build more than the minimum. Not recklessly, and not at the cost of missing requirements, but enough that the work becomes yours. The best learning I got from the program happened when I stopped asking "what is enough to pass?" and started asking "what would make this worth showing?"

That question changed everything.

What I Take Forward

I take forward a clearer identity as a developer.

I build full-stack products, design systems, AI-assisted tools, search-ready content, and business websites that need to work for real people. I care about interfaces, but I also care about the system behind them. I care about code, but I also care about whether the product can be found, understood, measured, and maintained.

Full Sail did not create that identity from nothing. It sharpened it. It gave me a structured path to prove it over and over again, course by course, project by project.

The final degree, Valedictorian honor, Advanced Achievement Award, Course Director's Awards, and National Society recognition are important because they document the outcome. But the more important result is practical: I left the program with a stronger standard for my own work.

That standard is what I am carrying forward.

A Few Acknowledgements

I owe Rachel more than a quick thank-you line can cover.

She carried the reality of this program with me, not just the idea of it. Every late night, every overloaded week, every deadline that landed on top of work and family life affected her too. She had to live with the schedule, the stress, the distracted evenings, the times I was physically home but mentally buried in code, documentation, deployments, or school requirements. Finishing this degree took effort from me, but it also took patience, grace, and sacrifice from her.

Rachel believed in the version of my life I was trying to build even when the day-to-day version of it was not clean or easy. She encouraged me when I was exhausted, gave me room when I needed to focus, and kept standing beside me through a process that asked a lot from our family. This degree is part of my professional story, but she is part of why I was able to finish it.

To Trinity and Alex, I hope one day this makes sense in a way that goes beyond seeing Dad on a laptop all the time.

There were nights, weekends, and ordinary family moments where school had to take space. I know that mattered. I know there were times when I had to ask for quiet, steal time, or push through one more assignment instead of being as present as I wanted to be. That is one of the hardest parts to write honestly because the goal was always for our family, but the work sometimes pulled me away from the very people I was doing it for.

I hope what you take from this is not that work should consume your life. I hope you see that hard things can be finished, that starting over professionally is possible, and that building a better future sometimes requires a season of sacrifice. I wanted you to see me finish. I wanted you to see that learning does not stop when you become an adult, a parent, or a provider. I wanted you to have proof that persistence can turn into something real.

To my friends and family, thank you for the encouragement, the check-ins, the patience, and the belief.

Support does not always look dramatic from the outside. Sometimes it is a message at the right time, a conversation that helps you reset, someone listening while you are frustrated, or someone reminding you that the work is worth finishing. Those moments mattered more than I probably said while I was in the middle of it. When life was crowded and the finish line still felt far away, encouragement helped keep the goal visible.

I also want to thank my Full Sail instructors for the mentorship, feedback, pressure, and structure they brought into the program.

The best instructors did more than grade submissions. They made the work feel connected to a professional standard. They pushed clarity. They rewarded effort, but they also expected execution. They treated projects like opportunities to think harder, communicate better, and build with more intent. Their feedback helped me see where an assignment could become a stronger product, where a technical choice needed a better explanation, and where "working" was not the same thing as being finished.

That mentorship mattered. It helped me turn coursework into portfolio work, portfolio work into professional direction, and professional direction into a stronger sense of what I want to build next.

FAQ

What degree did Ryan VerWey earn from Full Sail University?

I earned a Bachelor of Science in Web Development from Full Sail University. The degree was awarded on July 31, 2026.

What academic honors did Ryan VerWey receive at Full Sail University?

I was named Valedictorian for the Web Development Degree Program, received the Advanced Achievement Award, and earned Course Director's Awards in Server-Side Languages, Project and Portfolio III: Web Development, Project and Portfolio IV: Web Development, and Project and Portfolio V: Web Development.

What is Full Sail's Advanced Achievement Award?

The Advanced Achievement Award is a graduating-class distinction that recognizes a standout student across the full program. It is broader than grade-point average alone and reflects effort, dedication, energy, sacrifice, skill, leadership, and overall program performance.

What is a Course Director's Award at Full Sail University?

A Course Director's Award is course-level recognition from Full Sail faculty for standout performance in a specific course. In my case, those awards came from Server-Side Languages and three Project and Portfolio courses.

How did Full Sail contribute to Ryan VerWey's professional growth?

Full Sail helped connect technical skills to professional delivery. The program strengthened my work across frontend interfaces, backend logic, databases, security, deployment, testing, documentation, product planning, portfolio presentation, and search-ready content.

How does this reflection connect to the rest of Ryan VerWey's portfolio?

This reflection connects the Full Sail program to the broader portfolio. The course retrospectives live in my Full Sail learning journal, and the applied project work is collected on my projects page.

Turning GitHub Language Stats Into a Profile Snapshot

Ryan VerWey — Tue, 25 Aug 2026 14:44:39 +0000

Originally published on ryanverwey.dev.

I built profile-language-metrics as a reusable GitHub Action that generates a clean language snapshot for a GitHub profile README. It is written in Python, runs on GitHub Actions, scans active repositories, estimates non-empty source lines by language, and writes a polished SVG that can be embedded directly into a profile page.

The short version: it is a vanity metric, but it is an honest one. It does not pretend to measure engineering value, productivity, or skill level by itself. It gives developers a lightweight way to show the shape of their public work, and it gives me another practical Python automation project that solves a real presentation problem.

Why I Built It

GitHub profile READMEs are weirdly useful.

They are part portfolio, part landing page, part proof-of-work surface. A good profile does not need to be loud, but it should give someone a fast read on what you build, what tools you use, and whether your work is active.

The problem is that most profile widgets either depend on a third-party service, show generic GitHub stats that everyone has already seen, or turn into visual noise. I wanted something smaller and more specific:

a card that shows the language mix across my repos
a scheduled workflow that keeps it updated
no hosted dashboard
no package install step
no private repository names exposed
a result that looks good embedded in Markdown

That made Python the right tool for the job. The project needed file walking, API calls, subprocess control, counters, text escaping, and SVG generation. None of that required a framework. It needed boring reliability more than a big dependency tree.

What the Action Generates

The current public run against my GitHub profile found 40,292 estimated non-empty source lines across 17 public active repositories. Python shows up with 3,171 lines in that snapshot, alongside TypeScript, JavaScript, CSS, HTML, Astro, Svelte, Vue, YAML, MDX, Shell, Batchfile, and TOML.

The output is intentionally simple: one SVG card with a total line count, active repository count, stacked language distribution, and per-language rows. It is built for a README, not a business intelligence dashboard.

That distinction matters. Line counts can be useful context, but they are not proof of seniority or quality. The value here is presentation: it turns scattered repository activity into a compact snapshot someone can understand in a few seconds.

How It Works

The action follows a predictable pipeline:

Fetch eligible repositories from the GitHub API.
Create a temporary, shallow, read-only checkout of each active repository inside the GitHub Actions runner.
Walk source files and map extensions to languages.
Count non-empty source lines.
Render the aggregated result into an SVG.
Let the profile workflow commit the generated file.

That clone step deserves plain-English context. The action is not sending your repository to a third-party server, creating a permanent mirror, or changing your project files. It runs inside your own GitHub Actions job, performs a depth-1 checkout in a temporary runner workspace, reads the files for counting, and lets that workspace disappear when the job finishes. The only file the example workflow writes back is the generated assets/language-metrics.svg in the profile repository where you installed the action.

The repo filtering is as important as the counting. The action skips forks, archived repos, disabled repos, profile repos, dependency folders, build output, lockfiles, minified files, and binaries. Without those exclusions, the output gets polluted fast.

The counting logic is deliberately conservative. It estimates non-empty source lines in recognized source files. It does not try to parse abstract syntax trees, classify generated code perfectly, or become a compliance-grade code inventory tool.

That restraint is part of the design. For a profile README, I would rather have a clear, repeatable estimate than a complex analysis system that feels more official than it really is.

Why Python Was the Right Fit

This is the kind of Python I like writing: practical automation that sits between services, files, and developer workflow.

The script has to do several jobs cleanly:

call GitHub's API with optional authentication
handle public-only and private-inclusive modes
create temporary repository checkouts without mutating source repositories or leaking private paths into logs
skip binary and generated files
count text safely with encoding fallbacks
aggregate language totals with Counter
escape SVG text correctly
write an output file that works in GitHub Markdown

The implementation stays dependency-free. It uses Python's standard library plus Git on the runner. That makes the action easier to trust because the user does not have to wait on npm install, audit a package tree, or wonder why a profile utility needs a heavy runtime.

Here is the kind of workflow a user can drop into a profile repository:

name: Generate language metrics

on:
  workflow_dispatch:
  schedule:
    - cron: "37 8 * * 1"

permissions:
  contents: write

jobs:
  generate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: RyanVerWey/profile-language-metrics@v1
        with:
          github_user_name: ${{ github.repository_owner }}
          output_path: assets/language-metrics.svg

That is the user experience I wanted: configure it once, run it manually when you want the first image, then let the scheduled workflow keep it current.

The Privacy Model

Private repository support needed a clear boundary.

The action can include private repositories when the caller supplies a token with the right access, but the generated SVG only shows aggregate totals. It does not write private repository names, URLs, or per-repo breakdowns into the image.

That tradeoff is intentional. A developer might want their private work represented in the overall language mix, but a profile README is still public. Aggregates are useful. Private project disclosure is not.

I also suppress clone command output when a token is present and disable Git Large File Storage smudge during clone. That keeps logs cleaner and avoids pulling large private assets that do not belong in a lightweight metrics run.

What This Shows About My Python Work

This project is not Python for Python's sake. It is Python used where Python makes the product simpler.

The code has to be comfortable with API boundaries, local file systems, subprocesses, temporary workspaces, string rendering, escaping, and operational edge cases. It also has to be packaged so another developer can use it without reading the entire implementation first.

That is the part I care about most: turning a script into a reusable tool.

A one-off script would have been easy. A release needs more discipline:

clear inputs
documented outputs
safe defaults
exclusion rules
read-only private token guidance
a license
attribution notes
a README that gets someone from zero to embedded SVG

That is the difference between "I wrote some Python" and "I shipped a Python-based developer tool people can use."

What I Would Improve Next

The release is useful now, but there are a few improvements I would consider:

adding more language extensions as edge cases appear
improving the stacked bar renderer for very small language segments
offering a compact card variant for narrower profile layouts
adding a JSON output for people who want to build their own visualization
documenting a few example profile README layouts

I would still keep the core small. This kind of project gets worse if it tries to become a full analytics platform. The point is a clean profile snapshot, not an enterprise code intelligence system.

Try It

The project is public here: RyanVerWey/profile-language-metrics. If you like the release or end up using it in your own profile README, star the repo. That signal helps the project reach other developers who want a clean GitHub vanity snapshot without depending on a hosted badge service.

If you want a profile README card that shows your language mix without relying on a hosted badge service, add the action to your profile repository and let GitHub Actions commit the SVG. It is small, readable, MIT licensed, and built to be easy to understand.

For more context on the kind of developer work I build and publish, see my projects and about page.

FAQ

What is profile-language-metrics?

profile-language-metrics is a reusable GitHub Action that generates a profile-ready SVG showing aggregate source-line estimates by programming language across active repositories.

Is this a serious engineering metric?

No. It is a useful profile visualization, not a measurement of engineering quality, productivity, or business impact.

Why did you build it in Python?

Python fit the job: API requests, file walking, subprocess calls, counters, text escaping, and SVG rendering without pulling in a package install step.

Can it include private repositories?

Yes, if the caller supplies a token with access. Private repositories are shown only as aggregate totals, not as names, URLs, or per-repository details.

Who should use it?

Developers who want a clean GitHub profile README language snapshot that updates on a schedule and stays under their own repository control.

Publish First, Syndicate Later: Automating Dev.to Without Losing SEO Credit

Ryan VerWey — Fri, 21 Aug 2026 14:43:05 +0000

Originally published on ryanverwey.dev.

If you publish articles on a Next.js portfolio or agency website, Dev.to can be a useful syndication channel. You get distribution in a developer community, another place for people to discover your work, and a canonical backlink pointing to the original article on your own domain.

The important part is order.

Publish on your website first. Give search engines time to crawl your original page. Then publish the Dev.to copy with a canonical URL that points back to your site. That is how you use syndication for reach without teaching Google that the copy is the source of truth.

This guide walks through a practical setup: a Next.js blog, an RSS feed or local Markdown files, a Dev.to API key stored as a GitHub secret, a daily GitHub Actions workflow, and a script that waits three days before posting.

Short answer: Publish the original post on your own domain, wait three days, then post the Dev.to copy with canonical_url set to your original URL. Include the cover image, convert body images to absolute URLs, and send no more than four Dev.to tags.

Why Syndicate to Dev.to at All?

Your portfolio blog is the source of truth. That is where you own the domain, the analytics, the internal links, the service pages, the calls to action, and the long-term SEO value.

Dev.to is different. It is a discovery channel.

When you syndicate correctly, Dev.to can help with:

Getting technical articles in front of readers who may never find your personal site first.
Creating a clean attribution path from a high-authority community platform back to your original post.
Building repeatable distribution without manually copying every article.
Keeping your writing workflow centered on your own website, not on rented platforms.

The danger is duplicate content confusion. If the same article appears on your site and on Dev.to at the same time, Google has to decide which URL represents the original. Google recommends using canonical links in the HTML head and using absolute URLs for canonical annotations. DEV also documents a canonical URL field for imported or manually created posts, specifically so the original source can keep SEO credit.

That is why the delay matters.

What the Three-Day Delay Does

A three-day delay is not a magic ranking switch. It is a practical buffer.

When a new article goes live on your portfolio, you want search engines to see your domain first. The delay gives you time to:

Deploy the post.
Confirm the article URL returns 200.
Confirm the canonical tag on your site points to itself.
Let your sitemap, RSS feed, and internal links expose the original before Dev.to sees the copy.

After that delay, the Dev.to version should point back to the original with canonical_url.

Think of the Dev.to article as a syndicated copy with a signpost. The signpost says, "This is useful here, but the original lives over there."

For high-priority posts, you can also request indexing in Google Search Console. Treat that as an acceleration option, not as a required step in the recurring automation.

What You Are Building

The automation has six parts:

A Next.js blog source, usually Markdown or MDX files.
A canonical URL for every article on your own domain.
An RSS feed or script that can read each article's title, summary, body, date, image, and tags.
A Dev.to API key stored outside your repo.
A sync script that publishes only eligible posts.
A scheduled GitHub Actions workflow that runs daily.

The workflow should do this every time it runs:

Read all local blog posts.
Skip posts newer than three days.
Build the original URL from the post slug.
Check Dev.to for an existing article with that canonical URL.
Convert MDX or HTML-only content into Dev.to-friendly Markdown.
Make images absolute so they work away from your website.
Send up to four relevant Dev.to tags.
Create the Dev.to article with canonical_url.

Step 1: Confirm Your Next.js Blog Has Stable Slugs

Most Next.js portfolio blogs use one file per post:

content/blog/my-article-slug.mdx
content/blog/another-article.mdx

The filename becomes the URL:

https://www.yourdomain.com/blog/my-article-slug

Before you automate anything, make that contract reliable. Your script needs one predictable way to turn a file into a URL.

For example:

const SITE_URL = 'https://www.yourdomain.com'
const slug = fileName.replace(/\.mdx?$/, '')
const canonicalUrl = `${SITE_URL}/blog/${slug}`

Do not use localhost URLs, preview deployment URLs, random query strings, or relative canonical paths. The canonical URL should be the final public article URL.

Step 2: Add Self-Referential Canonical Tags on Your Site

Every original article should include a canonical tag in the HTML head that points to itself:

<link rel="canonical" href="https://www.yourdomain.com/blog/my-article-slug" />

In the Next.js App Router, this usually belongs in generateMetadata:

import type { Metadata } from 'next'

type PageProps = {
  params: Promise<{ slug: string }>
}

export async function generateMetadata({ params }: PageProps): Promise<Metadata> {
  const { slug } = await params
  const post = getBlogPost(slug)
  const canonical = `https://www.yourdomain.com/blog/${slug}`

  return {
    title: post.title,
    description: post.summary,
    alternates: {
      canonical,
    },
    openGraph: {
      title: post.title,
      description: post.summary,
      url: canonical,
      type: 'article',
      images: [
        {
          url: post.banner,
          width: 1200,
          height: 630,
          alt: post.title,
        },
      ],
    },
    twitter: {
      card: 'summary_large_image',
      title: post.title,
      description: post.summary,
      images: [post.banner],
    },
  }
}

Why this matters: your own page should clearly say, "I am the canonical version." The Dev.to copy will later say the same thing from the other direction.

Step 3: Make Your Blog Frontmatter Syndication-Ready

Each post needs enough metadata to become a Dev.to article without manual cleanup.

Use a frontmatter shape like this:

---
title: "How to Improve Your Portfolio Website"
date: "2026-08-18"
summary: "A practical guide to improving a portfolio website with better structure, speed, images, and calls to action."
tags: ["Next.js", "SEO", "Portfolio", "Web Development"]
category: ["Web Development"]
banner: "/images/blog/example-cover.webp"
updatedTime: "2026-08-18"
---

The key fields for Dev.to are:

Field	Why It Matters
`title`	Becomes the Dev.to article title.
`summary`	Becomes the Dev.to description.
`date`	Controls the three-day delay.
`banner`	Becomes the Dev.to `main_image`.
`tags`	Becomes Dev.to topic tags.

Use a public image for banner. Dev.to is not reading your site from the same origin, so a local image path like /images/blog/cover.webp needs to be converted to https://www.yourdomain.com/images/blog/cover.webp before publishing.

Step 4: Decide How Images Should Travel

Images fail in syndication more often than text.

There are two image types to handle:

The article cover image.
Images inside the article body.

For the cover image, send Dev.to a public image URL:

main_image: absoluteUrl(post.banner)

For body images, convert local paths to absolute URLs before publishing:

function makeImageUrlsAbsolute(markdown, siteUrl) {
  return markdown.replace(/!\\[([^\\]]*)\\]\\((\\/[^)]+)\\)/g, (_, alt, src) => {
    return `![${alt}](${siteUrl}${src})`
  })
}

If your posts use custom MDX components like this:

<BlogImage
  src="/images/blog/example.webp"
  alt="Dashboard on a laptop"
  caption="Use real images that explain the article."
/>

Convert them before sending to Dev.to:

function convertBlogImages(markdown, siteUrl) {
  return markdown.replace(/<BlogImage\\s+([^>]*?)\\s*\\/>/gs, (_, attrs) => {
    const src = attrs.match(/src=["']([^"']+)["']/)?.[1]
    const alt = attrs.match(/alt=["']([^"']*)["']/)?.[1] ?? ''
    const caption = attrs.match(/caption=["']([^"']*)["']/)?.[1]

    if (!src) return ''

    const imageUrl = src.startsWith('http') ? src : `${siteUrl}${src}`
    const image = `![${alt}](${imageUrl})`

    return caption ? `${image}\\n\\n*${caption}*` : image
  })
}

Why this matters: the Dev.to API accepts Markdown. It does not understand your custom React components. Convert the content before it leaves your site.

Step 5: Make Search Console Optional

The normal workflow should not depend on a person submitting every URL by hand. Your automation should rely on stable article URLs, self-referential canonicals, a sitemap, internal links, RSS discovery, and the three-day Dev.to delay.

For high-priority posts, request indexing for the original article as an optional acceleration step.

Click-by-click:

Open Google Search Console.
Select the property for your website.
Click the URL Inspection search bar at the top.
Paste the full original article URL.
Press Enter.
Wait for Google to inspect the URL.
If the page is live, click Request Indexing.
Wait for the confirmation message.
Let the automated Dev.to workflow handle normal syndication after the three-day delay.

This is not required for Dev.to automation to work. It is useful when a post is especially important, timely, or tied to a campaign. For routine posts, let the automated workflow run without a manual Search Console task.

Step 6: Create a Dev.to API Key

Do this from the Dev.to website:

Log in to Dev.to.
Click your profile image in the top-right corner.
Click Settings.
Click Extensions in the settings sidebar.
Scroll to DEV Community API Keys.
Type a short label, such as GitHub blog syndication.
Click Generate API Key.
Copy the key once.

Do not paste the key into your source code. Do not commit it to GitHub. Do not put it in a public blog post, screenshot, issue, pull request, or README.

The key belongs in your automation environment.

Step 7: Store the API Key as a GitHub Secret

If your portfolio is on GitHub, store the key as a repository secret:

Open your GitHub repository.
Click Settings.
In the left sidebar, click Secrets and variables.
Click Actions.
Click New repository secret.
Name the secret DEVTO_API_KEY.
Paste the Dev.to API key into the value field.
Click Add secret.

Your workflow will read it as:

env:
  DEVTO_API_KEY: ${{ secrets.DEVTO_API_KEY }}

That keeps the key out of your repo while still making it available to the scheduled job.

Step 8: Install the Packages Your Script Needs

For an MDX or Markdown blog, a small Node script can usually do the job.

Install:

npm install gray-matter

If you already have gray-matter, you can skip that. Node 18 and newer includes fetch, so you do not need a separate HTTP client in most modern Next.js projects.

Step 9: Add a Safe Tag Mapper

Dev.to tags should be short, lowercase, and relevant. Most posts should use no more than four.

Your website tags may be human-readable:

tags:
  - Web Development
  - SEO
  - Content Marketing

Dev.to tags should look more like:

['webdev', 'nextjs', 'seo', 'productivity']

Add a mapper:

const TAG_MAP = {
  'Web Development': 'webdev',
  SEO: 'seo',
  'Content Marketing': 'contentmarketing',
  'Web Design': 'webdesign',
  JavaScript: 'javascript',
  Nextjs: 'nextjs',
}

function normalizeDevToTags(tags) {
  const normalized = tags
    .map((tag) => TAG_MAP[tag] ?? tag)
    .map((tag) => tag.toLowerCase().replace(/[^a-z0-9]/g, ''))
    .filter(Boolean)

  return Array.from(new Set(normalized)).slice(0, 4)
}

Why this matters: tags are distribution channels on Dev.to. Bad tags make the article harder to discover, and too many tags can cause publishing problems. Keep the set focused.

Step 10: Write the Sync Script

Create a file like this:

scripts/publish-devto.mjs

Here is a complete generic version you can adapt:

import fs from 'node:fs/promises'
import path from 'node:path'
import matter from 'gray-matter'

const SITE_URL = process.env.SITE_URL ?? 'https://www.yourdomain.com'
const DEVTO_API_KEY = process.env.DEVTO_API_KEY
const BLOG_DIR = path.join(process.cwd(), 'content', 'blog')
const THREE_DAYS_MS = 3 * 24 * 60 * 60 * 1000

const TAG_MAP = {
  'Web Development': 'webdev',
  'Web Design': 'webdesign',
  SEO: 'seo',
  'Content Marketing': 'contentmarketing',
  JavaScript: 'javascript',
  Nextjs: 'nextjs',
}

if (!DEVTO_API_KEY) {
  throw new Error('Missing DEVTO_API_KEY.')
}

function postSlug(fileName) {
  return fileName.replace(/\.mdx?$/, '')
}

function canonicalForSlug(slug) {
  return `${SITE_URL}/blog/${slug}`
}

function absoluteUrl(url) {
  if (!url) return undefined
  if (url.startsWith('https://') || url.startsWith('http://')) return url
  return `${SITE_URL}${url.startsWith('/') ? url : `/${url}`}`
}

function normalizeDevToTags(tags = []) {
  const normalized = tags
    .map((tag) => TAG_MAP[tag] ?? tag)
    .map((tag) => String(tag).toLowerCase().replace(/[^a-z0-9]/g, ''))
    .filter(Boolean)

  return Array.from(new Set(normalized)).slice(0, 4)
}

function isAtLeastThreeDaysOld(date) {
  const publishedTime = new Date(date).getTime()
  if (Number.isNaN(publishedTime)) return false
  return Date.now() - publishedTime >= THREE_DAYS_MS
}

function convertBlogImages(markdown) {
  return markdown.replace(/<BlogImage\s+([^>]*?)\s*\/>/gs, (_, attrs) => {
    const src = attrs.match(/src=["']([^"']+)["']/)?.[1]
    const alt = attrs.match(/alt=["']([^"']*)["']/)?.[1] ?? ''
    const caption = attrs.match(/caption=["']([^"']*)["']/)?.[1]

    if (!src) return ''

    const image = `![${alt}](${absoluteUrl(src)})`
    return caption ? `${image}\n\n*${caption}*` : image
  })
}

function makeMarkdownPortable(markdown) {
  return convertBlogImages(markdown)
    .replace(/!\[([^\]]*)\]\((\/[^)]+)\)/g, (_, alt, src) => `![${alt}](${absoluteUrl(src)})`)
    .replace(/<Callout>\s*/g, '> ')
    .replace(/\s*<\/Callout>/g, '')
}

async function devToRequest(endpoint, options = {}) {
  const response = await fetch(`https://dev.to/api${endpoint}`, {
    ...options,
    headers: {
      'api-key': DEVTO_API_KEY,
      'content-type': 'application/json',
      ...(options.headers ?? {}),
    },
  })

  if (!response.ok) {
    const body = await response.text()
    throw new Error(`Dev.to request failed: ${response.status} ${body}`)
  }

  return response.json()
}

async function getExistingArticles() {
  const articles = []

  for (let page = 1; page <= 10; page += 1) {
    const batch = await devToRequest(`/articles/me/all?page=${page}&per_page=100`)
    articles.push(...batch)
    if (batch.length < 100) break
  }

  return articles
}

async function publishArticle({ post, body, canonicalUrl }) {
  return devToRequest('/articles', {
    method: 'POST',
    body: JSON.stringify({
      article: {
        title: post.title,
        description: post.summary,
        body_markdown: body,
        main_image: absoluteUrl(post.banner),
        canonical_url: canonicalUrl,
        tags: normalizeDevToTags(post.tags),
        published: true,
      },
    }),
  })
}

async function main() {
  const existingArticles = await getExistingArticles()
  const existingCanonicals = new Set(existingArticles.map((article) => article.canonical_url).filter(Boolean))
  const files = (await fs.readdir(BLOG_DIR)).filter((file) => /\.mdx?$/.test(file))

  for (const file of files) {
    const fullPath = path.join(BLOG_DIR, file)
    const slug = postSlug(file)
    const canonicalUrl = canonicalForSlug(slug)
    const source = await fs.readFile(fullPath, 'utf8')
    const { data, content } = matter(source)

    if (!isAtLeastThreeDaysOld(data.date)) {
      console.log(`Skipping ${slug}: younger than three days.`)
      continue
    }

    if (existingCanonicals.has(canonicalUrl)) {
      console.log(`Skipping ${slug}: already syndicated.`)
      continue
    }

    const attribution = `*Originally published on [your portfolio](${canonicalUrl}).*`
    const body = `${attribution}\n\n${makeMarkdownPortable(content)}`

    const article = await publishArticle({
      post: data,
      body,
      canonicalUrl,
    })

    console.log(`Published ${slug}: ${article.url}`)

    await new Promise((resolve) => setTimeout(resolve, 3500))
  }
}

main().catch((error) => {
  console.error(error)
  process.exit(1)
})

There are four important safety checks in that script:

It refuses to run without DEVTO_API_KEY.
It skips posts younger than three days.
It checks existing Dev.to posts by canonical_url.
It spaces out publish requests to avoid unnecessary API pressure.

Step 11: Add Package Scripts

Add scripts to package.json:

{
  "scripts": {
    "publish:devto": "node scripts/publish-devto.mjs",
    "publish:devto:dry-run": "node scripts/publish-devto.mjs --dry-run"
  }
}

If you want a safer first version, add a dry-run mode before allowing writes. A dry run should print what would be published without calling POST /articles.

For example:

npm run publish:devto:dry-run

The script should print skipped and published posts:

Skipping new-post: younger than three days.
Skipping old-post: already syndicated.
Published eligible-post: https://dev.to/username/eligible-post-slug

Step 12: Create the GitHub Actions Workflow

Create:

.github/workflows/devto-syndication.yml

Use a daily schedule plus a manual trigger:

name: Dev.to Syndication

on:
  schedule:
    - cron: '25 13 * * *'
  workflow_dispatch:

jobs:
  syndicate:
    runs-on: ubuntu-latest
    permissions:
      contents: read
    env:
      DEVTO_API_KEY: ${{ secrets.DEVTO_API_KEY }}
      SITE_URL: https://www.yourdomain.com
    steps:
      - name: Check out repository
        uses: actions/checkout@v4

      - name: Set up Node
        uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm

      - name: Install dependencies
        run: npm ci

      - name: Publish eligible posts to Dev.to
        run: npm run publish:devto

The cron time does not need to be exact. Pick a quiet time. The script controls eligibility, not the workflow schedule.

Why daily works: a post published Monday at noon becomes eligible Thursday at noon. The next daily run after that will post it.

Step 13: Test the Workflow Without Publishing

Before publishing anything, test locally with a dry run or a temporary logging-only script.

Check:

New posts are skipped.
Old posts are eligible.
Existing Dev.to posts are skipped.
Canonical URLs are absolute and correct.
Cover images are absolute.
Body images are absolute.
Tags are lowercase and limited to four.
No API key is printed in the logs.

Then run the GitHub Action manually:

Open your GitHub repository.
Click Actions.
Click Dev.to Syndication.
Click Run workflow.
Choose the branch.
Click Run workflow again.
Open the workflow run.
Watch the log output.

The logs should show skipped or published posts, but never the API key.

Step 14: Verify the Dev.to Article

After the first publish, open the Dev.to article and check it manually.

Confirm:

The title is correct.
The cover image appears.
Body images appear.
Code blocks are readable.
Tables still make sense.
The top attribution link points to the original post.
The Dev.to canonical URL points to the original post.
Tags are relevant and not spammy.

If you use the Dev.to editor, you can also check the canonical manually:

Open the Dev.to post.
Click Edit.
Open the post settings.
Find Canonical URL.
Confirm it matches your original article URL exactly.

In the basic Markdown editor, the same value may appear as frontmatter:

canonical_url: https://www.yourdomain.com/blog/my-article-slug

Step 15: Keep the Original URL Stable

Canonical syndication depends on stable URLs.

Avoid changing slugs after syndication. If you must change one:

Add a permanent redirect from the old URL to the new URL.
Update the Dev.to article's canonical_url.
Update the attribution link.
Re-submit the new original URL in Google Search Console.
Confirm the old URL does not return a broken page.

Broken canonical URLs waste the value of the whole setup. A canonical tag that points to a 404 is not helping the original article.

Step 16: Build a Post-Publish Checklist

Automation should reduce manual work, not remove responsibility.

Use this automation-first checklist for every new article:

[ ] Article is live on your own domain.
[ ] Original page returns 200.
[ ] Original page has a self-referential canonical URL.
[ ] Original page has a usable title and meta description.
[ ] Cover image is public and absolute.
[ ] Body images are public or convertible to absolute URLs.
[ ] Three days have passed.
[ ] Dev.to copy includes canonical_url.
[ ] Dev.to copy includes the article image.
[ ] Dev.to copy uses no more than four relevant tags.
[ ] Dev.to copy includes attribution to the original post.

Optional for priority posts:

[ ] Google Search Console indexing request is submitted for the original URL.

Why This Helps With Canonical Link Equity

"Link juice" is casual SEO language for link equity, authority, or ranking signals that flow through links and canonical relationships. The phrase is imperfect, but the practical goal is clear: you want the original article on your domain to receive the strongest possible credit.

The setup supports that goal in four ways:

Your site publishes first.
Your original page declares itself canonical.
Dev.to declares your original page as canonical.
The Dev.to body includes a visible attribution link back to the original.

Google still makes its own canonicalization decisions, and canonical tags are signals, not commands. But consistent signals matter. If your own page, your sitemap, your RSS feed, your Dev.to copy, and your internal links all point to the same original URL, you are making the decision easy for crawlers.

That is the real purpose of the three-day delay. It gives the original article a head start before the high-authority duplicate appears.

Common Mistakes to Avoid

Do not publish to Dev.to immediately.

Give your site time to be crawled first. Three days is a practical default.

Do not forget the canonical URL.

Without canonical_url, Dev.to may become the stronger version in search simply because the platform has more authority than your portfolio.

Do not use relative image paths.

Dev.to cannot reliably render /images/blog/example.webp unless it knows your domain. Convert it to https://www.yourdomain.com/images/blog/example.webp.

Do not send every website tag to Dev.to.

Pick four relevant tags. Treat tags like reader targeting, not keyword stuffing.

Do not expose your API key.

Use GitHub Secrets, environment variables, or your deployment platform's secret manager.

Do not rewrite internal links to Dev.to.

If the goal is canonical value for your site, keep links pointing back to your original domain where appropriate.

Manual Fallback: RSS Import

If you do not want to use the API yet, Dev.to also supports RSS imports.

Click-by-click:

Log in to Dev.to.
Click your profile image.
Click Settings.
Click Extensions.
Find Publishing to DEV Community from RSS.
Paste your RSS feed URL.
Enable Mark the RSS source as canonical URL by default.
Save the feed settings.
Review imported drafts before publishing.

RSS import is simpler. The API workflow gives you more control over the three-day delay, image conversion, existing-post checks, and tag mapping.

Final Recommended Workflow

For a Next.js portfolio, the cleanest process is:

Write the blog post in your repo.
Use an absolute cover image URL.
Deploy the original post to your domain.
Let the post sit for three days while your sitemap, feed, and internal links expose the original.
Optionally request indexing in Google Search Console for priority posts.
Run a scheduled GitHub Action every day.
Have the script publish only eligible posts to Dev.to.
Send canonical_url with every Dev.to article.
Include the main image and convert local body images.
Limit Dev.to tags to four.
Periodically audit Dev.to to make sure every syndicated article points back to the original.

That is the balance: own the original, syndicate for reach, and make every duplicate point back to your domain.

Sources

DEV Community Help, "Importing Your Organization's Content", accessed August 18, 2026.
Forem API Docs, "Create a new article", accessed August 18, 2026.
Google Search Central, "How to specify a canonical with rel=canonical and other methods", accessed August 18, 2026.
DEV Team, "Revamped RSS Feed Imports", March 9, 2026.

Social Media Content Calendar for Small Business Leads

Ryan VerWey — Tue, 18 Aug 2026 15:30:52 +0000

Originally published on echoeffect.net.

A social media content calendar should do more than remind you to post. For a small business, the useful version connects each post to an audience, a clear offer, a website destination, a tracking link, and a follow-up decision. That is how social media starts supporting leads instead of only producing likes.

The short answer: plan one month at a time, publish consistently, send interested people to the right website page, tag links with campaign parameters, and review both platform insights and website traffic before changing the next month. Meta Business Suite can schedule Facebook and Instagram content and show paid and organic activity, while Google Analytics can identify campaigns that referred traffic to your site (Meta Business Help Center, n.d.-a; Google Analytics Help, n.d.-a).

Key Takeaway: A strong content calendar is a conversion system. Every planned post should have a business role: awareness, trust-building, traffic, lead capture, retention, or direct offer support.

Why Most Content Calendars Fail

Most small business calendars fail because they start with empty dates instead of business goals. The owner asks, "What should we post on Tuesday?" instead of "What decision do we want a real customer to make this month?"

That produces a familiar pattern:

Random holidays that do not connect to the offer.
Platform trends copied without a clear audience fit.
Posts that get engagement but send nobody to the website.
Links with no UTM tracking, so traffic becomes hard to attribute.
No review cycle, so the same weak content repeats next month.

A calendar is useful only when it reduces guesswork. For Echo Effect clients, that means connecting platform execution with the website, landing pages, service pages, analytics, and reporting. If your posts create interest but the website does not explain the next step, the calendar is doing only half the job.

For deeper social execution, see Echo Effect's social media consulting services. If your website is the weak link after the click, review the web design and development services.

What Should a Small Business Content Calendar Include?

A practical social media content calendar should include the fields that affect publishing, measurement, and conversion. Keep it simple enough to use every week.

Calendar Field	Why It Matters
Platform	Facebook, Instagram, LinkedIn, and X behave differently, so do not paste the same plan everywhere.
Audience	Name who the post is for: new prospects, warm leads, past customers, partners, or referral sources.
Content role	Label the post as awareness, education, proof, offer, event, retention, or community.
Format	Choose the right asset: short video, carousel, static image, text post, story, article link, or poll.
Website destination	Map the post to a service page, contact page, blog article, booking page, or landing page.
Tracking link	Use consistent UTM parameters so campaigns can be found in analytics.
Owner and status	Track draft, review, approved, scheduled, published, and measured.
Result	Record useful outcomes: clicks, leads, comments, saves, replies, form starts, or booked calls.

Meta Business Suite supports creating and scheduling Facebook and Instagram posts from desktop, and its Insights area helps businesses understand paid and organic activity across a Facebook Page and Instagram account (Meta Business Help Center, n.d.-a; Meta Business Help Center, n.d.-b). That gives owners a starting point, but platform data should not be the only source of truth.

Your website analytics matter because they show what happened after the click. Google Analytics describes the Traffic acquisition report as a way to understand where website and app visitors came from (Google Analytics Help, n.d.-b). If social media is meant to drive leads, then website sessions, engaged visits, form actions, and consultation requests deserve attention alongside reach and engagement.

A content calendar works best when each post has a business role before it has a caption.

How Do You Build a Calendar That Drives Leads?

Start with the offer, not the platform. If the business goal is consultation requests, the calendar should support the path from curiosity to contact.

1. Pick One Monthly Business Goal

Choose one primary goal for the month:

More consultation requests.
More calls from a service page.
More traffic to a new blog article.
More quote requests for one service.
More retargeting audience growth before a paid campaign.

One goal does not mean every post is promotional. It means every post has a job in the same customer journey. A contractor might spend the month educating homeowners about when a repair becomes urgent. A consultant might spend the month explaining one problem, showing proof of expertise, and sending prospects to a discovery call.

2. Map Content Roles Across the Month

Use a balanced mix. A simple weekly rhythm might look like this:

Day	Content Role	Example
Monday	Education	Explain a common customer problem in plain language.
Wednesday	Proof	Show a process, before-and-after context, or client-safe result without inventing claims.
Friday	Offer	Link to the relevant service page or consultation page.
Weekend	Community	Ask a useful question, recap an event, or share a practical tip.

LinkedIn's own Pages best practices frame a company page as a way to establish thought leadership, build brand awareness, and move an audience to action (LinkedIn Marketing Solutions, n.d.). That same principle applies across platforms: content should not only fill space, it should help the audience understand why the business is credible and what to do next.

3. Connect Posts to the Right Website Page

Do not send every post to the homepage. Match the link to the intent.

A beginner education post can link to a blog article.
A comparison post can link to a service page.
A high-intent offer post can link to the contact page.
A paid social campaign can link to a focused landing page.
A trust-building post can link to an about page, review section, or case-study-style article if one exists.

This is where social media and web development overlap. The calendar creates attention, but the website captures demand. If the website is slow, vague, hard to use on mobile, or missing a clear call to action, stronger posting will not fix the lead path. Pair this article with the local business website essentials guide and the Core Web Vitals checklist when auditing the destination pages.

4. Use UTM Links Before You Publish

UTM parameters are small pieces of text added to a URL so analytics tools can identify campaign traffic. Google's URL builder documentation explains that campaign parameters help identify campaigns that refer traffic (Google Analytics Help, n.d.-a).

For a small business, keep naming consistent:

UTM Field	Example
`utm_source`	`facebook`, `instagram`, `linkedin`
`utm_medium`	`organic_social`, `paid_social`
`utm_campaign`	`august_2026_consultation_push`
`utm_content`	`service_page_carousel`, `owner_tip_video`, `faq_post`

Use lowercase names, avoid spaces, and document the pattern inside the calendar. The goal is not analytics perfection. The goal is to stop guessing whether social posts are creating website demand.

5. Review the Calendar Like a Sales Tool

At the end of the month, do not ask only which post got the most likes. Ask better questions:

Which posts drove qualified website traffic?
Which links produced form starts, calls, bookings, or email inquiries?
Which posts created real conversations with prospects?
Which platform reached the best-fit audience?
Which content role was missing?
Which website page failed to move visitors forward?

Meta insights can help identify content performance on Facebook and Instagram, while Google Analytics can show acquisition patterns after people reach the website (Meta Business Help Center, n.d.-b; Google Analytics Help, n.d.-b). Neither system tells the whole story alone. Use both.

The best calendar is simple enough to use weekly and specific enough to guide better decisions next month.

A 30-Day Content Calendar Framework

Use this as a starter structure for one service line.

Week	Focus	Content Ideas	Website Link
1	Problem awareness	Common mistakes, warning signs, myths, quick tips	Educational blog article
2	Trust and expertise	Process explanation, FAQ, service comparison, behind-the-scenes workflow	Service page
3	Proof and specificity	Review-safe quote, project detail without private data, checklist, decision guide	Related article or about page
4	Offer and conversion	Consultation invitation, limited-scope audit, downloadable checklist, direct next step	Contact page or landing page

This framework keeps the month balanced. It avoids a feed that is all selling and avoids a feed that is all education with no business outcome.

What Metrics Should You Track?

Track metrics in layers:

Layer	Useful Metrics	What It Tells You
Platform reach	Reach, impressions, profile visits	Did the post get seen by enough people?
Platform engagement	Comments, saves, shares, replies, link clicks	Did the topic create interest or action?
Website behavior	Sessions, engaged sessions, landing page views	Did the click become a real visit?
Lead behavior	Form submissions, calls, bookings, quote requests	Did the visit create a business opportunity?
Sales context	Lead quality, close rate, common objections	Did the content attract the right audience?

Vanity metrics are not useless, but they are incomplete. A post with modest reach and two qualified consultation requests can be more valuable than a viral post from people who will never buy.

FAQ: Social Media Content Calendars for Small Businesses

How far ahead should a small business plan social media content?

Plan one month at a time, then review weekly. Monthly planning gives enough structure for campaigns and approvals, while weekly review keeps the calendar flexible when offers, events, or customer questions change.

How often should a small business post?

Posting frequency depends on the platform, audience, and internal capacity. A sustainable schedule that gets reviewed and improved is better than an aggressive schedule that collapses after two weeks. Start with three to five useful posts per week across your priority platforms, then adjust based on real engagement and lead quality.

Should every post link to the website?

No. Some posts should create trust, start conversations, or answer questions directly on the platform. But every calendar should include regular posts that send interested people to a relevant website page, especially when the goal is leads.

Do I need paid ads with a content calendar?

Not always. Organic planning can improve consistency and clarify which messages resonate. Paid ads make more sense when the offer, website destination, audience, tracking, and creative have already been tested enough to spend with discipline.

What is the biggest content calendar mistake?

The biggest mistake is planning posts without a measurement loop. If you do not review what created traffic, leads, conversations, and customer questions, the calendar becomes a publishing habit instead of a marketing system.

Can Echo Effect manage this for my business?

Yes. Echo Effect's social media services include strategy, content creation, scheduling, platform optimization, reporting, and paid campaign support. The right fit depends on your goals, platforms, approval process, and whether your website is ready to convert visitors.

The Bottom Line

A social media content calendar should make your marketing easier to run and easier to measure. The useful version connects posts to business goals, audience intent, website destinations, tracking links, and monthly decisions.

If your business is posting inconsistently, relying on vanity metrics, or sending social traffic to weak website pages, Echo Effect can help build a cleaner system. Start with the social media consulting service, review your website's role in the funnel with web design and development, or schedule a consultation to map the next 30 days around leads instead of guesswork.

References

Google Analytics Help. (n.d.-a). URL builders: Collect campaign data with custom URLs.

Google Analytics Help. (n.d.-b). [GA4] Traffic acquisition report.

LinkedIn Marketing Solutions. (n.d.). LinkedIn Pages best practices.

Meta Business Help Center. (n.d.-a). Create and manage posts in Meta Business Suite on desktop.

Meta Business Help Center. (n.d.-b). About Insights in Meta Business Suite on desktop.

Website Accessibility Checklist for Small Businesses in 2026

Ryan VerWey — Tue, 18 Aug 2026 15:28:12 +0000

Originally published on echoeffect.net.

Website accessibility is not a side task for small business websites anymore. It affects whether people can read your content, use your forms, compare your services, request a quote, and trust your business.

It also affects search visibility. Search engines and AI answer systems need clear text, useful headings, descriptive images, crawlable pages, and accurate structured data. Those are accessibility basics too.

As of August 3, 2026, the practical benchmark for most small business website work is still WCAG 2.2, while W3C is actively developing WCAG 3.0 as the next major version of its accessibility guidance (W3C, 2023, 2026a). That does not mean every local business needs to become a legal expert. It means every business needs a repeatable accessibility review before design problems become customer problems.

Short answer: Start with the customer journey. Make navigation, headings, text, images, forms, buttons, color contrast, keyboard access, and mobile layouts usable before chasing cosmetic design changes.

Why Accessibility Belongs in Your 2026 Website Plan

An inaccessible website quietly blocks customers.

A visitor may not be able to read low-contrast text. A keyboard user may not be able to open a menu. A screen reader user may not understand an image, button, form error, or service comparison. A mobile visitor may miss a call button because a sticky banner covers it. A person with a cognitive disability may abandon a confusing page before contacting the business.

Those are not only compliance concerns. They are revenue concerns.

The U.S. Department of Justice explains that inaccessible web content can deny people with disabilities equal access to communication, goods, services, programs, and activities. DOJ guidance also says businesses open to the public and state and local governments have ADA responsibilities related to accessible web content (U.S. Department of Justice, 2022).

There is one important nuance. The 2024 DOJ web accessibility rule sets specific technical requirements for state and local governments under ADA Title II, not every private small business website. Still, the rule is a strong signal because it uses WCAG 2.1 Level AA as the required technical standard for covered public entities (U.S. Department of Justice, 2024). Private businesses should talk with qualified legal counsel about their specific obligations, but from a website quality standpoint, WCAG remains the most practical framework to follow.

Accessibility work should be tied to real customer tasks: reading service details, comparing options, using forms, and contacting the business.

What WCAG 2.2 and WCAG 3 Mean for Small Businesses

WCAG stands for Web Content Accessibility Guidelines. W3C says WCAG 2.2 covers recommendations for making web content more accessible to people with disabilities, including people with blindness, low vision, deafness, limited movement, cognitive limitations, and combinations of disabilities (W3C, 2023).

WCAG 2.2 is the current stable recommendation. WCAG 3.0 is not final. W3C published an updated WCAG 3 Working Draft on March 3, 2026, and describes WCAG 3 as the future successor to the WCAG 2 series (W3C, 2026a, 2026b).

For a small business owner, the takeaway is simple:

Use WCAG 2.2 as the practical checklist today.
Do not wait for WCAG 3.0 to start fixing obvious barriers.
Build habits that will age well: clear structure, readable design, usable forms, keyboard support, and tested customer journeys.

Good accessibility is not about passing a scan once. Automated scans are useful, but they cannot tell whether your offer is clear, whether your form error makes sense, or whether a person using a screen reader understands the page.

The 2026 Accessibility Checklist

Use this checklist when reviewing a homepage, service page, contact page, quote form, landing page, or blog post.

1. Make the Page Structure Obvious

A good page should make sense before anyone sees the colors or images.

Check for:

One clear H1 that describes the page.
H2 sections that answer real customer questions.
Short paragraphs that are easy to scan.
Lists for steps, requirements, features, and comparisons.
Internal links with descriptive anchor text.
Page titles and meta descriptions that match the visible content.

This helps accessibility, SEO, AEO, and GEO at the same time. People skim headings. Search engines use structure to understand topics. AI answer systems need direct, well-labeled answers they can summarize without guessing.

For example, a service page should answer "What do you do?", "Who is this for?", "What is included?", "How much does it usually involve?", "Where do you serve customers?", and "How do I contact you?" in visible text.

2. Write Alt Text for People First

Alt text is not a keyword stuffing field. It is a text alternative for images that need one.

Google's image SEO guidance says descriptive filenames, titles, and alt text help Google understand image subject matter, and that images should be placed near relevant text on relevant pages (Google Search Central, n.d.-a). W3C's image tutorial explains that informative image alternatives should convey the meaning or content shown visually, not merely list objects in the image (W3C, n.d.).

Use this simple rule:

If an image explains something important, describe what matters.
If an image is decorative, leave it empty or handle it as decorative in the code.
If an image is a link or button, describe the action.
If the image includes text, include the useful text in the page body whenever possible.

Bad alt text: "SEO web design business accessibility 2026."

Better alt text: "Customer using a laptop to review a small business service page."

3. Use Color Contrast That Works in Real Life

Low-contrast design is one of the fastest ways to make a website feel polished and unusable at the same time.

Check:

Body text against the page background.
Button text against button colors.
Navigation links in hover and active states.
Form labels, placeholders, helper text, and errors.
Light text over images.
Dark mode and light mode variants if the site supports both.

Do not rely on your own monitor. Test on a phone, in sunlight, at lower brightness, and with browser zoom. If the page gets harder to read, customers will feel it before they can explain it.

4. Make Every Interactive Element Keyboard Usable

Keyboard access is essential for people who cannot use a mouse, people using assistive technology, and power users who navigate quickly.

Test with the Tab, Shift + Tab, Enter, Space, and Escape keys.

Make sure:

Menus can be opened and closed.
Buttons show visible focus styles.
Modal windows do not trap people incorrectly.
Dropdowns can be operated without a mouse.
Forms can be completed in a logical order.
Skip links or clear navigation patterns help users reach content quickly.
Focus does not disappear behind sticky headers, cookie banners, or chat widgets.

This is where many custom designs fail. A beautiful menu that only works with a mouse is not finished.

5. Fix Forms Before Anything Else

Forms are where accessibility problems become lost leads.

Review every form field:

Does it have a visible label?
Is the required status clear?
Is the error message specific?
Can the error be understood by screen readers?
Does the form preserve user input after an error?
Can the form be completed on mobile?
Does the confirmation message explain what happens next?

For a small business website, the contact form is often the money path. A form that looks modern but fails accessibility, validation, or email delivery is a business problem.

6. Keep Mobile Layouts Stable and Simple

Mobile accessibility is not only about screen size. It is about touch targets, readable text, page stability, keyboard behavior, and friction.

Check:

Buttons are easy to tap.
Text does not require zooming.
The phone number is selectable and tappable.
Menus do not cover the page.
Forms do not jump when the keyboard opens.
Review widgets, maps, chat tools, and popups do not block the primary call to action.
Content remains readable when text size is increased.

Mobile is often the first visit, especially for local service searches. If the mobile experience is difficult, the business may never get a second chance.

Accessible websites support different input methods, including keyboards, assistive devices, touch screens, and screen readers.

7. Match Structured Data to Visible Content

Structured data helps search systems understand the page, but it must match what users can actually see.

Google says it uses structured data to understand content and gather information about people, organizations, products, and other entities on the web (Google Search Central, n.d.-b). For small businesses, useful structured data often includes Organization, LocalBusiness, Service, FAQPage where appropriate, BreadcrumbList, and BlogPosting.

The accessibility connection is straightforward: do not hide critical facts in code only. If the page schema says the business serves Florida, the page should visibly say that. If the schema describes a service, the page should clearly explain that service. If an FAQ is marked up, the question and answer should be visible to readers.

This supports GEO because AI systems need reliable entity signals. It supports SEO because search systems can better classify the page. It supports accessibility because people get the same information machines get.

8. Review Third-Party Widgets

Many accessibility failures come from tools added after launch:

Chat widgets.
Review embeds.
Booking calendars.
Social feeds.
Ad scripts.
Cookie banners.
CRM forms.
Payment widgets.

Do not assume a vendor widget is accessible because the vendor is large. Test it. If it blocks a form, traps focus, lacks labels, creates layout shifts, or makes the mobile page harder to use, it needs configuration or replacement.

9. Test With Real Tasks

A scan can find missing alt text. It cannot tell you whether a customer can confidently hire you.

Run task-based tests:

Find the main service.
Compare two service options.
Read a pricing or process explanation.
Find the service area.
Submit the contact form.
Tap the phone number.
Navigate the page with only a keyboard.
Increase browser zoom to 200%.
Turn on a screen reader and listen to the page structure.

If those tasks are difficult, fix the design before adding more features.

How Accessibility Improves SEO, AEO, and GEO

Accessibility is not a separate lane from search. It strengthens the same signals that help people and machines understand a website.

Accessible pages tend to have:

Clear headings.
Descriptive links.
Useful image descriptions.
Text that can be crawled and read aloud.
Stable mobile layouts.
Logical form labels.
Accurate structured data.
Fewer confusing interactions.
More complete answers to customer questions.

That combination helps traditional SEO because search engines can parse the page. It helps AEO because direct answers are easier to extract. It helps GEO because AI answer systems need clear source material before they can cite or summarize a business accurately.

For a small business, the goal is not to sound technical. The goal is to be understandable everywhere a customer may encounter you: Google, AI search, a screen reader, a phone browser, a desktop browser, and a referral link.

What Should a Small Business Fix First?

Start with the pages that make money.

Prioritize:

Homepage.
Contact page.
Primary service pages.
Paid ad landing pages.
Booking or quote forms.
High-traffic blog posts.

Then fix the highest-friction items:

Missing or confusing headings.
Low contrast text.
Buttons and links without clear names.
Forms without labels or useful errors.
Menus that fail keyboard or mobile users.
Images that explain important content but have no useful alt text.
Popups that cover the call to action.
Structured data that does not match visible content.

This order keeps the work practical. Accessibility does not need to become an endless audit before anything improves.

FAQ: Website Accessibility for Small Businesses

What is website accessibility?

Website accessibility means people with disabilities can perceive, navigate, understand, and interact with your website. That includes people using screen readers, keyboards, captions, zoom, voice control, assistive devices, and different visual or cognitive supports.

Does every small business website need to follow WCAG?

Legal obligations depend on the business, jurisdiction, website function, and customer relationship. From a design and risk standpoint, WCAG 2.2 is the best practical framework for improving accessibility. Businesses should consult qualified legal counsel for legal advice.

Does accessibility help SEO?

Yes, when it improves clarity and usability. Clear headings, descriptive links, alt text, readable content, mobile usability, and accurate structured data all help search systems understand pages better. Accessibility should be done for people first, with SEO as a secondary benefit.

Are accessibility overlay widgets enough?

No. An overlay cannot fix poor structure, unclear content, unlabeled forms, weak contrast, broken keyboard navigation, or inaccessible third-party widgets by itself. Accessibility needs to be built into the page and tested in the customer journey.

Can small businesses get tax help for accessibility work?

Some eligible small businesses may be able to claim the Disabled Access Credit for qualified access expenditures. The IRS says eligible small businesses use Form 8826 to claim the credit and that the credit is part of the general business credit (Internal Revenue Service, n.d.). Talk with a tax professional before relying on any tax benefit.

The Bottom Line

Accessible websites are better business websites. They are easier to read, easier to navigate, easier to cite, easier to trust, and easier to use when a customer is ready to act.

In 2026, small businesses should treat accessibility as part of website maintenance, not as a one-time redesign feature. Start with the money pages, fix the customer journey, use WCAG 2.2 as the practical standard, watch WCAG 3.0 as it develops, and make sure the information in your page content, images, forms, and structured data tells the same story.

Echo Effect helps small businesses build websites that work for people, search engines, and AI answer systems. If your site has never had an accessibility review, start with the homepage, service pages, and contact form. That is where the fastest improvements usually live.

References

Google Search Central. (n.d.-a). Image SEO best practices. Google for Developers. Retrieved August 3, 2026, from https://developers.google.com/search/docs/appearance/google-images

Google Search Central. (n.d.-b). Intro to how structured data markup works. Google for Developers. Retrieved August 3, 2026, from https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data

Internal Revenue Service. (n.d.). About Form 8826, Disabled Access Credit. Retrieved August 3, 2026, from https://www.irs.gov/forms-pubs/about-form-8826

U.S. Department of Justice. (2022, March 18). Guidance on web accessibility and the ADA. ADA.gov. https://www.ada.gov/resources/web-guidance/

U.S. Department of Justice. (2024, March 8). Fact sheet: New rule on the accessibility of web content and mobile apps provided by state and local governments. ADA.gov. https://www.ada.gov/resources/2024-03-08-web-rule/

W3C. (2023, October 5). Web Content Accessibility Guidelines (WCAG) 2.2. https://www.w3.org/TR/WCAG22/

W3C. (n.d.). Informative images. Web Accessibility Initiative. Retrieved August 3, 2026, from https://www.w3.org/WAI/tutorials/images/informative/

W3C. (2026a, March 3). For review: WCAG 3 Working Draft, March 2026. Web Accessibility Initiative. https://www.w3.org/WAI/news/2026-03-03/wcag3/

W3C. (2026b). WCAG 3 introduction. Web Accessibility Initiative. Retrieved August 3, 2026, from https://www.w3.org/WAI/standards-guidelines/wcag/wcag3-intro/

Passkeys Are Becoming Default: Small Business Checklist

Ryan VerWey — Tue, 18 Aug 2026 15:27:37 +0000

Originally published on echoeffect.net.

Passwords are not disappearing overnight, but the direction is clear: business sign-ins are moving toward passkeys and phishing-resistant authentication.

The current event that should get every small business owner's attention is Microsoft's July 2026 Entra ID update. Microsoft says passkeys will become the default authentication experience in Entra ID beginning September 1, 2026. Microsoft-provided SMS and voice authentication delivery will then be retired on February 1, 2027 for public cloud tenants (Microsoft, 2026a, 2026b).

That does not only matter to enterprise IT teams. It matters to small businesses using Microsoft 365, Google Workspace, customer portals, booking platforms, CRMs, ecommerce accounts, website admin panels, password managers, payment processors, social media tools, and ad accounts.

The short answer: if your business still relies on passwords, SMS codes, shared admin logins, or vendor-owned accounts, 2026 is the year to clean that up.

Short answer: Passkeys use public-key cryptography and device verification instead of reusable passwords. For most small businesses, the practical plan is to protect high-value accounts first, keep recovery clear, train staff, and phase out SMS MFA where stronger options are available.

What Is a Passkey?

A passkey is a passwordless sign-in method built on FIDO and WebAuthn standards. Instead of typing a password that can be stolen or reused, the user verifies themselves on a trusted device with a fingerprint, face scan, screen lock, PIN, hardware security key, or credential manager.

The important part happens behind the scenes. The website stores a public key. The user's device or credential provider keeps the private key. During sign-in, the device proves possession of the private key without sending a password to the website. web.dev explains that this design reduces phishing risk and credential theft because the private key signs a challenge for the valid domain, and the server verifies the result with the stored public key (Kitamura, 2026).

In plain English: a passkey is harder to steal than a password because there is no shared password to type into a fake login page.

Passkeys can be:

Synced passkeys: Stored in a credential manager such as iCloud Keychain, Google Password Manager, or another supported provider, then synced across the user's devices.
Device-bound passkeys: Stored on a specific device, such as a phone, computer, Microsoft Authenticator passkey, Windows Hello credential, or FIDO2 hardware security key.

Both categories can be useful. The right choice depends on the account, user, device ownership, recovery needs, and risk level.

Small businesses should not wait for a forced migration before replacing weak sign-in methods on critical accounts.

Why This Matters Right Now

Microsoft's announcement gives the market a clear signal. SMS and voice codes helped many organizations adopt MFA, but Microsoft now describes them as phishable methods that provide weaker protection than passkeys. Microsoft also says users enabled for SMS or voice in Entra ID will be auto-enabled and nudged to register passkeys beginning September 1, 2026, and users who still depend on Microsoft-provided SMS or voice after February 1, 2027 will face a blocking registration prompt before continuing to sign in (Microsoft, 2026a).

This is not an isolated vendor preference. The broader identity market has been moving this way for years.

The FIDO Alliance reported in its 2026 global passkey research that passkeys have reached 5 billion active credentials, 90% consumer awareness, and 75% consumer enablement on at least some accounts. It also reported that 68% of surveyed organizations were deploying, piloting, or rolling out passkeys for employee authentication (FIDO Alliance, 2026).

The business case is not only security. FIDO's 2025 Passkey Index reported a 93% success rate for passkey logins compared with 63% for other methods among participating platforms. The same report said passkey sign-ins averaged 8.5 seconds compared with 31.2 seconds for traditional MFA methods, a 73% decrease in login time (FIDO Alliance, 2025).

For a small business, that means authentication is both a security issue and a workflow issue. Every failed login, reset ticket, locked-out employee, vendor handoff, and forgotten password wastes time.

The Small Business Risk: Not Just "Hackers"

Most small businesses do not lose accounts because a genius attacker breaks cryptography. They lose accounts because of ordinary operational gaps:

One shared admin account controls the website.
A former vendor still has access.
SMS MFA is tied to a phone number nobody owns anymore.
Password reset email goes to a stale inbox.
A staff member reuses a password from a personal account.
A fake Microsoft 365 login page captures credentials.
A social media account has no recovery owner.
A password manager vault has no business continuity plan.

Passkeys do not fix every one of those problems by themselves. They do reduce the risk that a reused or phished password becomes the easy way in. They also force the business to answer questions that should already be documented: who owns each account, which devices are trusted, how access is recovered, and who can approve changes.

That is why passkey planning belongs in website maintenance, SEO, AEO, and GEO work. If attackers take over your website admin, Google Business Profile, social accounts, or email domain, the damage is not limited to IT. It can break lead flow, damage local search trust, interrupt ad campaigns, and pollute the public signals that search engines and AI answer systems use to understand your business.

What to Protect First

Do not start with every account in the company. Start with the accounts that can change money, identity, website content, customer data, or public trust.

Priority	Account type	Why it matters
1	Microsoft 365 or Google Workspace admins	Controls email, identity, reset paths, files, and often domain trust
2	Domain registrar and DNS	Controls where the website, email, and verification records point
3	Website hosting and CMS admin	Controls public pages, forms, plugins, redirects, and scripts
4	Payment, banking, payroll, and invoicing	Direct financial risk
5	Password manager administrator	Controls access to many other systems
6	Google Business Profile and ad accounts	Controls local visibility, paid traffic, and brand trust
7	Facebook, Instagram, LinkedIn, and YouTube	Controls public reputation and customer communication
8	CRM, booking, and form tools	Controls customer records and lead flow

If a small business only has time for one security improvement this month, protect the accounts at the top of that list.

A Practical Passkey Rollout Checklist

This checklist is written for small business owners, office managers, agencies, and web teams. You do not need to implement everything in one day. You do need a written migration path.

1. Inventory Accounts and Owners

Create a simple account inventory. Include:

Account name.
Business purpose.
Primary owner.
Backup owner.
Login URL.
MFA method.
Recovery email or phone.
Vendor access.
Last access review date.

This does not need to be fancy. A secure password manager, spreadsheet, or internal IT document can work if access is controlled.

The goal is to eliminate mystery. If nobody knows who owns the domain registrar, the business has a security and continuity problem.

2. Move Admins First

Roll passkeys or phishing-resistant MFA to administrators before general staff. Admin accounts can reset users, change DNS, install plugins, delete files, alter billing, and grant vendor access.

For Microsoft Entra users, Microsoft recommends identifying users enabled for SMS or voice, enabling passkeys, using registration campaigns, and communicating the change before the rollout hits users (Microsoft, 2026a, 2026b).

For other systems, the same pattern applies:

Identify who still uses password-only sign-in or SMS MFA.
Confirm the platform supports passkeys, FIDO2 security keys, or another phishing-resistant method.
Pilot with owners and admins.
Document recovery.
Roll out to the rest of the team.

3. Keep Recovery Strong

Weak recovery can undo strong authentication. If support can remove MFA after someone answers easy questions, attackers will target the recovery process instead of the login screen.

web.dev recommends notifying users after passkey registration so unauthorized passkey creation can be detected (Kitamura, 2026). For businesses, that principle should expand into a broader recovery plan.

Document:

Who can approve account recovery.
How identity is verified before resetting access.
Which email receives security alerts.
Where backup codes are stored.
Which devices can create or use passkeys.
What happens when a phone, laptop, or security key is lost.
How vendor access is removed at the end of a project.

Do not rely on one phone number, one employee, or one vendor relationship as the only recovery path.

4. Separate Shared Work From Shared Logins

Many small businesses still share one login because "everyone needs access." That is exactly the habit passkeys should help replace.

Use individual accounts with role-based access whenever possible. A social media scheduler, CMS, ad account, Google Business Profile, CRM, or password manager should allow named users or roles. Shared logins make it hard to revoke access, audit activity, and recover safely.

If a platform only supports one login, store it in a business password manager, protect the vault with strong MFA, and document who can use it. Then plan to move away from that platform if account sharing creates material risk.

5. Choose Passkey Types Intentionally

Synced passkeys are convenient because users can access accounts across devices through their credential provider. Device-bound passkeys can be stricter because they stay tied to a specific authenticator or security key.

NIST's SP 800-63 Revision 4, finalized in July 2025, explicitly integrates syncable authenticators such as synced passkeys into its updated digital identity guidance (NIST, 2025). That is a signal that synced passkeys are part of mainstream identity planning, not a niche convenience feature.

For small businesses:

Use synced passkeys for lower-risk employee workflows where convenience and recovery matter.
Consider device-bound passkeys or hardware security keys for owners, admins, finance, and critical systems.
Avoid letting unmanaged personal devices become the only path into business-critical accounts.
Keep at least two recovery-capable owners for critical systems.

6. Train People Before Prompts Appear

Passkey adoption fails when users see a security prompt they do not understand. Explain the change before rollout.

Your internal note should answer:

What is changing?
Why are passwords and SMS codes being reduced?
Which accounts are affected first?
What device should the person use?
What should they do if they lose a device?
Who should they contact before approving a strange prompt?
What does a real registration flow look like?

Keep the language simple. A staff member does not need a cryptography lesson. They need to know which prompts are expected and which prompts should be reported.

Passkeys reduce phishing risk, but the rollout still needs clear ownership, secure recovery, and user training.

Website and SEO Implications

Passkeys may sound like an internal IT topic, but they have direct website consequences.

Your website and marketing accounts are usually connected to:

Domain DNS.
Website hosting.
CMS admin.
Email delivery.
Analytics.
Google Search Console.
Google Business Profile.
Ad platforms.
Social media profiles.
Forms, booking tools, and CRM systems.

If any of those accounts are compromised, your SEO and AEO work can be damaged quickly. Attackers can add spam pages, change redirects, break forms, swap tracking scripts, abuse email, alter business details, publish fake posts, or block crawlers.

Google's 2026 guidance for generative AI features says AI search visibility still depends on foundational SEO: helpful content, crawlability, technical structure, page experience, and high-quality supporting images or video (Google Search Central, 2026). A compromised or unstable site weakens those signals.

The AEO and GEO lesson is simple: trustworthy content requires trustworthy operations. A business cannot expect search engines and AI answer systems to cite accurate information if account security allows the public facts about the business to be changed by the wrong person.

For related visibility work, read Echo Effect's guides to answer engine optimization, AI crawler access, and website vulnerability management.

Passkeys Are Not Magic

Passkeys are a major improvement, but they are not a complete security program.

They do not replace:

Device updates.
Malware protection.
Vendor offboarding.
Backup planning.
Least-privilege access.
Secure recovery.
Phishing awareness.
Website patching.
Monitoring for suspicious changes.

They also introduce practical questions. Which devices are allowed? What happens when an employee leaves? Can the business recover if the owner's phone is lost? Are passkeys stored in a personal credential manager or a managed business system? Do vendors need their own accounts?

Those questions are solvable, but they should be answered before a forced platform change creates urgency.

FAQ: Passkeys for Small Businesses

Should every small business use passkeys?

Most small businesses should use passkeys where important platforms support them, especially for email, domain, hosting, website, finance, and admin accounts. If passkeys are not available, use the strongest MFA option available and plan to upgrade.

Are passkeys better than SMS codes?

Yes for most business sign-in scenarios. SMS codes can be phished, intercepted, socially engineered, or affected by SIM-swap attacks. Passkeys are designed to be phishing-resistant because they use cryptographic keys tied to the legitimate domain.

Can a passkey be stolen?

A passkey is much harder to steal than a password, but no system is perfect. Attackers may still target devices, recovery processes, malware, support desks, or compromised credential providers. That is why passkeys should be paired with device security and strong recovery rules.

What if an employee loses their phone?

The business needs a documented recovery process before rollout. Keep at least two account owners for critical systems, store recovery codes securely, and make sure recovery does not depend on one person, one phone number, or one vendor.

Do passkeys help SEO?

Indirectly, yes. Passkeys do not make a page rank higher by themselves. They help protect the accounts that control website content, DNS, analytics, business listings, ads, and crawl visibility. Stronger account security protects the trust signals that SEO, AEO, and GEO depend on.

What should I do this week?

Start with your highest-risk accounts. Review Microsoft 365 or Google Workspace admins, domain registrar access, hosting, CMS admin accounts, password manager ownership, Google Business Profile, ad accounts, and social media profiles. Turn on passkeys or phishing-resistant MFA where available.

The Bottom Line

Passkeys are moving from optional upgrade to default expectation. Microsoft's 2026 Entra timeline makes that obvious, and broader FIDO adoption data shows the market is ready.

Small businesses should not treat this as an enterprise-only issue. Your website, email, domain, ads, social profiles, CRM, booking tools, and payment systems all depend on identity security.

Start with ownership. Protect the accounts that can change public trust or move money. Replace SMS MFA where stronger options are available. Train users before prompts appear. Keep recovery documented. Review access monthly.

Good authentication is not separate from digital marketing anymore. It protects the systems that keep your website live, your lead flow working, your local business details accurate, and your search visibility trustworthy.

Echo Effect helps small businesses build and maintain websites with practical security, SEO, AEO, and GEO in mind. If your business does not know who owns every critical login, start there before the next forced platform change starts the clock.

References

Cybersecurity and Infrastructure Security Agency. (n.d.). Require multifactor authentication. Retrieved July 27, 2026, from https://www.cisa.gov/audiences/small-and-medium-businesses/secure-your-business/require-multifactor-authentication

FIDO Alliance. (2025, October). Passkey Index. https://fidoalliance.org/wp-content/uploads/2025/10/FIDO-Passkey-Index-October-2025.pdf

FIDO Alliance. (2026, May 7). The state of passkeys 2026: Global consumer and workforce report. https://fidoalliance.org/the-state-of-passkeys-2026-global-consumer-and-workforce-report/

Google Search Central. (2026, July 10). Optimizing your website for generative AI features on Google Search. Google for Developers. https://developers.google.com/search/docs/fundamentals/ai-optimization-guide

Kitamura, E. (2026, April 9). Create a passkey for passwordless logins. web.dev. https://web.dev/articles/passkey-registration

Microsoft. (2026a, July 21). Passkeys by default and retirement of Microsoft-provided SMS and voice authentication. Microsoft Learn. https://learn.microsoft.com/en-us/entra/identity/authentication/concept-sms-voice-retirement

Microsoft. (2026b, July 13). Microsoft Entra ID security updates: Passkeys are the default authentication method in Entra ID. Microsoft Security Blog. https://www.microsoft.com/en-us/security/blog/2026/07/13/microsoft-entra-id-security-updates-passkeys-are-the-default-authentication-method-in-entra-id/

National Institute of Standards and Technology. (2025, July). SP 800-63 Digital Identity Guidelines. https://pages.nist.gov/800-63-4/

Website Vulnerability Checklist for Small Businesses in 2026

Ryan VerWey — Tue, 18 Aug 2026 15:27:33 +0000

Originally published on echoeffect.net.

Website security used to feel like an enterprise problem. In 2026, it is a small business website problem too.

Verizon's 2026 Data Breach Investigations Report found that 31% of breaches now start with software vulnerabilities, making vulnerability exploitation the top breach entry point in the report's public summary (Verizon, 2026a, 2026b). That is not just a warning for banks, hospitals, or SaaS companies. It matters for service businesses, local retailers, restaurants, contractors, medical offices, law firms, and consultants whose websites collect leads, connect to email, load third-party scripts, and depend on plugins, packages, themes, forms, analytics, booking tools, or hosting panels.

The short answer: a small business website needs a maintenance process, not a one-time launch. If no one is checking updates, reviewing dependencies, testing forms, watching logs, and removing unused software, the site gets riskier every month.

Short answer: Treat website vulnerability management like bookkeeping. Assign an owner, review it on a schedule, document what changed, and fix high-risk issues before they become emergencies.

Why Vulnerability Exploitation Is a Business Issue

A vulnerable website does not need to hold credit card data to hurt the business. Attackers can abuse ordinary marketing sites in several ways:

Inject spam pages that damage search visibility.
Steal form submissions or customer contact details.
Redirect visitors to scams.
Use the site to host malware.
Abuse server resources and increase hosting costs.
Break the lead path by taking forms, pages, or booking tools offline.
Expose admin accounts, API keys, or SMTP credentials.

That last point is often missed. Many small business websites connect to services that are more sensitive than the public page itself. A contact form may connect to Microsoft 365 SMTP. A booking widget may connect to a calendar. An analytics script may connect to ad accounts. A plugin may store an API key. A neglected website can become a doorway into tools the business depends on.

This is why security belongs in the same conversation as SEO, AEO, and GEO. Search engines and AI answer systems need stable, trustworthy, crawlable pages. If a website gets defaced, injected with spam, blocked by browsers, or knocked offline, visibility suffers along with customer trust.

What Changed in 2026

The most important shift is speed. Verizon reported that vulnerability exploitation rose to 31% of breaches and surpassed stolen credentials as the leading entry point (Verizon, 2026a). Verizon's public news summary also says attackers are using AI to accelerate exploitation, shrinking the response window from months to hours (Verizon, 2026b).

That does not mean AI is the root cause of every attack. It means old maintenance habits are no longer good enough. Waiting a quarter to apply a critical patch is too slow when attackers can scan the internet, find known vulnerable software, and automate exploitation quickly.

For small businesses, the practical lesson is simple: do not wait until the website visibly breaks. Most serious website security work is boring on purpose. It is version checks, patch notes, backups, access reviews, log checks, and test deployments.

Small business website security should focus on fast detection, fast patching, and clean recovery before a warning becomes visible to customers.

The Five Risk Areas to Review First

Small businesses do not need a 60-page security program to start. They need to focus on the website surfaces that most often create practical risk.

Risk area	What to check first	Business reason
Access control	Admin users, roles, MFA, staging access	Prevent unauthorized site changes and private content exposure
Security misconfiguration	Debug mode, public backups, headers, runtime versions	Reduce quiet mistakes that make a normal site easy to abuse
Software supply chain	Plugins, packages, themes, lockfiles, abandoned tools	Limit risk from third-party code your business depends on
Injection	Forms, search, booking tools, custom integrations	Protect databases, lead data, and connected business systems
Cross-site scripting	Displayed user input, widgets, unsafe scripts	Protect visitors from attacker-controlled scripts

1. Access Control

OWASP lists Broken Access Control as the number one risk in the OWASP Top 10:2025, and its introduction says this category remains the most serious application security risk (OWASP Foundation, 2025a, 2025b).

For a small business website, access control usually means:

Admin logins.
CMS roles.
Customer portal permissions.
Staging site protection.
File uploads.
Private pages.
API routes.
Form submission endpoints.

The question is not only "Can someone log in?" The better question is "Can someone access something they should not be able to access?"

Use strong passwords, require multifactor authentication where available, remove former vendors and employees, avoid shared admin accounts, protect staging sites, and limit each user to the access they actually need.

2. Security Misconfiguration

OWASP moved Security Misconfiguration to number two in the 2025 list, noting that modern software increasingly depends on configuration choices (OWASP Foundation, 2025b). That matters because small business sites often combine hosting settings, DNS records, CDN rules, form settings, cache settings, environment variables, redirects, robots rules, and third-party scripts.

Common misconfigurations include:

Public staging sites indexed by Google.
Debug mode left on in production.
Overly broad file permissions.
Missing security headers.
Old PHP or Node versions.
Exposed environment files.
Public admin paths without rate limiting.
Backups stored inside the public web root.

Misconfiguration is dangerous because the site can look normal while the risk is sitting in plain sight.

3. Software Supply Chain Failures

OWASP added Software Supply Chain Failures as a top-three risk in 2025 (OWASP Foundation, 2025c). This category is especially relevant for modern websites because few sites are built from one piece of software. A simple business website may depend on dozens or hundreds of packages, plugins, themes, build tools, hosting adapters, and third-party scripts.

The business owner does not need to audit every line of code personally. They do need someone to own these questions:

What platform, framework, plugins, packages, and themes does the site use?
Which dependencies are outdated or abandoned?
Are updates tested before production?
Can a bad update be rolled back quickly?
Are lockfiles, plugin inventories, and hosting versions documented?

If nobody can answer those questions, the website is harder to defend and harder to recover.

4. Injection

CISA and the FBI warned in March 2024 that SQL injection remains a persistent class of defect despite decades of known mitigations. Their Secure by Design alert explains that SQL injection happens when user-supplied input is inserted into a SQL command, and recommends parameterized queries with prepared statements as the standard defense (CISA & FBI, 2024a).

Small businesses usually encounter injection risk through forms, search boxes, booking tools, old plugins, custom dashboards, and poorly built integrations.

The fix is not "sanitize harder" as a vague slogan. The fix is to use secure framework defaults, parameterized database access, server-side validation, and code review on every feature that accepts user input.

5. Cross-Site Scripting

CISA and the FBI also warned that cross-site scripting remains preventable and should not be present in software products. Their September 2024 alert says XSS can allow malicious scripts to be injected into web applications, and recommends input validation, output encoding, code reviews, threat modeling, and adversarial testing (CISA & FBI, 2024b).

For small businesses, XSS risk often appears in places that accept or display content:

Contact forms.
Review widgets.
Blog comments.
Search results.
Admin dashboards.
Customer messages.
User-uploaded content.
Embedded third-party scripts.

Modern frameworks help, but they do not eliminate every edge case. Be careful with custom HTML, unsafe script injection, poorly reviewed plugins, and any feature that displays untrusted text.

A Practical Website Vulnerability Checklist

Use this checklist monthly, and immediately after a high-severity advisory affects your website stack.

Confirm Ownership

Assign one person or vendor to own website maintenance. "The hosting company probably handles it" is not a plan. Hosting providers may patch infrastructure, but they usually do not update your custom code, plugins, content system, DNS rules, analytics scripts, or business workflows.

Your owner should document:

Website platform and version.
Hosting provider.
DNS provider.
CMS admin users.
Framework and package manager.
Plugins, apps, themes, and integrations.
Contact form delivery path.
Backup location and restore process.

Patch the Stack

Review the full stack, not only the visible website.

Check:

CMS core.
Plugins and themes.
JavaScript packages.
Server runtime, such as Node or PHP.
Framework versions.
Hosting build images.
Form libraries.
Email dependencies.
Analytics and marketing scripts.
CDN, cache, and WAF settings.

NIST's Secure Software Development Framework recommends secure development practices that reduce vulnerabilities in released software, mitigate the impact of issues that still slip through, and address root causes to prevent recurrence (Souppaya et al., 2022). In plain terms, patching should be part of the way the website is managed, not a panic task after something goes wrong.

Remove What You Do Not Use

Unused software is easy to ignore and hard to defend. Remove inactive plugins, old themes, unused packages, abandoned scripts, test pages, stale admin accounts, and old integrations.

Every unused dependency is another thing that can become vulnerable without providing business value.

Protect Admin Access

Lock down the accounts that can change the site.

At minimum:

Require unique passwords.
Enable multifactor authentication where possible.
Remove former employees and vendors.
Avoid shared administrator accounts.
Limit admin roles.
Review password reset emails.
Rate limit login attempts where the platform supports it.
Keep recovery codes in a secure place.

Access control is usually cheaper to fix before an incident than after an account is abused.

Test the Lead Path After Updates

Security updates can break important workflows if they are rushed. After every material update, test the actual customer path:

Homepage loads.
Service pages load.
Contact form submits.
Email notification arrives.
Calendar or booking link works.
Phone links and CTA buttons work.
Blog posts render.
Images load.
Sitemap and robots.txt still respond.
Analytics and conversion tracking still fire.

Good maintenance protects security and revenue at the same time.

A useful maintenance plan checks vulnerable areas regularly, documents what changed, and confirms the customer journey still works.

What to Ask Your Web Developer or Agency

If someone else manages your website, send these questions:

What platform, framework, CMS, plugins, and runtime versions are live right now?
Which parts of the site accept user input?
Are any plugins, packages, or themes abandoned?
How quickly do we patch critical vulnerabilities?
Do we test updates before production?
What backup can we restore from today?
How often are admin users reviewed?
Is multifactor authentication enabled for admin access?
Are forms protected against spam and abuse?
Do we monitor uptime, form failures, and crawl errors?
Who gets notified when a security advisory affects our stack?
What would we do if the site were defaced or blocked tomorrow?

The answer does not need to be complicated. It does need to be specific.

FAQ: Small Business Website Vulnerabilities

How often should a small business update its website?

Review website software monthly at minimum. Apply critical security patches as soon as they are available, especially when the affected software is internet-facing or accepts user input.

Is a brochure website still at risk?

Yes. A brochure site can still be abused if it has forms, admin access, plugins, scripts, a CMS, hosting credentials, or outdated dependencies. Static sites usually have a smaller attack surface, but they still need domain, hosting, DNS, and form security.

Will security updates hurt SEO?

They should not if they are tested properly. The SEO risk comes from broken redirects, missing metadata, failed pages, blocked crawlers, broken images, bad canonicals, or forms that stop working after an update.

What is the fastest way to reduce risk this week?

Remove unused plugins and accounts, enable multifactor authentication on admin accounts, verify backups, update critical software, and test the contact form. Those steps reduce common risk quickly.

Do small businesses need a vulnerability scanner?

Many do, but a scanner is not a substitute for ownership. Scanners can find exposed software, missing headers, outdated dependencies, and common flaws. Someone still needs to review findings, prioritize fixes, and confirm the repair.

The Bottom Line

Website vulnerability management is now part of small business operations. The 2026 DBIR shows why: attackers are exploiting software flaws at scale, and the window to respond is getting shorter.

You do not need enterprise complexity to improve security. You need a clear owner, a monthly review, fast critical patching, clean backups, limited admin access, dependency awareness, and testing after every meaningful change.

That same discipline supports SEO, AEO, and GEO. A website that stays patched, stable, fast, and trustworthy is easier for customers to use, easier for search engines to crawl, and easier for AI answer systems to cite accurately.

Echo Effect helps small businesses build and maintain websites with performance, search visibility, and practical security in mind. If your current site has no patch owner, no backup plan, or no clear inventory, start with a technical website audit before the next vulnerability turns into lost leads.

References

Cybersecurity and Infrastructure Security Agency, & Federal Bureau of Investigation. (2024a, March). Secure by design alert: Eliminating SQL injection vulnerabilities in software. https://www.ic3.gov/CSA/2024/240325.pdf

Cybersecurity and Infrastructure Security Agency, & Federal Bureau of Investigation. (2024b, September). Secure by design alert: Eliminating cross-site scripting vulnerabilities. https://www.ic3.gov/CSA/2024/240917.pdf

OWASP Foundation. (2025a). A01:2025 Broken access control. https://owasp.org/Top10/2025/A01_2025-Broken_Access_Control/

OWASP Foundation. (2025b). Introduction: OWASP Top 10:2025. https://owasp.org/Top10/2025/0x00_2025-Introduction/

OWASP Foundation. (2025c). A03:2025 Software supply chain failures. https://owasp.org/Top10/2025/A03_2025-Software_Supply_Chain_Failures/

Souppaya, M., Scarfone, K., & Dodson, D. (2022). Secure Software Development Framework (SSDF) version 1.1: Recommendations for mitigating the risk of software vulnerabilities (NIST Special Publication 800-218). National Institute of Standards and Technology. https://csrc.nist.gov/pubs/sp/800/218/final

Verizon. (2026a). 2026 Data Breach Investigations Report. https://www.verizon.com/business/resources/reports/dbir/

Verizon. (2026b, May). Breach entry point, 2026 DBIR finds. https://www.verizon.com/about/news/breach-industry-wide-dbir-finds

Should Small Businesses Block AI Crawlers in 2026?

Ryan VerWey — Tue, 18 Aug 2026 15:26:56 +0000

Originally published on echoeffect.net.

AI crawlers are no longer a side issue for publishers and large media companies. They are now part of how customers discover local services, compare businesses, ask buying questions, and decide which website is worth trusting.

That creates a practical question for small business owners: should your website allow AI crawlers, block them, or split the difference?

The short answer is this: most small businesses should allow search and user-requested AI crawlers that can send visibility back to the business, but they should be more cautious about training crawlers, unknown bots, and automated traffic that creates cost without a clear business return. The right answer is not "allow everything" or "block everything." It is a written access policy.

Short answer: If your website depends on discovery, do not blindly block every AI crawler. Separate search, agent, and training use cases, then decide what each category is allowed to do.

Why AI Crawler Access Changed in 2026

For years, the crawler bargain was easy to understand. Search engines crawled public pages, indexed them, and sent people back through organic search results. Website owners allowed crawling because the traffic was worth it.

AI search complicates that bargain. Some bots crawl to build search indexes that can cite and link to your website. Some fetch pages because a user asked an assistant a specific question. Others collect public content for model training, where the business value to the website owner is harder to measure.

Cloudflare framed this shift clearly in its July 1, 2026 update on AI traffic controls. It separated AI bot activity into three main use cases: Search, Agent, and Training. Search crawlers collect or index content so they can answer future questions. Agent traffic acts in real time on a person's behalf. Training crawlers collect content that may be absorbed into an AI model (Lee & Becker, 2026).

That distinction matters. A small business may want ChatGPT, Perplexity, Claude, or Google to cite its service pages in answers. That same business may not want every training crawler copying its full blog archive forever.

AI crawler policy should be tied to measurable visibility, traffic, server behavior, and lead quality.

The Three AI Bot Categories That Matter

Small businesses do not need to memorize every user agent on the internet. They need a decision framework.

1. Search crawlers

Search crawlers are the easiest category to justify allowing when visibility is the goal. These bots help AI-powered search products discover and cite websites.

OpenAI's crawler documentation says OAI-SearchBot is used to surface websites in ChatGPT search features. OpenAI also explains that site owners can allow OAI-SearchBot for search visibility while disallowing GPTBot for training use, because those settings are independent (OpenAI, n.d.).

Perplexity documents a similar split. PerplexityBot is designed to surface and link websites in Perplexity search results, while Perplexity-User supports user-triggered fetches when someone asks a question (Perplexity, n.d.).

For a small business website, search crawlers usually deserve access to public marketing pages, service pages, blog posts, case studies, reviews, and FAQs. Those are the pages that can earn citations, impressions, and qualified leads.

2. Agent and user-requested crawlers

Agent traffic is different from background crawling. It may happen because a real person asks an AI assistant to compare providers, summarize a service page, check pricing, or find contact information.

OpenAI says ChatGPT-User is used for certain user actions in ChatGPT and Custom GPTs, is not automatic web crawling, and is not used to determine whether content appears in search (OpenAI, n.d.). Anthropic lists Claude-User as user-directed retrieval and warns that disabling it may reduce visibility for user-directed web search (Anthropic, n.d.).

This kind of traffic can be valuable because it may happen close to a buying decision. A customer might ask, "Find a Florida web design agency that works with small businesses and understands SEO." If an assistant cannot fetch your public pages, your business may not be considered.

Agent traffic still needs guardrails. Forms, checkout flows, booking tools, and account areas should be protected from abuse. Public informational pages can usually be available.

3. Training crawlers

Training crawlers are the most sensitive category. They collect content that may be used to improve AI foundation models. That may benefit the broader AI ecosystem, but the return to an individual small business is usually indirect.

OpenAI describes GPTBot as a crawler for content that may be used in training its generative AI foundation models. Anthropic describes ClaudeBot as a crawler that collects web content that could contribute to model training (Anthropic, n.d.; OpenAI, n.d.).

Some businesses will allow training crawlers because they want maximum exposure and do not publish sensitive or proprietary material. Others will block training crawlers while keeping search crawlers open. That is a reasonable middle ground.

Robots.txt Is a Traffic Signal, Not a Security Wall

The first tool most site owners hear about is robots.txt. It is useful, but it is often misunderstood.

Google Search Central explains that robots.txt tells crawlers which URLs they can access and is mainly used to manage crawler traffic. Google is explicit that robots.txt is not a mechanism for keeping a page out of Google Search results, and private material should be protected with stronger controls such as noindex or password protection when appropriate (Google Search Central, 2025).

The limitation is important: robots.txt is a request. Respectable crawlers usually honor it. Bad or careless crawlers may ignore it.

That means robots.txt is good for:

Expressing crawler policy.
Reducing wasteful crawling.
Allowing or disallowing named AI bots.
Separating search crawlers from training crawlers when a vendor supports that split.

It is not good for:

Protecting confidential content.
Stopping hostile scraping by itself.
Blocking all bot traffic at the network level.
Guaranteeing that a disallowed URL cannot appear anywhere online.

If information should not be public, it should not be protected only by robots.txt.

What Google Says About AI Search Visibility

Google's guidance is useful because it cuts through a lot of bad advice. Google says the same foundational SEO best practices still apply to AI Overviews and AI Mode. Pages need to be crawlable, indexed, eligible for snippets, internally discoverable, useful to users, and supported by visible text, relevant media, and structured data that matches the visible content (Google Search Central, n.d.-a).

Google also says there are no extra technical requirements to appear as a supporting link in AI Overviews or AI Mode, beyond being indexed and eligible for Google Search with a snippet (Google Search Central, n.d.-a).

For crawler policy, this creates a simple rule: if you want Google Search and Google's AI features to understand a public page, do not block Googlebot from crawling it. Google says AI features in Search use Googlebot crawling controls, while snippet and preview controls such as nosnippet, data-nosnippet, max-snippet, and noindex limit what can be shown from pages (Google Search Central, n.d.-a).

That is different from Google-Extended, which Google describes separately for limiting AI training and grounding in some other Google systems (Google Search Central, n.d.-a).

The practical takeaway: do not confuse search visibility controls with training opt-out controls. They are related, but they are not the same decision.

The best AI access policy is a business decision first, then a technical configuration.

A Practical AI Crawler Policy for Small Businesses

Here is a simple starting policy for a service business that wants visibility but does not want to give away control blindly.

Allow search crawlers for public marketing content

Allow crawlers that are explicitly tied to search discovery and citation, such as Googlebot, OAI-SearchBot, PerplexityBot, and other reputable search-oriented bots, unless you have a specific reason to block them.

Public pages that should usually stay crawlable include:

Homepage.
Service pages.
About page.
Contact page.
Blog posts.
FAQs.
Case studies and portfolio pages.
Public reviews or testimonials.

These pages support SEO, AEO, and GEO because they tell search systems and answer engines who you are, what you do, where you serve customers, and why you are credible.

Consider blocking training crawlers if your content is proprietary

If your site includes original research, paid resources, detailed templates, premium guides, proprietary methods, or content you do not want used for model training, consider blocking training-specific user agents while keeping search-specific crawlers available.

This is the key nuance many businesses miss. Blocking every AI bot may reduce discoverability. Allowing every AI bot may give away more than the business intends. Splitting the policy by use case is the more mature option.

Keep user-requested fetchers available for public pages

User-requested fetchers can help assistants answer questions about your business in the moment. For a small business, that can be valuable.

The safer approach is to allow them to retrieve public content while protecting forms, private tools, admin routes, staging environments, and anything that should require authentication.

Use WAF and bot tools for enforcement

When crawler behavior becomes abusive, use stronger controls than robots.txt. A web application firewall, CDN bot management, rate limiting, and IP verification can help separate legitimate bots from spoofed user agents.

Perplexity's documentation, for example, recommends using both user-agent and official IP range conditions when configuring WAF rules for its bots (Perplexity, n.d.). That same principle applies broadly: a user-agent string alone is easy to fake.

Monitor the outcome

Crawler policy is not a one-time setting. Review it monthly or quarterly.

Watch for:

Drops in Google Search Console impressions.
Important pages disappearing from AI search citations.
Sudden spikes in bot traffic.
Server load tied to suspicious crawlers.
AI referrals that convert into leads.
Branded search growth after AI visibility.
Crawl errors caused by CDN or WAF rules.

Google says Search Console can measure performance in generative AI features and warns against relying on third-party tools that claim access to internal AI ranking systems (Google Search Central, n.d.-b). Treat your own lead data as the final test.

Where Pay Per Crawl Fits

Cloudflare introduced Pay Per Crawl in 2025 as a private beta that lets content owners allow, charge, or block AI crawler access. The system uses HTTP status code 402 Payment Required and gives publishers a way to set a price per request across a domain (Allen & Newton, 2025).

For most small businesses, this is not the first move. A local service business usually makes money from being discovered, contacted, and hired, not from charging crawlers to read its service pages.

But Pay Per Crawl matters as a signal. The web is moving toward more explicit access rules. Website owners are asking better questions:

Who is crawling my content?
What are they using it for?
Do they send users back?
Do they respect my stated preferences?
Can I measure the business return?

Those questions are healthy, even if the answer for a small business is still "allow search, monitor agents, restrict training where appropriate."

FAQ: AI Crawlers and Small Business Websites

Should small businesses block all AI crawlers?

Usually, no. Blocking all AI crawlers can reduce visibility in AI-powered search and user-requested answers. Most small businesses should separate search crawlers, user-requested agents, and training crawlers, then make a different decision for each category.

Will blocking training crawlers hurt SEO?

Not necessarily. Some vendors separate search and training crawlers. For example, OpenAI says site owners can allow OAI-SearchBot while disallowing GPTBot. The risk comes from blocking crawlers that are tied to search discovery or from blocking major search engines by mistake.

Is robots.txt enough to protect private content?

No. robots.txt is not a security control. It communicates crawler preferences, but it does not hide private material from the web. Use authentication, password protection, noindex, server rules, or access controls for content that should not be public.

Does Google require llms.txt for AI Overviews or AI Mode?

No. Google says no new machine-readable file, AI text file, special AI markup, or special schema is required to appear in AI Overviews or AI Mode. Foundational SEO still matters most: crawlability, helpful content, internal links, page experience, visible text, relevant media, and accurate structured data (Google Search Central, n.d.-a).

What should a small business do this month?

Review robots.txt, confirm public pages are crawlable, decide whether training crawlers should be allowed, check CDN or WAF rules for accidental blocks, and monitor Search Console after any access change. The goal is controlled discoverability, not panic blocking.

The Bottom Line

AI crawler access is now part of SEO, AEO, and GEO strategy. It affects whether your business can be found, cited, summarized, compared, and recommended by AI-powered search tools.

The smartest policy for most small businesses is selective access.

Allow crawlers that support search visibility. Keep public pages available to user-requested assistants. Consider limiting training crawlers when your content is proprietary or when the business return is unclear. Use robots.txt to state preferences, WAF rules to enforce suspicious traffic controls, and Search Console plus lead data to measure whether the policy is helping.

Do not let fear make your business invisible. Do not let hype make your website a free-for-all. Treat crawler access like every other digital marketing decision: define the goal, measure the return, and adjust when the data changes.

Echo Effect helps small businesses build websites that are readable by people, search engines, and AI answer systems. If your crawler policy, robots.txt file, or AI visibility strategy is unclear, schedule a discovery call and we will identify the highest-impact fixes first.

References

Allen, W., & Newton, S. (2025, July 1). Introducing pay per crawl: Enabling content owners to charge AI crawlers for access. Cloudflare. https://blog.cloudflare.com/introducing-pay-per-crawl/

Anthropic. (n.d.). Does Anthropic crawl data from the web, and how can site owners block the crawler? Claude Help Center. Retrieved July 13, 2026, from https://support.claude.com/en/articles/8896518-does-anthropic-crawl-data-from-the-web-and-how-can-site-owners-block-the-crawler

Google Search Central. (n.d.-a). AI features and your website. Google for Developers. Retrieved July 13, 2026, from https://developers.google.com/search/docs/appearance/ai-features

Google Search Central. (n.d.-b). Optimizing your website for generative AI features on Google Search. Google for Developers. Retrieved July 13, 2026, from https://developers.google.com/search/docs/fundamentals/ai-optimization-guide

Google Search Central. (2025, December 10). Robots.txt introduction and guide. Google for Developers. https://developers.google.com/search/docs/crawling-indexing/robots/intro

Lee, J.-H., & Becker, B. (2026, July 1). Your site, your rules: New AI traffic options for all customers. Cloudflare. https://blog.cloudflare.com/content-independence-day-ai-options/

OpenAI. (n.d.). Overview of OpenAI crawlers. OpenAI Developers. Retrieved July 13, 2026, from https://developers.openai.com/api/docs/bots

Perplexity. (n.d.). Perplexity crawlers. Perplexity Docs. Retrieved July 13, 2026, from https://docs.perplexity.ai/docs/resources/perplexity-crawlers

Interop 2026 Website Upgrades for Small Businesses

Ryan VerWey — Tue, 18 Aug 2026 15:26:52 +0000

Originally published on echoeffect.net.

Interop 2026 is one of the most practical web development stories of the year because it is not about one framework, one browser, or one vendor. It is about making important web platform features work more consistently across Chrome, Edge, Firefox, and Safari.

For small businesses, that matters more than it sounds. Browser inconsistency turns into expensive rework, broken forms, awkward mobile menus, glitchy popups, unreliable animations, and website features that behave differently for different customers.

As of July 6, 2026, the smart move is not to chase every new feature. The smart move is to modernize around features that are becoming reliable, supported, and useful for real customer journeys.

Short answer: Interop 2026 helps browser teams improve the same high-priority web features during the same year. Small businesses should use it as a signal to plan safer upgrades for menus, dialogs, page transitions, responsive layouts, mobile behavior, accessibility, and AI-search-ready content.

What Is Interop 2026?

Interop 2026 is a coordinated cross-browser effort run by representatives from major browser engine contributors, including Apple, Google, Igalia, Microsoft, and Mozilla. The project selects focus areas that matter to developers and users, then tracks browser progress through automated Web Platform Tests (Andrew, 2026; Web Platform Tests, 2026).

The 2026 focus areas include features such as anchor positioning, container style queries, dialogs and popovers, view transitions, scroll-driven animations, scroll snap, web compatibility fixes, WebRTC, WebTransport, and mobile testing work (Web Platform Tests, 2026; Wu & Simmons, 2026).

That list may sound technical, but the business outcome is simple: websites should be easier to build once and trust across modern browsers.

That is especially useful for small business sites because customers do not care which browser caused a bug. If a menu fails on iPhone, a booking form shifts on Android, or a modal traps keyboard focus on desktop, the business owns the bad experience.

Why Baseline Belongs in the Same Conversation

Interop is about improving cross-browser consistency. Baseline is about knowing when a web platform feature is ready to use.

web.dev explains that Baseline gives developers clear information about which features are supported across the core browser set: Chrome, Edge, Firefox, and Safari on desktop and mobile. A feature can be "newly available" when all core browsers support it, then "widely available" after 30 months have passed (Google Chrome Developers, n.d.).

For a business owner, Baseline is useful because it turns a vague question into a practical one.

Instead of asking, "Can our website use this new feature?" ask:

Is it Baseline?
Is it supported by the browsers our customers actually use?
Does it improve conversion, accessibility, performance, or maintenance?
Can we ship it without adding heavy JavaScript?
Can we keep a simple fallback for older browsers?

That mindset prevents two common mistakes: using outdated techniques forever because they feel safe, or adopting new features too early because they feel exciting.

Modern web upgrades should reduce complexity, not add it. Interop and Baseline help teams choose native browser features with stronger support.

The Small Business Website Upgrades Worth Watching

Not every Interop 2026 focus area belongs on a brochure site. A small business website does not need experimental complexity to look modern. It needs dependable navigation, clear content, fast pages, usable forms, accessible interactions, and crawlable answers.

These are the areas most likely to matter.

1. Better Popups, Dialogs, and Menus

Dialogs and popovers are part of the Interop 2026 focus list. The work includes improvements around the <dialog> element and Popover API, including open states and behavior for subordinate popovers (Andrew, 2026).

That matters because many websites still use custom JavaScript for dropdowns, modals, tooltips, announcement bars, cookie notices, quote prompts, and mobile navigation. Custom overlays are easy to get wrong. They can trap focus, block content, fail screen readers, or create layout shifts.

Native browser primitives can reduce that risk when used carefully. For small businesses, the priority should be practical:

Mobile menus that open and close predictably.
Quote request popups that do not block the whole page.
Tooltips that support keyboard and touch users.
Cookie notices that do not cover important actions.
Form dialogs that keep focus where users expect it.

The goal is not to add more popups. The goal is to make necessary overlays less fragile.

2. More Reliable Responsive Layouts

Container style queries and anchor positioning are also Interop 2026 focus areas. Container style queries let styles respond to a container's properties rather than only the viewport. Anchor positioning lets one element be positioned relative to another, such as placing a tooltip beside the field it explains (Andrew, 2026; Web Platform Tests, 2026).

For small business websites, this can make component design more reliable. Service cards, pricing tables, testimonial blocks, FAQ sections, and lead forms often appear in different layouts across the site. A component that adapts based on its own container can be easier to reuse without layout hacks.

That can improve maintainability and page speed. When native CSS handles layout decisions, a site may need less JavaScript and fewer brittle breakpoints.

3. Cleaner Page Transitions

View transitions continued from prior Interop work into 2026. WebKit notes that cross-document view transitions can create smoother animated transitions between pages, reducing abrupt jumps when users navigate a site (Wu & Simmons, 2026).

This is not a license to animate everything. Overdone motion hurts usability.

Used carefully, page transitions can make service pages, galleries, product pages, and portfolio pages feel smoother without turning the site into a heavy app. They can also help preserve orientation when users move through related pages.

The practical rule is simple: motion should clarify the experience. If it distracts from the call to action, remove it.

4. Stronger Mobile Testing

Interop 2026 includes mobile testing as an investigation area. WebKit specifically points to mobile-specific infrastructure work for dynamic viewport changes, which are crucial for responsive mobile web experiences (Wu & Simmons, 2026).

That matters because small business traffic often comes from mobile moments: someone needs a quote, checks reviews, looks up hours, compares services, or tries to tap a phone number.

A mobile site should pass these checks:

The first screen explains what the business does.
The primary action is visible and easy to tap.
Forms do not jump when the keyboard opens.
Sticky headers do not hide content.
Menus work with touch, keyboard, and screen readers.
Images are sharp but not oversized.
Contact information is crawlable text.

Mobile is not a smaller desktop site. It is often the main sales path.

How This Supports SEO, AEO, and GEO

Interop and Baseline are web development topics, but they directly affect search visibility.

Google Search Central says Core Web Vitals measure real-world user experience for loading performance, interactivity, and visual stability. Google recommends good Core Web Vitals for Search and general user experience, with LCP at 2.5 seconds or faster, INP under 200 milliseconds, and CLS below 0.1 (Google Search Central, 2025).

Modern native features can help when they replace heavy scripts, reduce layout hacks, and make pages easier to interact with. Faster, more stable pages support SEO because users and crawlers can access content with less friction.

They also support AEO and GEO.

Google's guidance for AI features in Search says existing SEO fundamentals remain relevant for AI Overviews and AI Mode. Site owners should allow crawling, make content easy to find through internal links, provide a good page experience, keep important content available in text, support content with useful images and videos, and make sure structured data matches visible text (Google Search Central, n.d.).

That means an AI-ready website still needs old-fashioned discipline:

Clear HTML content.
Descriptive headings.
Useful internal links.
Fast pages.
Accurate structured data.
Real author attribution.
Original answers to customer questions.
Images that support the page topic.

The future of search is not only about prompts. It is also about whether your website gives machines and people clean, trustworthy information.

The best website upgrades connect platform changes to measurable outcomes: faster pages, clearer answers, better leads, and fewer browser-specific bugs.

A Practical Upgrade Checklist

Use this checklist before adding new web platform features to a small business website.

Audit the Browser Risk

Check analytics to see the browsers, devices, and operating systems your customers actually use. A feature that works well for a developer's desktop setup may still need testing on Safari for iOS, Chrome for Android, Edge on Windows, and Firefox.

Prefer Baseline Features

Start with features marked Baseline when possible. If a feature is newly available, test it carefully and provide a fallback. If it has limited availability, avoid using it for essential conversion paths unless there is a strong reason.

Replace JavaScript Only When the Native Feature Is Better

Native does not automatically mean better. A native dialog used poorly is still a poor experience. The right test is whether the change improves performance, accessibility, maintainability, or user clarity.

Test the Money Pages First

Do not limit compatibility testing to the homepage. Test the pages that create business value:

Primary service pages.
Contact page.
Quote request forms.
Booking pages.
Paid ad landing pages.
Blog posts that attract search traffic.

If the homepage works but the lead form fails, the site still fails.

Keep Content Visible as Text

Do not hide important service details inside images, animations, tabs that never render server-side, or scripts that crawlers may struggle to process. If the information matters to customers, write it as visible text.

Measure Before and After

Before shipping upgrades, record Core Web Vitals, crawlability, form completion behavior, and conversion rates. After shipping, measure again. A modern implementation that worsens INP or lead flow is not an upgrade.

FAQ: Interop 2026 and Small Business Websites

Does Interop 2026 mean every browser supports the same features now?

No. Interop 2026 is an active effort to improve selected focus areas during 2026. Use it as a planning signal, then verify current browser support before shipping important features.

Is Baseline the same as Interop?

No. Interop coordinates browser work on high-priority focus areas. Baseline helps developers understand whether a feature is ready to use across the core browser set.

Should a small business redesign its website because of Interop 2026?

Not automatically. Interop 2026 is a reason to review outdated patterns and plan safer upgrades. A redesign makes sense when your current site is slow, hard to update, difficult to use on mobile, or unreliable across browsers.

Which upgrades are most useful for lead generation?

Focus on reliable mobile navigation, faster pages, accessible dialogs, stable forms, clear service content, and crawlable FAQ sections. Those improvements support both customer experience and search visibility.

Do AI search tools care about modern browser features?

AI search tools care most about accessible, crawlable, helpful content. Modern browser features help when they make content easier to reach, reduce friction, improve page experience, and keep important information available as text.

The Bottom Line

Interop 2026 is a reminder that the web platform keeps improving, and small business websites should not be frozen in old patterns forever.

The right approach is selective modernization. Use Baseline to choose safer features. Use Interop 2026 to understand where browser reliability is improving. Test the customer journey on real devices. Measure Core Web Vitals. Keep service information visible, structured, and easy to cite.

That combination supports SEO, AEO, and GEO because it gives search engines, answer engines, AI systems, and customers the same thing: a fast, trustworthy website that clearly explains what the business does and how to take the next step.

References

Andrew, R. (2026, February 12). Interop 2026: Continuing to improve the web for developers. web.dev. https://web.dev/blog/interop-2026

Google Chrome Developers. (n.d.). Baseline. web.dev. https://web.dev/baseline

Google Search Central. (n.d.). AI features and your website. Google for Developers. https://developers.google.com/search/docs/appearance/ai-features

Google Search Central. (2025, December 10). Understanding Core Web Vitals and Google search results. Google for Developers. https://developers.google.com/search/docs/appearance/core-web-vitals

Web Platform Tests. (2026). Interop 2026. GitHub. https://github.com/web-platform-tests/interop/blob/main/2026/README.md

Wu, Y., & Simmons, J. (2026, February 12). Announcing Interop 2026. WebKit. https://webkit.org/blog/17818/announcing-interop-2026/

Core Web Vitals Checklist for Small Business Websites

Ryan VerWey — Tue, 18 Aug 2026 15:26:18 +0000

Originally published on echoeffect.net.

Core Web Vitals are still one of the clearest ways to tell whether a small business website feels fast, stable, and easy to use. They are not the whole SEO story, but they are a practical signal because they measure what real visitors experience: loading speed, responsiveness, and visual stability.

As of June 29, 2026, the three Core Web Vitals that matter most are Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift. Google recommends checking those metrics at the 75th percentile of page loads, segmented across mobile and desktop visits (Google Search Central, n.d.; Walton, 2024).

For small businesses, this is not just a technical scorecard. A slow homepage can waste ad spend. A sticky navigation menu can frustrate mobile visitors. A jumpy contact form can cost leads. A page that loads poorly can also weaken the clarity signals that search engines, answer engines, and AI crawlers use to understand and cite your site.

Short answer: Aim for LCP at 2.5 seconds or faster, INP at 200 milliseconds or faster, and CLS at 0.1 or lower. Then test the actual lead path, not only the homepage.

What Core Web Vitals Measure

Core Web Vitals are a subset of Google's broader Web Vitals program. They focus on three user experience questions:

How quickly does the main content load?
How quickly does the page respond after someone interacts?
Does the layout stay stable while the page loads?

Largest Contentful Paint, or LCP, measures loading performance. A good LCP is 2.5 seconds or faster. Interaction to Next Paint, or INP, measures responsiveness after user input. A good INP is 200 milliseconds or faster. Cumulative Layout Shift, or CLS, measures unexpected visual movement. A good CLS is 0.1 or lower (Walton, 2024).

Those numbers matter because they turn vague complaints into specific action. "The site feels slow" becomes "the hero image is pushing LCP past 4 seconds on mobile." "The form feels laggy" becomes "the first tap is waiting on heavy JavaScript." "The page jumps" becomes "images and embedded widgets do not reserve space before loading."

Core Web Vitals are useful because they connect technical decisions to visible customer experience: faster pages, steadier layouts, and smoother interactions.

Why This Matters for SEO, AEO, and GEO

Google's page experience guidance says Core Web Vitals are part of evaluating page experience, alongside factors such as mobile usability, HTTPS, and avoiding intrusive interstitials. Google also makes clear that helpful content remains central, but a good page experience can help content perform better when pages are otherwise similar (Google Search Central, n.d.).

That is the SEO layer. The answer engine optimization and generative engine optimization layers are just as important.

Answer engines need clean, readable pages that directly answer questions. Generative AI systems need content that is crawlable, structured, accurate, and easy to parse. Google's guidance for AI features says site owners should continue following search fundamentals, make important content available in text, keep structured data aligned with visible content, and support content with useful images or video where appropriate (Google Search Central, n.d.).

Core Web Vitals do not guarantee AI citations. They do make your content easier to access and trust. A fast, stable, crawlable page with clear headings, direct answers, and real sources is more citation-friendly than a slow page buried behind layout shifts and heavy scripts.

For the broader search strategy, pair this checklist with the Google Search Console guide, the answer engine optimization guide, and the generative engine optimization guide.

The 2026 Core Web Vitals Checklist

Use this checklist when reviewing a small business website, especially before redesigning, buying ads, or publishing a new service page.

1. Test Real Field Data First

Start with field data, not lab data. Field data reflects real users, devices, networks, and pages. Google's PageSpeed Insights reports field data from the Chrome User Experience Report when enough data is available, plus lab diagnostics from Lighthouse (Google PageSpeed Insights Team, n.d.).

Check:

Homepage.
Primary service pages.
Contact page.
Blog posts that bring organic traffic.
Landing pages used for ads.
Product or booking pages if the site has them.

The homepage may pass while a money page fails. Do not stop after one URL.

2. Fix LCP by Prioritizing the Main Content

LCP usually points to the largest visible element in the first viewport. On small business websites, that is often a hero image, heading block, background image, or large service-card section.

Common LCP fixes include:

Compress and resize hero images.
Use modern image formats such as WebP or AVIF when possible.
Avoid loading huge desktop images on mobile.
Preload the most important above-the-fold image when appropriate.
Reduce slow server response time.
Remove render-blocking scripts and styles where practical.
Keep the first viewport focused, not overloaded with sliders, videos, and popups.

For many local business sites, the biggest win is simple: use one strong hero image, size it correctly, and avoid making the browser download five decorative assets before the visitor can read the offer.

3. Fix INP by Reducing JavaScript Pressure

INP replaced First Input Delay as a Core Web Vital because it measures responsiveness across the full page visit, not only the first interaction. web.dev explains that INP observes interactions such as clicks, taps, and keyboard input, then reports a high-percentile interaction latency for the page (Wagner & Pollard, 2025).

Poor INP often comes from too much JavaScript competing for the main thread. That can happen when a site loads heavy tracking tags, chat widgets, animation libraries, booking embeds, cookie banners, or large client-side frameworks on pages that do not need them.

Improve INP by asking:

Does this script help the visitor complete the task?
Does it need to load on every page?
Can it load after the main content?
Can this interaction be simpler?
Can server-rendered HTML replace client-side rendering?

This matters for conversions. A visitor who taps "Request a Quote" should not wait because the browser is busy running a carousel script, three trackers, and an unused animation bundle.

4. Fix CLS by Reserving Space

CLS is about unexpected movement. It usually shows up when images, ads, embeds, fonts, banners, or late-loading content shift the page after the visitor has started reading or tapping.

Common CLS fixes include:

Set width and height for images and videos.
Reserve space for review widgets, maps, forms, and embedded calendars.
Avoid injecting banners above existing content after load.
Use font loading strategies that prevent dramatic text reflow.
Keep sticky headers and mobile menus predictable.
Test the page on real mobile widths, not only a desktop browser.

CLS is especially important on lead forms. If the submit button moves while someone is trying to tap it, that is not a minor design issue. It is a conversion problem.

Performance work should include the full customer journey: landing page, service details, contact form, confirmation page, and follow-up tracking.

5. Audit Third-Party Tools Like Business Costs

Small business sites often collect third-party tools over time: analytics, heatmaps, chat widgets, booking tools, review embeds, social feeds, CRM forms, ad pixels, and cookie consent scripts.

Some are worth it. Some are silently slowing down the site.

Review each tool with four questions:

Does it support revenue, measurement, compliance, or customer service?
Is it still used by the business?
Does it need to load on every page?
Is there a lighter way to achieve the same result?

Performance best practice is not "remove every script." It is "make every script justify its place."

6. Keep Mobile as the Default Test Case

Most small business searches start in impatient moments: someone needs a contractor, restaurant, consultant, repair service, clinic, or local expert. They are often on a phone, using a cellular connection, and comparing options quickly.

That means mobile performance deserves priority.

Check whether:

The first viewport explains what the business does.
The main call to action is easy to tap.
The phone number or contact path is visible.
Text is readable without zooming.
Menus respond quickly.
Forms are short and stable.
Images are sharp but not oversized.

Good mobile performance supports SEO, but it also supports the basic sales path. People do not wait patiently for a slow site when competitors are one tap away.

AEO and GEO Formatting Tips for Performance Pages

Technical performance content can become too vague for AI systems to summarize well. Structure matters.

For service pages and blog posts, use:

Direct answers near the top of the page.
Clear H2 and H3 headings.
Short definitions for LCP, INP, and CLS.
Specific thresholds and dates.
Step-by-step checklists.
Internal links to related SEO and web design resources.
APA-style references for factual claims.
Descriptive image alt text.

That format helps human readers skim, helps search engines classify the page, and helps AI systems extract accurate answers.

FAQ: Core Web Vitals for Small Businesses

Do Core Web Vitals directly affect Google rankings?

Core Web Vitals are part of Google's page experience signals. They are not a substitute for helpful content, relevance, authority, or local trust, but they can matter when users and search systems compare similar pages.

What score should a small business website aim for?

Aim for LCP at 2.5 seconds or faster, INP at 200 milliseconds or faster, and CLS at 0.1 or lower at the 75th percentile of page loads. Check both mobile and desktop.

Is PageSpeed Insights enough?

PageSpeed Insights is a strong starting point, especially when it has field data. For a fuller picture, also check Search Console's Core Web Vitals report, Lighthouse diagnostics, analytics behavior, and real lead-flow testing.

Should I redesign my website if Core Web Vitals are poor?

Not always. Some sites need targeted fixes: better images, fewer scripts, cleaner hosting, or reserved layout space. A full redesign makes sense when the site is structurally slow, hard to maintain, or failing the customer journey.

How often should Core Web Vitals be checked?

Check monthly, after major content or design changes, and before spending heavily on ads. Also check after adding third-party scripts such as chat, booking, reviews, analytics, or social embeds.

The Bottom Line

Core Web Vitals are not vanity metrics. They are a practical way to measure whether your website is fast enough, responsive enough, and stable enough for real customers.

For small businesses, the best approach is focused: test the pages that make money, fix the biggest blockers first, keep mobile users in mind, and remove scripts or design choices that do not support the customer journey.

Strong SEO, AEO, and GEO all start with the same foundation: helpful content on a website that people and crawlers can access without friction. If your site is slow, jumpy, or frustrating on mobile, a Core Web Vitals audit is one of the highest-value technical reviews you can run this year.

References

Google PageSpeed Insights Team. (n.d.). About PageSpeed Insights. Google for Developers. https://developers.google.com/speed/docs/insights/v5/about

Google Search Central. (n.d.). Understanding page experience in Google Search results. Google for Developers. https://developers.google.com/search/docs/appearance/page-experience

Google Search Central. (n.d.). AI features and your website. Google for Developers. https://developers.google.com/search/docs/appearance/ai-features

Wagner, J., & Pollard, B. (2025, September 2). Interaction to Next Paint (INP). web.dev. https://web.dev/articles/inp

Walton, P. (2024, September 17). Web Vitals. web.dev. https://web.dev/articles/vitals