DEV Community: Uriel Bitton

SaaS Role Permission Testing: Share a Matrix Before Asking Peers to Try Your Demo

Uriel Bitton — Mon, 09 Nov 2026 14:55:16 +0000

For SaaS role permission testing, define the expected action for each account and resource before inviting feedback on a public demo. Rehearse the task with separate test accounts, check the stored result and publish only the narrow behavior you actually verified. A viewer failing to find an edit button is useful interface feedback, but it does not establish that unauthorized edits are blocked.

Building in public can help you find people willing to question an access rule or try a confusing workflow. Give them a test they can interpret. “Try the app and tell me if permissions work” leaves both the permitted task and the expected result undefined.

The following workflow uses a fictional document-review SaaS. It is a proposed test plan, not a report of testing Buildside or another live product. Perform checks only in systems and disposable workspaces you own or are explicitly authorized to test.

Write the role and resource matrix first

Start with the smallest useful set of actions. The fictional app has documents inside workspaces. An editor can read and change documents in their workspace. A viewer can read those documents but cannot change them. Neither role can read another workspace's private documents.

Write each rule with a resource context. “Editor can edit” is incomplete. It leaves open whether the rule applies to every document, only assigned documents or everything in one workspace. A role label alone does not express the whole relationship.

For the example, the initial matrix contains four cases: viewer reads a document in their workspace; viewer attempts to change that document; editor changes that document; editor requests a private document in a separate test workspace. The first and third should succeed. The second and fourth should be denied.

Keep the expected result explicit. For a denied edit, the stored document must remain unchanged. For a denied read, the response must not contain the protected document. An error banner alone is insufficient evidence of either result.

The OWASP authorization testing automation guide describes expressing roles, services and test inputs in an authorization matrix. You do not need to adopt its sample implementation to use the underlying discipline: describe the allowed combinations before evaluating behavior.

Separate account identity from authorization

Prepare an editor account and a viewer account with different test identities. Keep their sessions separate so you can tell which one performed the action. A convenient administrator session should not stand in for either participant.

The OWASP authorization guidance distinguishes authentication from authorization. Signing in establishes identity; it does not mean every action is permitted. Its recommendations include checking permissions on every request and denying access by default.

For your rehearsal, record the account's role, workspace membership and document relationship. Also record the product version and relevant configuration. If you change a membership halfway through, that is a new condition, not a continuation of an identical test.

Use synthetic documents with obvious markers. For example, the original body can contain a fictional task description, and an attempted edit can add a distinctive test phrase. This makes it easier to check whether a denied operation changed anything without involving real customer material.

Run the permitted task before the denied task

Begin by confirming that the viewer can perform the intended read task. Can they open the document, understand that they are viewing it and find what they are allowed to do next? A secure but unusable screen still needs product work.

Then inspect the attempted edit condition. The interface may omit the edit control, show a disabled control or explain that another role is required. Ask a peer to describe what they believe their account can do. Their interpretation tests the communication of the rule.

Separately, use your authorized development test setup to verify enforcement at the request boundary. A hidden button is not that boundary. Check the response and the resulting stored document for the same action under the viewer's actual identity.

Run the corresponding editor case against the same synthetic document. If neither account can save because the test environment is broken, the viewer's failure tells you little about the permission rule. You need the successful comparison to interpret the denied condition.

Check the resource boundary as well as the button

Now use the second disposable workspace. Give it a private synthetic document whose marker differs from the first. Test that the editor from the first workspace cannot read it under the stated rule.

Keep this within your own authorized test environment. Do not invite public testers to enumerate accounts, guess other people's document identifiers or investigate production access. A useful community exercise can be narrow without exposing unrelated people to risk.

If you discover that an unauthorized action succeeds, stop the public demonstration of that path. Fix the issue and verify the boundary before sharing a reproduction that would enable misuse. Your public progress note can explain that a permission assumption needs repair without exposing operational details.

Also look for partial disclosure. A blocked document page might still display a private title, preview or attachment in another part of the interface. Your expected outcome should specify which information is allowed to appear, rather than treating one denied request as a verdict on the whole product.

Give founder peers an interpretable request

Once your own checks pass, prepare a small public review packet: the fictional task, the role being demonstrated, the expected result and the specific question you want answered. Include a screenshot or recording only if it contains safe test data.

A request could say: “This is the viewer flow in a fictional document workspace. The account can read, but cannot edit. Where does the page leave you uncertain about what to do next?” That invites interface feedback without asking volunteers to certify your security.

If you want a second developer to review the matrix, ask which relevant combinations are missing. They may point out attachment access, a changed membership or a document that moved between workspaces. Those suggestions improve the plan; they do not prove the missing cases pass.

Buildside is a founder community for public work. Wherever you ask, explain which part of the test is available to peers and which enforcement checks remain your responsibility. Do not describe a general comment as a completed independent audit.

Save evidence that survives the demo

Keep a short record for each case: initial document marker, acting account and relationship, requested action, observed response and final stored state. Mark a case untested if you did not run it. A tidy matrix full of assumed passes is less useful than a small matrix with honest gaps.

For interface feedback, save the participant's interpretation separately from the enforcement result. “The viewer thought they could request access” and “the viewer's update was denied with no stored change” answer different questions. Both can inform the next release.

If a condition changes, repeat the affected cases. A new attachment route or membership rule may introduce a path your earlier check did not cover. Avoid claiming that an old recording verifies a later version.

You can turn confirmed cases into regression tests through your project's established process. The article's manual rehearsal is a way to clarify expected behavior, not a substitute for a maintained authorization test suite or an appropriate security review.

Publish the boundary and the remaining question

An accurate build-in-public update names the checked scope. For the fictional app, that might be the viewer read/edit distinction and the separate-workspace read boundary in one test version. It should also name important cases that remain outside the check.

Show what the feedback changed: perhaps the page now explains why editing is unavailable, or the matrix now includes attachment access. Keep the distinction between a clearer interface and stronger enforcement visible in the follow-up.

Before inviting people into your next demo, ask whether a reviewer can identify the acting role, the resource, the expected result and the evidence of the final state. If those are clear, the conversation can move beyond “seems to work” toward a useful product decision.

Hey I'm Uriel Bitton. I write about building in public strategies and growing startups.

Subscribe for more stories on growing your audience by building in public.

Join us on Buildside: the social network for founders building in public.

Sources

Stale JavaScript in Google’s Render? Check the Asset Fingerprint

Uriel Bitton — Mon, 09 Nov 2026 14:34:42 +0000

If Google's rendered page still shows an old answer after a JavaScript deployment, check which script file the public HTML references and which version the rendered output used. A changed source file in your repository does not prove the current page requests a new asset URL.

Google recommends content fingerprinting for JavaScript and CSS resources. In practice, that means a content change produces a different filename. The diagnostic task is to trace the reference, confirm the file exists, and inspect the resulting answer. Adding a random version label to a page is not enough.

This guide follows a fictional documentation update. It is a proposed debugging method, not a report that a real website or Google rendering test was run.

Understand the documented caching risk

Google's JavaScript SEO documentation says Googlebot caches aggressively and its Web Rendering Service may ignore caching headers. That can result in outdated JavaScript or CSS resources being used. Google recommends a content fingerprint in the filename so a changed resource gets a new filename.

The Web Rendering Service, often shortened to WRS, is the rendering component discussed in that guidance. Keep the claim scoped to Google's documented behavior. It does not establish how every AI crawler or browser caches scripts, and it does not prove caching caused the particular stale answer you are investigating.

Use the documented risk to form a testable hypothesis: the live HTML may still point to an asset whose URL did not change when its contents changed. Preserve competing explanations, including old HTML, an outdated data response, or a failed deployment. The next checks should narrow that list.

Follow a fictional documentation update

Imagine a public setup guide whose answer changes from “administrators only” to “administrators and editors.” In this invented example, a client-side script supplies the eligibility sentence. The team updates the script but continues publishing it at the same filename, guide.js.

A developer sees the new sentence in a freshly loaded browser. A later rendering observation still shows the old sentence. These are fictional observations illustrating the investigation. They do not establish that a fresh browser view and a Google rendering view will always differ this way.

Start by recording the URL, the deployment identifier, the exact old and new sentences, and the time of each observation. Then preserve the public HTML's script references. If the deployed page still requests guide.js, the team has a specific reference to investigate. If it requests a new fingerprinted file, follow that file rather than assuming the earlier naming mistake remains the active cause.

Inspect the public reference rather than the build folder

A local build can produce correctly fingerprinted assets while an old HTML document still references a previous release. Check the document delivered at the public URL. Record the script URLs it requests and compare them with the deployment's asset manifest or equivalent build output.

Use a small reference chain: public page, referenced script, rendered eligibility sentence. Each link in that chain answers a different question. The manifest says what the build intended to publish. The public document says what a recipient is being instructed to load. The rendered output says what content appeared in the inspected run.

Do not expose private build configuration or credentials in an SEO ticket. Usually the public asset path, deployment identifier, and a short content excerpt are enough to explain the mismatch. Keep complete diagnostic records in the team's appropriate private location when they contain internal details.

Check that the new filename represents new content

Content fingerprinting ties the filename to the file's contents. It is useful because a meaningful file change creates a different resource address. If a pipeline keeps the old filename while replacing the contents, it has not applied the approach Google describes for this problem.

In the fictional guide, a new build might reference guide.a72c.js instead of guide.19bf.js. Those names are illustrative. Confirm that the public HTML points to the intended file and that the file can be fetched through the normal public path. A new reference to a missing file creates a different failure.

Check the relevant module or generated content inside the deployed asset using approved inspection tools. Do not rely only on a filename that looks new. A configuration error can publish a new asset name with the wrong source content. The repair needs agreement between the reference and the actual answer it produces.

Deploy the document and its assets as a coherent release

A page and its dependencies need to agree during deployment. If new HTML points to files that are not available yet, readers may receive a broken page. If an old document remains available, it may continue requesting older assets. Inspect the project's established deployment behavior before proposing changes.

Keep older assets available for as long as the site's legitimate document versions can reference them, according to the project's release and retention policy. Do not delete a previous build's files simply because a new build finished. That is an engineering recommendation about dependency consistency, not a statement that Google requires one universal retention period.

When writing the issue, name the actual boundary that failed. “The public HTML still references the previous script” is more actionable than “Google ignores our updates.” It also gives the deployment owner a concrete condition to reproduce and verify without requiring access to the whole content strategy.

Compare the resulting answer under recorded conditions

After the repair, inspect the public page and record the script reference again. Then inspect the relevant rendered output using the appropriate native testing workflow. Google's documentation points to rendered HTML as the place to check what is visible after rendering. Keep the timestamp and the specific tool used with that observation.

Search for the complete eligibility sentence, including its limiting condition. Seeing the word “editors” somewhere in the page is weaker evidence than seeing the intended answer in the correct section. Also check that the sentence remains connected to its product and task so the updated passage is meaningful to a reader.

If the output remains stale, do not keep changing filenames at random. Revisit the chain. Is the document old? Is the requested file correct? Does a separate data request supply the sentence? Did rendering fail before the component finished? Record the observed break and investigate that layer. A fingerprint addresses asset identity; it cannot repair every content or rendering failure.

Close the delivery issue without overstating visibility

A useful completion note could say: “The public setup page references the current fingerprinted script, the asset loads, and the inspected rendered HTML contains the revised eligibility sentence.” Include the page URL, asset URL, deployment identifier, inspection method, and time. This is a proposed format for reporting a real check.

It does not establish that Google's stored search result has updated, that a page has gained rankings, or that an AI answer now cites it. Those outcomes need separate evidence. A live rendering inspection and a historical indexed observation may describe different moments in the page's lifecycle.

For an AI-answer follow-up, retain the exact prompt, engine, mode, date, answer, and linked sources. Check whether the updated eligibility condition survives in the response. A brand mention alone does not confirm the page was cited, and a citation alone does not confirm the condition was summarized accurately.

The practical outcome is a traceable content version. Your team should be able to explain which public document requested which asset and what answer the inspected output contained. That makes the next SEO or AI visibility question much easier to investigate with evidence.

Hey I'm Uriel Bitton. I write about SEO, AEO, GEO, and helping brands get found in AI answers.

Subscribe for practical ways to grow your brand's visibility in search and AI answers.

Explore HoneyWeRank for SEO and AI visibility.

Sources

Google Search Central: JavaScript SEO basics, including content fingerprinting and rendered HTML

Offline UX Testing: Disconnect During the Task in Your Public SaaS Demo

Uriel Bitton — Sun, 08 Nov 2026 17:16:09 +0000

Test offline UX by interrupting a real task, inspecting what the interface knows about the attempted change, and checking the resulting record after reconnecting. An offline banner alone cannot tell a reviewer whether a request never left the browser, reached the server without a visible response, or remains unresolved. Make those differences part of the public demo.

For a developer building in public, this gives peers a useful behavior to inspect. A recording that starts after the connection has recovered can hide the moment a user must decide whether to wait, retry or leave. That decision is where the demonstration should spend its time.

The document-sharing product below is fictional. The suggested test cases are a rehearsal plan, not results from a tested application. Use an isolated test account and sample records. Keep any disruptive network change limited to the test setting you control.

Name the task and the expected shared result

Imagine a product where a project lead shares a brief with a teammate. The lead changes the brief and submits it. The teammate should later see the intended version once, with the correct status. This is the task the two observers will inspect.

Write the expected result before changing connectivity. Decide what counts as the submitted version and which screen can confirm it. The lead's editor, a confirmation message and the teammate's view may reveal different things. Do not silently use whichever one looks most reassuring.

Give the sample brief a harmless distinctive phrase so observers can identify the version. Record the starting state in both accounts. A second observer is useful because the person pressing Submit may otherwise judge success entirely from the screen that made the attempt.

Keep the first run small. One brief and one attempted submission are easier to reason about than a busy workspace with several pending edits. You can introduce overlapping actions later, once you can describe what happened in the simpler case.

Treat connectivity indicators as hints

MDN's navigator.onLine documentation explains that browsers use different heuristics for online status and that a network connection may exist without internet access. It cautions against treating that property as reliable proof of connectivity. A visible indicator needs limits just as a public claim does.

In the fictional product, a browser reporting online would not prove that a particular submission succeeded. The relevant service could still be unreachable or the response could be delayed. An indicator can help explain a possible problem while the application handles the actual operation's outcome.

Describe the test condition precisely. A browser's offline simulation, disabling a local connection and making one service unavailable are different interventions. A successful rehearsal under one condition does not establish that every network failure produces the same behavior.

For a public walkthrough, state which condition you used and when you introduced it. Keep internal addresses and private request details out of the recording. Peers need enough context to assess the behavior, rather than an unfiltered log of your environment.

Separate the case where nothing was sent

Begin one rehearsal with the test browser already offline. Attempt the submission and inspect the interface. Does it preserve the text? Does it explain whether any action is waiting? Can the observer tell which parts remain local to this device?

If the product supports a queue, identify what is actually queued and how the user can inspect it. If it does not support offline submission, make the available next step understandable. Do not display a completion message merely because the click was accepted by the interface.

Ask the second observer to check the starting brief independently. The expected finding in this particular rehearsal may be that it has not changed, but inspect it rather than assuming. This creates a clear comparison between the attempted local action and the shared record.

Write down the visible state before reconnecting. Otherwise, a fast recovery can erase the confusing message you wanted feedback on. The useful record includes what the user could reasonably understand while the connection was absent.

Rehearse a submission whose outcome is uncertain

Now consider a different case: the request may have left the browser before the connection is interrupted. The interface has not received a usable confirmation. From the lead's point of view, that is an uncertain outcome, not sufficient evidence that the server did nothing.

Choose a controlled way to rehearse that boundary in your test setup. Record the timing you can observe, and acknowledge anything you cannot establish. If your setup only simulates a failed request before sending, do not describe it as a lost-response test.

Look closely at the recovery choices. A large Retry button can appear helpful while leaving the user uncertain about duplication. Inspect what happens when the offered action is used. Does the shared record contain the intended result, an extra submission, an older version or no change?

Keep the public claim tied to that observation. You can report that a particular retry produced one visible submission in this test. You cannot conclude that every timing condition is safe, or that the behavior holds for other operations you did not attempt.

Give the observer a decision to make during the uncertainty. Ask whether they would press the offered recovery control, keep waiting or leave the page, and what message led them there. Record that explanation before revealing the eventual outcome. A message can become obvious in hindsight while remaining unhelpful at the moment the user must act. This separates the clarity of the recovery choice from whether the particular request eventually completed.

Check reconciliation after the connection returns

Reconnect and watch the transition before refreshing. Does the interface distinguish waiting, retrying, confirmed and failed work in a way that fits its actual behavior? A disappearing banner should not be the only clue that the operation has reached a conclusion.

Then inspect the shared record from the teammate's account. Compare the distinctive phrase, the version and any relevant status with the intended result. This check answers a different question from whether the lead's screen looks complete.

If the product allows continued editing while a submission waits, add that as a separate case. Note which version should be sent and what happens to later changes. Do not let a recording of the first simple case imply support for this more complicated sequence.

Refresh only after you have captured the transition you want to review. Then check whether the confirmed result survives. If a refresh changes the apparent outcome, preserve that difference in the test record rather than choosing one view as the entire story.

Give founder peers a test record they can question

A useful build-in-public post can show the initial state, attempted action, interruption, recovery message and final shared record. Explain which parts are observations and which are your interpretation. The sequence gives another developer somewhere specific to challenge the reasoning.

Ask a focused UX question. For example, could a person tell whether this brief was still waiting on their device? Or did the retry choice explain what would happen to the original attempt? These questions invite feedback on the uncertainty a real user must navigate.

Buildside's founder community is a place to share visible product work and connect with peers. Present the rehearsal as one bounded test, with sample data and known limits. A peer's comment can improve your next test without proving reliability across the product.

Finish with the unresolved case you will inspect next. That could be a longer interruption, leaving the page, or a later edit that conflicts with queued work. Choose it because the current observation leaves a real question, and keep the next promised behavior separate from what you have already verified.

Hey I'm Uriel Bitton. I write about building in public strategies and growing startups.

Subscribe for more stories on growing your audience by building in public.

Join us on Buildside: the social network for founders building in public.

Sources

MDN: navigator.onLine and the limits of connectivity heuristics

Buildside: Share product work with founder peers

Content-Encoding and SEO: Can the Crawler Decode the Answer?

Uriel Bitton — Sun, 08 Nov 2026 15:29:40 +0000

When compressed HTML appears unreadable to a crawler, inspect the response's Content-Encoding and the bytes actually delivered before rewriting the page. A successful HTTP response and a correct HTML template do not, by themselves, demonstrate that the recipient can decode the answer.

This is a delivery investigation. First establish what was requested, what the server declared, and whether decoding produces the intended document. Then investigate indexing or AI visibility as separate outcomes. Changing compression is not a documented shortcut to citations or recommendations.

The workflow below follows a fictional documentation page through an origin server and an edge layer. It is a diagnostic example, not an incident report or a test of a real website.

Establish the encoding contract

Google's crawler overview lists gzip, deflate, and Brotli as supported content encodings. It says each Google user agent advertises supported encodings through its request's Accept-Encoding header. Inspect the actual request rather than assuming every crawler from every provider supports the same set.

MDN's Content-Encoding reference explains that this response header describes the encodings applied to a resource, including their order. The recipient uses that information to recover the underlying content format. Accept-Encoding expresses what the client can accept; Content-Encoding describes what the server sent.

For a page declared as gzip, the delivered representation needs to be consistent with that declaration. An HTML-looking URL does not settle the question. Neither does a dashboard that reports only an HTTP status. The evidence you need includes the headers and the delivered representation from the same request.

Freeze one failing example before changing settings

Choose a single public page where the problem has been observed. Record the exact URL, timestamp, response status, request encoding preferences, response Content-Encoding, and the location from which you tested. Keep any authentication or cookie conditions in the record without exposing private values.

Also preserve the specific failure. Did the client report a decoding error? Did it obtain readable HTML with the answer missing? Did only a cached browser view work? Those observations point toward different investigations. “The bot cannot read us” is too broad to guide an infrastructure change.

Use a non-sensitive documentation page for the comparison. Do not publish private response bodies or access tokens in an SEO issue. A small excerpt showing whether the expected heading and answer survived decoding is usually more useful than a complete dump of unrelated page data. Keep full diagnostic artifacts in the team's appropriate private location.

Follow a fictional mismatch through the edge

Imagine the origin produces a normal HTML guide about creating a project. In this invented configuration, the origin compresses the response with gzip. An edge transformation then decodes the body for inspection but forwards the old Content-Encoding header with the now-uncompressed HTML.

The declared representation and the actual body no longer agree. A recipient instructed to decode gzip has not received the representation that header describes. This example illustrates a configuration mismatch; it does not establish that your CDN behaves this way or that a particular search engine will handle every mismatch identically.

The useful comparison is between the origin response and the public response for equivalent requests. If origin decoding produces the guide and public decoding fails, focus on the transformation between them. If both decode correctly but the guide's main answer is absent, investigate content generation next. Keep the hypothesis attached to the observed difference rather than changing several unrelated settings at once.

Compare like requests and readable output

Make a small test matrix using your team's approved HTTP inspection tools. Include an ordinary supported compressed request and, where the server supports it, an uncompressed comparison. Record what each request actually receives. A server may choose a representation based on its configuration; the request header alone is not proof of the response format.

For each successful decode, inspect the resulting HTML for a stable marker: the page's main heading, the first answer paragraph, and a link near the end. This checks document meaning as well as the ability to inflate bytes. A decoded maintenance page is still the wrong document for a buyer's question.

Compare the important content across variants, allowing for harmless delivery differences such as request identifiers. Do not require every byte of a dynamic page to match. Do require the same substantive answer and the intended access conditions. Record cache state when your tools expose it, because comparing a fresh origin response with an old edge copy can confuse the diagnosis.

Assign ownership of each transformation

Draw the actual route in plain language: application, origin server, edge transformation, public response. Beside each step, state whether it can compress, decompress, or rewrite the body and whether it can change the relevant headers. Use configuration evidence rather than a vendor diagram that may not match your deployment.

Then ask who owns the complete representation at the final boundary. A fix should restore agreement between the outgoing bytes and their metadata. That may mean correcting a transformation, removing stale metadata through the established server configuration, or changing where compression occurs. The right choice depends on the demonstrated defect.

Avoid copying a universal “disable compression for bots” rule into production. Google's documentation already identifies supported compressed formats. Broadly removing a working delivery feature is unnecessary when the observed problem is a specific mismatch. Any change still needs normal engineering review and a check that ordinary readers receive the correct page.

Verify the repair at the same boundary

Repeat the original failing request after the change and record the new timestamp. Check the response declaration, successful decoding, and the expected answer markers together. Then repeat the comparison variants you used to isolate the defect. This makes the evidence about the repair comparable to the evidence about the failure.

Check another representative page that shares the delivery path. A homepage alone may use a different route from documentation. If the repair only covers one cache key or one template, say so. Do not close a site-wide issue based on a single URL when the suspected scope was broader.

Include the fallback path in the handover. If the tested representation fails again after a deployment, the next engineer should know which configuration changed and how to restore the previously verified delivery behavior. Keep that rollback guidance tied to the affected layer rather than suggesting an unrelated content rewrite.

For a real crawler observation, verify the crawler using the engine's documented method before attributing a request to it. A user-agent string you typed into a local test can help reproduce server routing, but it does not turn that test into evidence of an actual crawler visit. Keep synthetic checks and observed crawler traffic labeled separately.

Report delivery, discovery, and citation separately

Your delivery result might be: “The public guide now decodes correctly for the tested gzip request, and the main answer is present.” That is a meaningful technical outcome. It does not establish that the page has been indexed, selected as an AI source, or recommended to a buyer.

Continue those investigations with their own evidence. Record indexing observations through the relevant native tools. For AI-answer checks, retain the prompt, engine, mode, date, answer and linked sources. A brand mention without a page link is different from a citation to the repaired guide.

The practical priority is simple: recover a readable, accurate document before interpreting visibility results. When the representation is valid, the content team can assess the answer itself. When it is broken, repeating keywords or adding another heading does not repair the delivery contract.

Hey I'm Uriel Bitton. I write about SEO, AEO, GEO, and helping brands get found in AI answers.

Subscribe for practical ways to grow your brand's visibility in search and AI answers.

Explore HoneyWeRank for SEO and AI visibility.

Sources

Google: Crawlers and fetchers, including supported content encodings

MDN: Content-Encoding header

Optimistic UI Rollback: Let Public Demo Testers See a Change Fail

Uriel Bitton — Sat, 07 Nov 2026 20:58:25 +0000

To test optimistic UI rollback in a public SaaS demo, show an immediate interface change, deliberately reject the underlying operation, and check what the tester understands and what remains after a refresh. Ask them to distinguish a pending change from a confirmed one. A fast animation is useful feedback about responsiveness, but it is not evidence that the requested change was saved.

An optimistic interface displays the expected result before the operation finishes. That creates a useful testing question for a founder building in public: when the expectation is wrong, can another person recover without needing your explanation?

The task board below is fictional. It supplies a repeatable review exercise, not a report of testing Uriel's products or a claim about Buildside's implementation.

Start with one reversible change

Use a disposable task whose priority can change from Normal to High. Begin with an account that can normally perform the operation, a known saved Normal value, and a visible way to inspect that task again. A small reversible action makes the difference between the display and the stored result easier to follow.

Write the expected sequence before recording anything. The tester chooses High. The interface shows a pending High value. The service rejects the change. The interface explains the failure and returns to the confirmed value, or otherwise makes the unresolved state explicit. A later reload should agree with the product's stated result.

That sequence is a proposed behavior for this exercise. Your product may need a different recovery policy. For example, an unsent draft may deserve to remain available for retry. Decide the intended result for the actual task before asking a community to judge whether the implementation is correct.

Make the rejection part of the demonstration

Arrange a controlled failure in a safe test environment. Describe the condition you introduced, such as a simulated rejected response, rather than implying that a staged failure was an unexpected production incident. Keep real customer work outside the demonstration.

Show the successful path once so the viewer knows what confirmed High looks like. Then reset the fixture and run the rejection. Keep the starting task, account capability, and requested value comparable across the two runs. If you also change the task or permissions, say so because the comparison now answers a different question.

React's useOptimistic documentation explains that optimistic state is temporary while an Action is pending. It also describes returning to the current underlying value when the Action ends, including failure, and catching errors to show a message. That explains one mechanism. It does not establish that your whole application handles rejected operations correctly.

A public demo should therefore show the behavior, not just name the hook or library. A reader can inspect a rejected operation and its visible result even when their own stack differs from yours.

Ask the tester what state they believe

Give the tester the task and let them operate the interface. Before explaining the pending indicator, ask what they think has happened. Do they believe the priority is saved? Are they waiting for a response? Would they leave the page now?

After rejection, ask what they would do next and which value they expect to see tomorrow. These questions reveal whether the interface communicates the result. Telling someone that the label means pending and then asking whether the label is clear tests your explanation as much as the design.

Record the action, the visible state, the tester's interpretation, and the next action they choose. A short sequence of observations is more useful than a single verdict that the flow felt fine. Do not invent a usability score from one person's reaction.

If the tester understands the failure but cannot recover, you have a recovery problem. If they recover only after you explain the message, you also have a communication problem. Those observations can lead to different changes even though they arise in the same run.

Reload after the interface settles

The fictional board should be inspected again after the rejected request finishes. Reopen the task through the ordinary product route. Check whether its priority agrees with the result the interface communicated. Record the actual value you observe.

This step can reveal a mismatch between a restored local display and the next fetched value. It is still a bounded observation. A matching reload in one test does not prove that every device, cache, account, or failure condition behaves the same way.

Also check the successful path after a fresh reset. A failure demonstration that always returns to Normal could conceal a separate problem where successful changes never persist. The purpose is to compare expected outcomes, not to celebrate rollback as the only acceptable final state.

Describe the timing boundary in your public note. For example, say that you inspected the task after the rejected operation completed and then reopened it. Avoid compressing a pending screen and a later confirmed screen into a before-and-after image that hides the moment the user had to make a decision.

Check what happens when actions overlap

Once the single change is understandable, try a second action before the first one finishes. In the fictional board, the tester chooses High and then Normal while the earlier operation is still pending. Decide whether the product permits that sequence or temporarily prevents another change.

If it permits overlapping requests, inspect both the visible result and the final saved value after the responses settle. A late failure should not silently erase a newer confirmed choice. Record the order of the actions and the outcomes you introduced so another developer can understand what was actually tested.

Do not generalize from one response order. A successful run in which replies arrive in the same order as clicks leaves other orderings untested. You can publish that limitation and request a review of a specific remaining sequence.

If your product disables the control while pending, show that behavior too. Ask whether the tester understands why the control is unavailable and how long they expect to wait. Preventing a second click is a design choice whose consequences should be visible, not a reason to omit the waiting state from the demonstration.

Publish an observer script alongside the clip

A useful public-building update includes enough context for a peer to repeat the exercise. Name the disposable fixture, the initial saved value, the intended action, the failure condition, and what to inspect after it settles. State the environment and any access requirements that affect the result.

Keep the request small. Ask a reviewer to explain what the pending and rejected states mean before you ask for broader design suggestions. A specific question gives a developer or likely user a clear way to contribute without reverse-engineering your whole product.

Buildside provides the founder-community context for sharing visible product work and questions. The useful artifact here is the repeatable behavior review: a clip plus instructions and an open question. Its value comes from what another person can inspect, rather than from an unexplained claim that the interface is instant.

Review the recording for private information before posting it. Disposable task names help, but browser chrome, account details, and surrounding tabs can still disclose information. Use only what the review needs.

Turn the result into one next change

Suppose a hypothetical tester thinks High was saved, sees a brief error, and leaves without noticing the return to Normal. That observation supports reviewing the pending label, failure message, or placement of the restored value. It does not establish that optimistic UI should be removed from the entire product.

Choose one concrete change and repeat the same exercise under comparable conditions. Keep the original observation available in your notes so a more polished recording does not quietly replace the problem you were trying to solve.

When you share the follow-up, name what changed and what you observed. Be candid about the sequences and participants you have not checked. A founder can build trust by showing a failure clearly and making the recovery open to inspection, even while the broader product still needs work.

Hey I'm Uriel Bitton. I write about building in public strategies and growing startups.

Subscribe for more stories on growing your audience by building in public.

Join us on Buildside: the social network for founders building in public.

Sources

React: useOptimistic, pending state and error recovery

Buildside: Building in public and founder community

Breadcrumb Markup: Test the Trail, Not Just the Validator

Uriel Bitton — Sat, 07 Nov 2026 18:14:56 +0000

Test breadcrumb markup against a real route through your site before treating a successful validator result as completion. Check each label, destination and position, then compare that ordered trail with the navigation a reader can use. Valid structured data can still describe an unhelpful or misleading path.

For a documentation site, the useful outcome is a visitor who can move from a specific answer to the right parent guide. Search appearance is a separate observation. Google's current breadcrumb documentation lists desktop availability; a missing breadcrumb on a mobile result is not, by itself, evidence that your implementation failed.

Start with the parent the reader needs

Choose a specific page and ask what a reader would reasonably open next to understand its context. A configuration guide might belong under a task collection, a product guide or an API family. Use the site's actual information architecture, with names that mean something to the audience.

Google's breadcrumb guide recommends representing a typical user path rather than simply copying the URL structure. That matters when an address contains a version segment, an internal identifier or a folder name inherited from an old publishing system.

Treat the path as an editorial decision that engineering must implement accurately. A folder called guides does not settle which guide collection should be the parent. Ask the documentation owner to identify the intended route before a template automatically turns every slash into a crumb. This avoids shipping a polished representation of an accidental storage layout.

Write a small trail specification

For each item, record the visible label, intended destination and order. Keep the page being audited beside that list. A reviewer should be able to follow the path without guessing whether two similar labels refer to the same collection.

Distinguish the title of a linked parent from an instruction to the reader. Set up notifications is an action; Notification guides may be a collection containing several actions. Either can be useful in the right place, but they are not interchangeable destinations.

Give the specification an owner and include a representative page from each affected template. If several products share the component, choose a case with a different product family as well. A single successful page does not establish that the template resolves every parent correctly. The purpose is a compact acceptance record, not a new sitemap of every possible route.

Check the actual links before the metadata

Open each parent destination in the rendered navigation and inspect where it leads. Confirm that the landing page matches its label and offers the relevant onward path. If the link redirects, inspect the destination you actually reach rather than approving the initial address from the template alone.

Try the route as a reader arriving directly at the specific guide. Can you move upward and recognize where you are? If a parent requires a different account or opens an unrelated product catalog, record that behavior explicitly. A technically clickable label can still send someone out of the documentation context they need.

Keep this review limited to the intended public material. Private workspace navigation should not be exposed merely to make a public breadcrumb look complete. The trail should describe a legitimate route for the page's audience, with its destinations available under the access conditions the documentation is supposed to have.

Match the ordered markup to the approved trail

Inspect the rendered page's breadcrumb representation using the site's supported development tools. Compare the labels, item URLs and ordering with the approved specification. Do not assume the visible component and the structured data use the same source of truth simply because they were deployed together.

Google documents an ordered BreadcrumbList containing at least two ListItems, with supported details for names, positions and item destinations. Its final-item rules allow the containing page's URL to be used when that last item's destination is omitted. Follow the current documentation for the format your implementation uses.

This article does not supply a block of production markup to paste blindly. The useful check is whether your actual output represents your actual page. Keep one clear ownership path for those values. If separate plugins or templates each emit a trail, inspect their combined output and resolve contradictions deliberately rather than assuming a validator will choose the intended version.

Work through a fictional two-path guide

Imagine a fictional developer portal containing a guide called Rotate a service key. Readers can reach it through Security tasks or through API access. Both collections explain a legitimate route to that same guide. These are invented site details for a worked example, not findings from an audited production system.

Suppose the visible trail uses Security tasks, but an inherited template emits an old Integration setup parent. Under those assumptions, the values may be syntactically acceptable while the relationship is stale. The repair is to update the intended trail mapping and verify its destinations, not to rename the final guide just to match the old folder.

Google's documentation also illustrates multiple breadcrumb trails. If the fictional portal chooses to represent both legitimate paths, each needs its own coherent order. Combining the two parent collections into a single invented chain would describe a route the reader cannot follow. Multiple valid paths do not justify an arbitrary list of keywords.

Use validation to answer a defined question

Run the appropriate structured-data validation after checking the actual trail. Record whether the expected items were detected and whether errors remain. Save the tested URL, time and relevant output so a later reviewer can distinguish a successful test of a current page from an old screenshot.

Google recommends its Rich Results Test and URL Inspection as part of the implementation workflow. Those checks help investigate supported markup and Google's access to a page. They do not replace the human decision about whether a parent label is useful or whether the represented route makes sense.

Avoid mixing local and published evidence. A component preview may use a corrected mapping while the deployed page still serves an earlier configuration. Test the public output after release and compare it with the approved specification. If the two disagree, close the deployment gap before interpreting a search result as a verdict on the new implementation.

Observe the supported search surface separately

Record a desktop search observation with the query, result URL and date when checking Google's breadcrumb presentation. Keep the result's displayed path apart from the site's visible navigation. They concern the same page but are different pieces of evidence.

Google does not guarantee that structured-data features will appear. A passing test therefore supports a narrower statement than the search result now has the desired trail. Likewise, a mobile screenshot should not be used to judge a feature currently documented for desktop.

If the result differs from the intended trail, revisit the rendered output and the exact page being observed. Avoid repeatedly editing labels without establishing what changed between observations. A speculative label churn can make the implementation less consistent while leaving the original question unresolved. Keep a deployment record and a search-observation record, with each conclusion attached to the evidence that actually supports it.

Leave a maintainable acceptance record

Finish the task with the representative URLs, approved parent mappings, live link checks, validation results and any unresolved search observation. Include the shared component or content owner responsible for future category moves. The next edit should have an obvious place to update the relationship.

When a guide changes collections, review its trail alongside the navigation that leads into it. When a collection is retired, inspect affected children before leaving them linked to a destination that no longer explains their context. These are practical maintenance recommendations, not promises of better rankings or AI citations.

The completion standard is concrete: the page presents a useful navigable route, its structured representation agrees, and the public output has been checked. Search appearance can then be monitored honestly. A validator pass is valuable evidence within that process, with a clear boundary around what it proves.

Hey I'm Uriel Bitton. I write about SEO, AEO, GEO, and helping brands get found in AI answers.

Subscribe for practical ways to grow your brand's visibility in search and AI answers.

Explore HoneyWeRank for SEO and AI visibility.

Sources

Google Search Central: Breadcrumb structured data, properties, testing and feature availability

CSV Import Preview: Show Which Rows Will Change in Your Public SaaS Demo

Uriel Bitton — Fri, 06 Nov 2026 17:17:01 +0000

A useful CSV import preview shows which source columns map to which fields, which rows need attention, and what will change after confirmation. When you share the feature while building in public, demonstrate those boundaries with a fictional file. A successful upload alone does not tell a reader whether records have been created, updated, skipped, or left untouched.

For a small SaaS team, the public demonstration can serve two purposes. It explains the feature to prospective users, and it gives developers and founder peers a concrete workflow to question. The most useful feedback concerns the decisions a user must make before committing data.

You do not need a large demo database to expose those decisions. A small disposable example with a few carefully chosen rows is easier to inspect. The aim is to make the importer understandable, including what it does when the file is imperfect.

Define the import task before the preview screen

Start with a narrow task. In the fictional example used throughout this article, a founder is building a workshop-planning tool. The user wants to import a participant list into one draft workshop. The import must not send invitations, charge anyone, or change another workshop.

That task description gives the preview a boundary. “Import contacts” could imply a global address book. “Add participants to this draft workshop” tells a reviewer what to inspect. State the destination in the demo before selecting the file so the audience can judge later screens against it.

Use invented names and safe example values. Include an ordinary new row, a row matching a participant already in the demo, and a row missing a required value. Label the dataset fictional in the public post. None of these records should resemble a real customer's exported list.

Write down the question you want the demo to answer. For example: can a first-time reviewer predict which participants will appear in the draft workshop? That is more specific than asking whether the importer looks clean, and it produces feedback you can act on.

Separate parsing from business validation

The file has to be read before its contents can be judged. RFC 4180 documents a common CSV format, including optional headers and quoting rules for fields containing commas, line breaks, or quotes. It is an informational memo, not a complete specification for your application's import behavior.

A parser understanding a row does not make the row suitable for the workshop. The application still needs to decide whether a required email is present, how a date is interpreted, and what counts as the same participant. Those are separate product rules that the preview should make visible.

In the fictional file, an organization name might contain a comma inside quotes. That belongs in a parsing example. A participant without the required contact value belongs in a validation example. Showing both makes it harder to confuse a file-format problem with an application rule.

Avoid presenting a list of supported edge cases that the current importer has not passed. If the demonstration is a prototype, say so. A public explanation of intended behavior is useful, but it should not become a claim that every implementation detail is already reliable.

Show the mapping as a decision

Use source headings a reader might actually encounter. The fictional file might call a column “Attendee” while the product field is “Participant name.” The preview should show the relationship clearly enough that a person can correct it before continuing.

If the application guesses a mapping, distinguish the guess from a confirmed choice. A confident-looking arrow can conceal a bad assumption. In the public walkthrough, deliberately inspect one suggested mapping and explain why it is appropriate for this dataset.

Also show what happens to an unused column. A reviewer should not have to infer whether it is ignored, stored somewhere else, or blocking the import. The right choice depends on your product, but an unexplained column creates an avoidable gap in the demo.

Ask a peer to explain the mapping back without your narration. If they cannot tell which value becomes the participant name, polishing the success animation will not resolve the issue. Improve the field labels or sample values first, then run the same task again.

Explain each row's proposed effect

The preview needs more than a green success state. For this fictional workflow, give every row a proposed effect: add a participant, update an existing draft participant, skip an unchanged match, or block the row until the required value is supplied. These labels are design suggestions, not universal import rules.

Define the matching rule alongside the preview. If this example matches participants by email within the selected workshop, show that scope. Two rows with the same name should not silently demonstrate the same rule as two rows with the same email.

Include one visible before-and-after comparison for the matching row. Suppose the demo already contains a participant with a blank organization field. The file supplies an organization. A reviewer should be able to see whether that value will be added and whether other fields remain as they were.

For the blocked row, explain what the person can do next. They might fix the file and upload it again, edit a supported value in the preview, or exclude that row. Only show options the current product actually supports. An unavailable recovery path does not become real because the mockup looks plausible.

Make the final commit boundary unmistakable

Before confirmation, say whether the preview has changed the destination. In this example, previewing creates no participants. The final action commits the approved rows to the draft workshop. That separation should be visible in the interface as well as in the public explanation.

Choose an explicit policy for mixed valid and invalid rows. The example could block the whole batch, or permit only the valid rows after clear confirmation. Either way, explain what the user is authorizing. Do not let a generic “Continue” carry an undisclosed decision about partial imports.

After committing, show the resulting workshop list and compare it with the preview. If the demo says a row will be skipped, verify it was skipped. A completion banner confirms that an action finished; the destination is where the reader can check what actually changed.

Then demonstrate a second attempt using the same fictional file. This is a useful review question even before you have a sophisticated retry system: would the same action create duplicates, update matches, or refuse the request? Document the observed behavior rather than assuming repetition is harmless.

Turn the public demo into a focused review

Share a short sequence containing the destination, the file headings, the mapping, the row effects, and the final result. A founder community can examine that sequence without needing access to your private repository or production data. Keep the review surface small enough to finish in one sitting.

Buildside is a relevant place to share the progress and the question behind this work. Ask founder peers whether the preview gives them enough information to approve the import. If you want feedback from people who routinely move workshop lists, say that rather than treating every reaction as equivalent.

Separate three kinds of response in your notes. A developer may spot an untested parsing case. A relevant user may misunderstand the destination. A founder may suggest a different launch story. All can be useful, but they answer different questions about the feature.

Record what changed after the review and what remains untested. If a clearer label helped one reviewer predict the row effects, describe that observation at its actual scope. It is evidence from that review, not proof that the importer is ready for every dataset.

Publish the next check with the improvement

A useful build-in-public update can end with one unresolved task. Perhaps the matching rule is clear, but the recovery message after a failed commit needs work. Name that gap and show the state a reviewer would see. This gives the next conversation a concrete starting point.

Keep the fictional file with the demo notes so you can compare later versions using the same task. Change it deliberately when a new question requires a new case. If every video uses a different dataset, it becomes harder to tell whether the explanation improved.

An import preview earns confidence by making its consequences inspectable. Show what the file says, what the application proposes, and what confirmation actually changes. That gives early users a clearer decision and gives your founder peers a better way to help you build.

Hey I'm Uriel Bitton. I write about building in public strategies and growing startups.

Subscribe for more stories on growing your audience by building in public.

Join us on Buildside: the social network for founders building in public.

Sources

RFC 4180: Common format and MIME type for CSV files

Buildside: Building in public and founder community

robots.txt Redirects: Keep the Rules Attached to the Original Host

Uriel Bitton — Fri, 06 Nov 2026 17:07:57 +0000

When a robots.txt request redirects to another host, trace the complete HTTP route and evaluate the returned rules in the context of the original request. The location holding the policy file and the site governed by that request are different facts. Keep both in your evidence before deciding whether a public documentation page is allowed to be crawled.

A redirect can be intentional, such as a shared policy service. It can also be an accidental consequence of a hostname or application routing change. The useful engineering task is to identify which file the crawler can reach and what that file means for the initial site. A successful browser visit to some policy text is only the beginning of that check.

Start at the site's actual robots endpoint

Choose the exact public site involved in the discovery problem. Record its scheme, host and relevant port, then begin at its top-level robots.txt endpoint. Do not start from a bookmarked destination in a shared file store and assume you have reproduced the site's route.

Google's robots.txt specification guide describes where the file belongs and the scope of its rules. It also documents Google's handling of redirects. Keep that engine-specific implementation beside the broader protocol instead of treating every automated client as identical.

For an investigation, save the initial request, observation time, returned status and Location header when present. Continue from the actual response. A manually assembled destination that looks plausible is not evidence of where the deployed endpoint sends a client.

Capture the route before reading the policy

Inspect each HTTP response in order, including the final response and body. Identify a loop, an unexpected login destination, a missing file, or a shared endpoint that returns the wrong site's policy. Preserve the response details needed to distinguish those possibilities.

Google says it follows at least five redirect hops for robots.txt and then treats the unresolved file as a 404. It does not follow logical redirects implemented through frames, JavaScript or meta refresh. A page that sends a human elsewhere after rendering therefore does not establish the documented robots retrieval behavior.

This is a reason to make a deliberate route short and inspectable, not an invitation to consume every available hop. If a policy can be served directly at the original endpoint, consider whether that simpler arrangement fits the system. If a redirect is necessary, document its owner and destination so later routing work does not quietly change the policy path.

Keep the original authority attached to the rules

RFC 9309, section 2.3.1.2 says crawlers should follow at least five consecutive redirects, including across authorities. When the file is reached within that sequence, its rules are fetched, parsed and followed in the context of the initial authority. The RFC uses specific requirement language; it does not say every client implements every detail identically.

Suppose a documentation host redirects its robots request to a file on an asset host. A path restriction in that returned file must be assessed against the documentation site's path under this protocol rule. Finding the same path on the asset host would answer a different question.

Keep an explicit pair in the investigation note: the initial site and the final policy URL. That small piece of bookkeeping prevents a shared-host deployment from turning into an ambiguous instruction to inspect whichever host appears last in the trace.

Walk through a fictional shared-policy mistake

Imagine a fictional SaaS company with a marketing host and a documentation host. Each robots endpoint redirects to a central policy service. The team intends the documentation host to expose public guides while keeping a particular preview path outside ordinary crawling.

During a routing change, the documentation endpoint begins redirecting to the marketing policy file. The file is readable and the request completes successfully, so a basic uptime check remains green. However, the returned path rules were written for a different public site.

These are illustrative assumptions, not captured requests or measurements from a real deployment. They show why a valid route can deliver the wrong policy. The investigation must compare the returned content with the intended policy for the initial documentation host.

The repair under these assumptions is to restore the correct destination or serve the intended file directly. Rewriting every public guide would not address the routing defect. After the change, capture a new route and compare the returned rules with the intended documentation paths.

A useful incident note would also explain how the wrong destination was selected. Was it a copied redirect rule, a changed deployment variable, or an unresolved routing decision? Those are questions to investigate, not causes to invent. Keep the confirmed mechanism beside the actual corrective change. If the cause remains unknown but the intended route has been restored, say so and assign the remaining investigation separately. That gives a future maintainer a reproducible symptom without turning a plausible explanation into a false incident history.

Test allowed and restricted paths deliberately

Choose a small representative set of URLs before evaluating the policy. Include a public guide that should be crawlable, a preview path covered by the intended restriction, and a nearby path that should remain unaffected. Write the expected decision beside each case.

Then evaluate the actual returned rules for the relevant crawler. Keep retrieval and matching as separate checks: first establish which file arrived, then determine how its rules apply. A correct matching test against an old local copy cannot verify a broken production retrieval path.

If the company uses several hosts, repeat the initial-request trace for each host in scope. A shared destination can be intentional, but the evidence must still show which original request produced it. Do not infer all hosts are repaired from one successful trace.

Use clearly fictional fixtures for an explanatory test, or retain the real request details when documenting an authorized production incident. Do not label a manual request as a Googlebot observation merely because the investigation concerns Google Search.

Watch what deployment and caching can change

A routing rule can change independently of the policy file. So can the service that chooses which file to return. Identify both owners in the handoff. The person updating documentation should not need to guess whether an infrastructure release changed the robots response.

Compare the public endpoint after deployment with the route you intended to ship. Check that no application fallback, authentication redirect or hostname normalization has inserted an unexpected step. These are proposed inspection points, not claims about the architecture of a particular hosting service.

Keep the capture time with the returned content. If a later check differs, preserve both observations before assigning a cause. An old report and a fresh request may concern different deployed states. That distinction helps the team explain a change without claiming a universal crawler refresh deadline.

Close delivery and discovery as separate questions

Close the delivery defect when the original endpoint reliably reaches the intended policy and the representative paths produce the expected rule decisions. Include the initial site, each redirect, final file, relevant crawler and before-and-after evidence. Name any remaining uncertainty rather than hiding it behind a success code.

The Robots Exclusion Protocol is not access authorization, as the RFC also makes clear. Protect private material with the appropriate application controls. A public robots file should not be treated as a mechanism that makes a preview secret.

Finally, keep later search observations separate. A repaired policy route establishes what was delivered and how the checked rules apply. It does not guarantee indexing, rankings, or citations from an AI answer engine. Those outcomes need their own evidence after the technical work has a defensible finish.

Hey I'm Uriel Bitton. I write about SEO, AEO, GEO, and helping brands get found in AI answers.

Subscribe for practical ways to grow your brand's visibility in search and AI answers.

Explore HoneyWeRank for SEO and AI visibility.

Sources

Google Crawling Infrastructure: How Google interprets robots.txt

RFC 9309: Robots Exclusion Protocol

Autosave UX: Show What Saved Means in Your Public SaaS Demo

Uriel Bitton — Thu, 05 Nov 2026 15:21:33 +0000

To get useful feedback on autosave UX, show one edit moving from local text to a confirmed save, then show a failed save and its recovery. Reopen the same item at the end. A public demo should make clear which version is on screen, which version was accepted, and what the user can safely do next.

A smooth typing clip leaves the difficult part out. The text looks present because it is still in the editor. That alone does not demonstrate that it will survive reopening, reach another device, or remain after a failed request.

Building this sequence into a small public demo gives founder peers a concrete behavior to inspect. The question becomes whether the product tells the truth about the latest edit, rather than whether the animation looks polished.

Define what Saved promises in this product

Write a plain sentence before choosing the status label. Does saved mean the server accepted this revision? Does it mean a draft exists only on this device? Is there a separate publication step? Different products can make different promises, but the interface should not blur them.

For example, a draft editor might confirm that a revision has been accepted by the service while still requiring a separate action to publish it. The demo should show that boundary. A person should not infer that their writing is public just because it is saved, or safely stored remotely just because it remains visible.

Use wording that matches the actual implementation. If you only have a prototype with simulated responses, label it as a prototype. If the recording uses a controlled failure, say so. An honest demonstration of an unfinished state is more useful than a finished-looking badge with an undefined meaning.

Track revisions rather than the last response alone

Consider a fictional editor for a client brief. The sample text begins with Meeting on Tuesday. The user changes it to Meeting on Wednesday. Call that revision A. While its request is pending, they change it again to Meeting on Thursday, revision B.

A response confirming A does not confirm B. If the interface displays Saved while B is still pending, it gives the user an inaccurate account of their current text. The visible status needs to describe the revision they are looking at, not merely the most recent successful response.

This is a behavior to verify whatever tools or architecture you use. You can serialize updates, track revisions, or adopt another suitable approach. The public demonstration need not reveal private infrastructure or pretend that one design solves every concurrency case.

Write the expected outcome in your notes: when the confirmation for A arrives, the editor still shows that B needs saving. When B is accepted, the saved indication refers to B. That expectation is specific enough for someone else to challenge.

Show a pending save without stealing the typing task

The user should be able to understand that work is pending without being repeatedly pulled away from writing. Put the status near a stable part of the editor and keep the meaning consistent as the state changes.

The W3C explanation of status messages describes making relevant updates available to assistive technology without moving focus. Its examples cover waiting, results, and errors. It does not prescribe your autosave timing or prove that a particular component is accessible.

In your review, check the visible message and its announcement separately. A status that only changes color may be unclear to readers who cannot perceive that change. A screen reader user should not have to leave the editor and search for an update that matters to their next action.

Avoid announcing every keystroke. Review the actual announcement behavior with the tools and browsers you support. A screenshot of a label cannot establish how that experience works.

Use a controlled failed-save example

Use disposable sample content in a test environment. Make the failure observable and repeatable through your normal development tools or test controls. Explain what you are simulating and what you are not checking.

Return to the fictional client brief. Revision A has been saved. The user types revision B, and that save fails. The editor keeps B visible and identifies that the latest changes have not been saved. A retry action is available if the product supports one.

The status should not quietly return to a reassuring success state just because an older version exists. Tell the user about the unsaved changes. If the product can preserve only part of the work or has a recovery limit, make that limit visible rather than promising that nothing can be lost.

Record the sequence from before the edit through the failure. An isolated error screenshot cannot show whether the application discarded text, changed focus, or mislabeled the previous revision.

Retry the current edit and reopen the item

After a failure, the user may continue typing. Decide what your retry action sends. Does it retry the failed revision, or save the latest visible content? Either way, the behavior should be explicit and the resulting status should match the text it covers.

For the worked example, choose a simple expectation: Retry saves the current visible revision. The user adds a location to the brief, retries, and waits for confirmation. The reopened item should contain both the changed day and the added location.

Reopening is a useful check because it removes the comforting presence of the old editor session. Compare the actual content, not just a toast or a checkmark. Keep the test item identifiable so you do not accidentally inspect a different draft with similar text.

This is still a narrow test. A successful reopen in one environment does not establish behavior across devices, account permissions, offline sessions, or concurrent editors. Name those gaps if they matter to the product's promise.

Share a small trace alongside the public demo

A short written trace makes the clip easier to review. Include the starting text, the exact change, the controlled delay or failure, the status shown, the action taken, and the text found after reopening.

For a community discussion on Buildside, ask one focused question: after the failed save, would you know which changes were still at risk? A second useful question is whether the retry label accurately describes the action. Do not ask peers to certify the whole storage system from a short video.

Keep customer information out of the example. Sample text should be visibly ordinary and disposable. If the clip includes browser tools, crop unrelated tabs and private values while retaining the parts needed to understand the sequence.

Include text that explains the important states for readers who cannot watch the recording. The post should remain useful even when the media does not play.

Turn feedback into a behavior decision

Separate a reader's expectation from the application's observed behavior. Someone might expect a save confirmation to remain visible longer. That is a design question. A newer revision being marked saved before acceptance is a correctness problem. Treating both as vague feedback makes the next step harder to choose.

Keep a compact review note: what the person saw, what they expected, what the application actually did, and the change you will make or investigate. If the evidence is incomplete, record the missing step rather than guessing.

For a small release, verify a few meaningful paths: normal save, delayed save while typing continues, failure, retry after another edit, and reopening. Add concurrent editing or offline recovery checks when those are part of the product you offer. Match the scope to the actual promise.

Then publish the result with its limits. Say which paths you checked and which remain open. A clear autosave demo gives readers a way to inspect a real product decision, and gives you a more useful next task than another round of comments about how clean the editor looks.

Hey I'm Uriel Bitton. I write about building in public strategies and growing startups.

Subscribe for more stories on growing your audience by building in public.

Join us on Buildside: the social network for founders building in public.

Sources

W3C: Understanding status messages

Buildside: A community for founders building in public

HTTP 206 and SEO: Inspect the Range Before Calling the HTML Complete

Uriel Bitton — Thu, 05 Nov 2026 15:05:51 +0000

When an HTML request returns HTTP 206, inspect the requested range and the bytes actually delivered before calling the page complete. Compare it with a request for the full document. A successful response can represent only part of a resource, so a green status alone does not tell you whether the buyer's answer arrived.

Treat this as a response-delivery investigation. The first goal is to explain what the public request received and why. A corrected response is useful technical evidence; it is not, by itself, proof of indexing or an AI citation.

Start with the request that produced 206

RFC 9110 defines 206 Partial Content as a successful response fulfilling a range request by transferring one or more parts of the selected representation. It says clients need to inspect Content-Type and Content-Range to understand which parts are enclosed.

Save the method, URL, request headers, status, response headers, and response body from the observation. Include the time and environment. Do not reduce the record to a screenshot of the status code, because the request may explain why the response contains a partial document.

Identify whether the request asked for a byte range. If a colleague used a diagnostic tool, ask for its request configuration too. A deliberately narrow request and an ordinary full-document request are different tests, even when they target the same URL.

Keep authorization material out of any broadly shared issue. The technical handoff should preserve the relevant range information without spreading session cookies or credentials. Use your team's normal controlled records for sensitive captures.

Compare the full request with the range request

Use an authorized inspection method to request the same public document without the range restriction. Preserve this response separately. Compare its status, content type, and body with the original observation rather than assuming that both tests retrieved the same representation.

For a single-part 206 response, the standard specifies a Content-Range header describing the enclosed range. Its total resource length and the response's Content-Length describe different things. Avoid treating the number of delivered bytes as the size of the complete page.

If the response contains multiple parts, read the relevant multipart structure instead of looking for one continuous HTML document. The standard covers that arrangement too. This distinction concerns HTTP semantics; it does not establish how a particular search product will use the response.

A useful comparison record has one row per request, with the request's range setting, resulting status, content type, and the location of the answer passage in the returned body. The rows should remain separate even if their URLs match exactly.

Work through a fictional missing-answer incident

Imagine a public export guide whose opening explains the feature, while a later section identifies which role can run the export. An engineer's diagnostic capture contains the opening but ends before the role restriction. The response status is 206.

In this fictional example, the diagnostic request explicitly asked for the first segment of the document. A second request without that range returns the complete guide, including the role restriction. These are invented conditions for a debugging exercise, not measured results from a real website.

The evidence supports a narrow conclusion: the first capture cannot establish that the public document omits the restriction. It intentionally retrieved an incomplete segment. The content editor should not rewrite the guide merely to satisfy a diagnostic record that never requested the full body.

Now change one assumption. Suppose an ordinary full-document request also receives that same short segment. The investigation changes. The team must trace why the public delivery path returns partial material for that request. That is a delivery question before it becomes a content-quality question.

This two-case exercise helps distinguish an incomplete observation from an incomplete delivery. Both can produce a record with missing text, but they require different next actions.

Trace the layer that changed the response

If the ordinary request receives an unexpected partial response, compare outputs through the delivery path your team controls. The application, proxy, content-delivery service, and cache configuration are possible places to investigate. The presence of a header alone does not identify which layer generated it.

Ask the responsible owner to explain any range handling, transformation, or caching rule that applies to the route. Compare the configuration with the captured request and response. Do not remove a broad shared policy simply because it contains a familiar header name.

For the fictional guide, the next useful finding might be a route-specific rule that incorrectly reuses a partial representation. That remains a hypothesis until the team traces the output. Document the uncertainty rather than presenting the most plausible explanation as a proven cause.

If other document types use intentional range requests, preserve their supported behavior. A repair for an HTML guide should not silently disable legitimate partial delivery for unrelated resources. Define the affected route family and the intended behavior before changing anything.

Verify the content that matters to the reader

After the relevant repair, repeat the original request and the full-document comparison. Confirm that each receives the intended representation. Check the opening, the disputed answer passage, and the end of the body, rather than stopping after the first screen looks reasonable.

In the fictional guide, the important check is whether the public full request includes the role restriction with the export instructions. The presence of a title and navigation is insufficient. A page can appear familiar while the sentence that determines eligibility is missing.

Keep the actual response captures with the issue. Record which request each capture belongs to. If someone later sees another 206 response, they can compare the circumstances without reopening the entire diagnosis from memory.

Also verify the normal browser experience after the repair. That complements the response check; it does not replace it. A browser's current state and a captured public request can expose different parts of a delivery problem.

Keep Google's documented scope clear

Google's HTTP status guidance says a 2xx response may be considered for processing and that a success code does not guarantee indexing. Its current table does not provide a separate 206-specific indexing promise.

Do not turn the general success category into a claim that Google will reconstruct or index every partial HTML response. Likewise, this guide makes no claim that ChatGPT, Claude, or Gemini handles partial responses in the same way.

If you inspect a search-related observation, keep its evidence separate: the requested URL, tool or crawler identity, time, returned representation, and any reported indexing state. A manually constructed range request is not a captured Googlebot request merely because the guide concerns SEO.

This separation lets engineering close a verified delivery defect without promising a search outcome. Search follow-up can then use its own evidence and relevant product documentation.

Close the issue with a reproducible distinction

Write down whether the original problem came from the diagnostic request, the public delivery path, or an unresolved difference between the two. Include the before-and-after requests, relevant headers, complete-body checks, and responsible configuration owner.

State what was repaired and what remains unknown. If the first observation was simply partial by design, close that misunderstanding and keep the useful full-document capture. If delivery was wrong, document the specific corrected behavior and the route sample used to verify it.

The durable lesson is to make completeness an observable property of the returned document. A status code helps explain the response, but the actual request and body determine whether your inspection reached the answer you were trying to assess.

Hey I'm Uriel Bitton. I write about SEO, AEO, GEO, and helping brands get found in AI answers.

Subscribe for practical ways to grow your brand's visibility in search and AI answers.

Explore HoneyWeRank for SEO and AI visibility.

Sources

RFC 9110: Section 15.3.7, 206 Partial Content

Google Crawling Infrastructure: How HTTP status codes affect Google's crawlers

Conflicting Canonicals in HTTP Headers and HTML: Trace Both Outputs

Uriel Bitton — Wed, 04 Nov 2026 15:58:25 +0000

When an HTTP canonical header and an HTML canonical element point to different URLs, inspect both outputs from the same page request before editing either one. Then trace each declaration to the layer that produces it. A correct template can still leave a conflicting header on the public response.

The immediate engineering goal is a consistent, intentional declaration. It is not proof that a search engine will select your preferred URL, and it is not evidence that an AI system will cite that URL. Keep those outcomes separate from the configuration you can verify.

Confirm that there are two declarations

Google's canonical guidance supports an HTML link element and an HTTP Link header. It recommends choosing one method because maintaining both can introduce errors, including different destination URLs. That documented risk is the starting point for this diagnostic.

Open the public page with the browser's network panel active and inspect the document response. Record its status, final request URL, and response headers. Separately inspect the canonical link in the HTML head. A search through rendered page text will not show either declaration reliably.

Save the exact values rather than writing that canonicalization looks wrong. Include the request time and environment. If the page redirects, distinguish the response before the redirect from the final document response. Otherwise, two developers can discuss different responses while believing they reproduced the same problem.

Build a two-URL response matrix

Here is a fictional incident. A product guide is available at a short guide URL and at an older documentation URL. The team has chosen the guide URL as the preferred location because it is the maintained version of the same content.

On the guide URL, the HTML canonical points to the guide, while the HTTP header points to the older documentation URL. On the older URL, both declarations point to the guide. This is an invented debugging exercise, not a report of a real site or a measured search outcome.

Create one row for each requested URL. Give each row columns for final URL, status, header destination, HTML destination, and observation time. Copy the exact destinations, including scheme, hostname, path, and any query string. Do not normalize away the difference you are investigating.

The matrix shows something a broad warning would miss: the disagreement is isolated to one output of one route. It does not establish which URL Google selected. It gives the engineer a narrower question about why that response still carries the old destination.

Trace each output to its owner

Start with the component that controls each observed value. The HTML may come from a page template or a server-rendered component. A response header may come from application middleware, an edge rule, a reverse proxy, or a hosting configuration. These are possible places to inspect, not claims about your particular stack.

For the fictional incident, suppose the page template correctly reads the new guide URL from content metadata. An older middleware mapping still assigns the documentation URL to the guide route. Changing the template again would not remove the stale mapping.

Give the investigation two explicit owners if the layers belong to different teams. Ask the application owner to identify the HTML declaration's source. Ask the delivery owner to identify the header rule. Share the same captured response so that each person can compare their configuration with the public output.

When the source remains uncertain, label it uncertain. A header's presence does not prove which component added it. Trace configuration and compare outputs through the access your team already has, rather than removing unrelated delivery rules to see what happens.

Select a coherent repair

Decide which method your site will maintain for this document type. Google recommends choosing one of the two canonical annotation methods. Its documentation also covers header declarations for supported non-HTML documents, such as PDFs, where an HTML head is unavailable.

In the fictional HTML guide, the team chooses to retain the intentional HTML declaration and remove the stale canonical header from the affected route. That is one example decision. Another site's document types, publishing system, and ownership model could justify a different consistent approach.

Write the intended output before changing configuration. Specify the route, preferred absolute URL, declaration method, and treatment of the older duplicate. Keep unrelated links and response headers outside the repair. Removing an entire shared header policy would be a much broader change than this incident requires.

Also examine whether a shared rule affects additional routes. Fix the source of the mismatch, then sample the affected route family. A repair that hardcodes one exception can leave the same outdated mapping on other pages and make the next migration harder to understand.

Verify the response after deployment

Repeat the same public requests after the repair. Capture the final response headers and HTML again, with a new time. Check both matrix rows and any additional routes affected by the shared rule. The acceptance condition concerns what those responses now declare.

For the fictional example, the guide response should contain the intended HTML canonical without the stale conflicting header. The older duplicate should follow the team's documented canonical policy. Verify the destination itself remains the intended public document rather than a missing page or an unexpected redirect.

If your application modifies head elements with JavaScript, compare the delivered HTML and the rendered head as an additional check. Record the difference instead of assuming the first source view describes the final output. Consult the relevant implementation guidance before introducing a new client-side canonical mechanism.

Keep the actual response captures with the change record. A configuration diff describes intent, while the captured output shows what the visitor-facing request received. Both are useful when caching, route conditions, or a later deployment complicate the investigation.

Separate repair evidence from search evidence

A consistent declaration closes the configuration defect. Search-engine selection is a different observation. If you inspect indexing information, record the URL and the reported state with the time of inspection. Do not relabel a changed source declaration as a confirmed change in Google's selected canonical.

Likewise, a linked AI citation has its own URL and context. If an answer cites the older address, preserve that observation separately. The existence of the citation alone does not identify the reason that address was used or demonstrate that the header repair failed.

This separation helps a team explain progress without overstating it. Engineering can report that the conflicting public outputs have been corrected. Search analysis can continue with its own evidence. Neither team needs to manufacture a quick visibility result to show that a real defect was repaired.

Leave a useful handoff

The final issue should contain the affected request URLs, the conflicting values, the producing components, the chosen policy, and the verified outputs after deployment. Include a small route sample if the change touched a shared layer. State any remaining uncertainty explicitly.

Add a maintenance note where future editors will find it: which layer owns canonical declarations for this document family, and where the destination mapping lives. That note is more useful than an unexplained exception whose purpose will be forgotten at the next migration.

Finally, tell the content owner which public URL remains the maintained guide. Internal documentation, navigation, and future publishing work can then use the same intended destination. This is a coordination step, not a promise about ranking or citations.

The strongest outcome of this diagnostic is a traceable relationship between a document, its declarations, and the components responsible for them. You can reproduce it, review it, and keep it consistent even when the site has more than one layer capable of setting a canonical.

Hey I'm Uriel Bitton. I write about SEO, AEO, GEO, and helping brands get found in AI answers.

Subscribe for practical ways to grow your brand's visibility in search and AI answers.

Explore HoneyWeRank for SEO and AI visibility.

Sources

Google Search Central: How to specify a canonical URL

Stale Search Results: Show the Slow Response in Your Public SaaS Demo

Uriel Bitton — Wed, 04 Nov 2026 15:56:41 +0000

When you share a SaaS search demo in public, run two searches and make the first response arrive last. The results on screen should still belong to the current query. Keep the query, any filters and the visible result state in the recording so another developer can tell which request owns the screen.

This test catches a problem that a fast happy-path recording can hide. A person types a new search, sees plausible results and opens one. If an older response replaced the newer list, the interface has quietly answered a different question. A public demo can show that failure clearly with sample data and a small, repeatable sequence.

Give the two searches visibly different answers

Imagine a fictional SaaS app for managing equipment inspections. An operator searches for an asset before opening its latest report. Use two sample assets with names that are easy to distinguish, such as North Pump and South Lift. The first query is “pump.” The second is “lift.” Keep the test account and its permissions unchanged between those requests.

Arrange the test environment so the pump response is delayed while the lift response returns quickly. You can use a controlled test fixture or supported development tools for your app. Record how you introduced the delay. The point is to reproduce an order the network can produce without relying on luck or publishing real asset information.

Start the recording with the query field visible. Submit pump, change it to lift and submit again. Let the lift response settle before releasing the delayed pump response. Then leave the screen visible for a moment. A viewer should be able to see whether the input still says lift, whether the result list contains the lift and whether anything changes when the pump request finishes.

Do the same sequence in the opposite direction. Distinct names make a mismatch easy to spot, but a correctly handled pump-to-lift sequence alone says little about a bug tied to one query or one cached result. Keep each run short enough that someone can reproduce it from the description.

Decide which state belongs to the active request

The list is only part of the state. A late response might leave the correct rows in place while clearing the current loading indicator, displaying an old error or replacing the result count. Review those elements together. The screen should give one coherent account of the current search.

In the fictional app, the current request could be identified by the submitted query plus the selected site and inspection status. A request for lift at the north site is a different search from lift across all sites. If you change a filter while a request is running, the earlier response should not silently claim the new filter's result area.

Be explicit about the period before the current response returns. You may clear the old list or leave it visible with a clear loading treatment. If you keep it visible, check whether the operator can tell that those rows came from the previous search. Also decide what happens if they activate an old row while a new search is pending. That decision affects what your demo should show.

The official React useEffect documentation includes an example that ignores a response after its effect has been cleaned up. It explains that responses may arrive in a different order from the requests. The example establishes the problem and one way to guard an update in that setting. Your app may already have a framework or data library responsible for request and cache state, so inspect that existing flow before adding a second mechanism.

Show what happens when the old request fails

A late successful response is a useful first case. Follow it with an older request that fails after the current one succeeds. In the fictional app, let lift results load and then return an error for the delayed pump request. Watch for an error message that replaces the successful lift list or a retry button that runs the wrong query.

Describe the intended behavior in terms of the current task. The operator is looking for the lift. An error from a superseded pump search should not make them believe the lift search failed. If the app records that old failure for diagnostics, keep that separate from what it displays as the active result.

Then test a failure of the current request. In that case the user needs a truthful error state and a retry path that preserves the query and filters they intended. The two failure runs let peers assess whether the interface knows which request it is talking about. A single error toast gives them less information.

Include the empty-query case if clearing the input changes the screen. A delayed response might repopulate results after the operator has deliberately returned to a blank search. Decide what the cleared state means in your product and show whether that state survives the late arrival.

Trace the action someone can take from the result

After the lift results settle and the delayed pump response finishes, open the displayed asset. Check the destination's name and identity. This catches a mismatch between the visible label and the row action. A list that looks right can still route someone using stale state.

Use only sample records and harmless actions. You can open a report or inspect a detail view without starting a real inspection or notifying a customer. Keep the destination visible in the recording long enough to establish that it matches the selected row. If the route includes an identifier, use the sample identifier consistently in your private notes.

The resulting trace can be compact. Note the first query, second query, completion order, final visible query, result identity and opened destination. Add the app version and whether caching affected the run. These details give another developer a way to compare their result with yours.

If cached results appear immediately, say so. Repeat the sequence with the conditions that matter to the bug you are investigating. A warm cache can change the order without changing which query should own the display. Keep the setup honest when you share a repaired version.

Ask founder peers to review the visible contract

A public build update can show the expected sequence and the actual recording. In Buildside's founder community, ask peers what they believe the visible list represents while the second request is pending. If people cannot tell, that is a useful interface question even when the code prevents stale updates correctly.

Developer peers can help assess the reproduction and the ownership of state. People who perform the underlying work can help judge whether retaining old results makes sense. An operator searching several assets quickly may need a different transition from someone making one occasional lookup. Keep those perspectives attached to the feedback.

When you publish a fix, use the same two sample queries and completion order. Show the old failure if it helps explain the change, then show the repaired behavior with the same starting conditions. Describe the branch you tested and any remaining cases. A successful recording supports that sequence, while other timing, navigation and permission changes still deserve their own checks.

Before your next search demo, write down which request owns the results at each moment. Then make the older request finish last. The final screen should let a viewer identify the current search without needing an explanation from the person who built it.

Hey I'm Uriel Bitton. I write about building in public strategies and growing startups.

Subscribe for more stories on growing your audience by building in public.

Join us on Buildside: the social network for founders building in public.