DEV Community: Uriel Bitton

HTML lang and SEO: Check the Language Your Page Declares

Uriel Bitton — Sun, 01 Nov 2026 14:46:59 +0000

Set the HTML lang attribute to describe the page’s actual predominant language. Then verify that the delivered page and its language label agree. This helps users and assistive technology; it should not be presented as a command that makes Google detect a language or target a country.

Google explicitly says it uses algorithms, rather than HTML lang or hreflang, to detect a page’s language. That makes the technical diagnosis more precise: a wrong language label is worth fixing, but an unwanted search-language result needs its own investigation. Do not promise that changing the attribute will resolve both.

Keep three observations separate

Take a fictional documentation page intended for French-speaking readers. Its route contains a French-looking path, most of its explanatory text is French, but a shared layout still declares English on the root HTML element. These are three different observations: route naming, visible language, and programmatic language.

The mismatch is not repaired by pointing at the URL and saying the language is obvious. A person can infer meaning from the page while a user agent receives a different label. Equally, a French label on an untranslated English page would not make that page French.

Before changing anything, record the exact public URL and what the page currently delivers. Keep regional audience requirements separate from language correctness. A page can be written in French for readers in several countries, or use the same language across regional variants with different commercial conditions.

Visible content: what language dominates the actual answer?
Declared language: what does the root HTML element identify?
Audience and variants: who is the page for, and which related versions exist?

Understand what the language label helps readers do

W3C’s Language of Page explanation describes identifying the default human language so user agents and assistive technologies can present content appropriately. Screen readers can use the correct pronunciation rules. This is a user-facing reason to provide an accurate label, independent of a ranking claim.

Apply that purpose to the fictional page. If its main answer is French, a default English label is a defect to investigate in the template or localization pipeline. Correcting it helps the programmatic description match what the reader receives.

A non-empty value alone is not a complete quality check. The label also needs to represent the content. A quick automated check can flag a missing attribute while missing a plausible but incorrect value inherited from another route. Include an editorial review of the visible language when verifying a translated page.

Inspect the document that actually reaches the browser

Open the public route directly, rather than reaching it only through an already localized session. In browser developer tools, inspect the root HTML element and read its lang value. Compare it with the main text, headings, navigation, and any important notices. Save the route and the observation date.

Then follow a normal internal navigation path to the same page. If the site changes content without loading a whole document, check the language label again after navigation. A correct initial document does not establish that the attribute stays correct during every route transition.

In the hypothetical docs site, direct loading might deliver the expected French label while a client-side transition leaves the previous page’s English value behind. That is a proposed failure case to test, not an observed result from a real site. If it occurs, the repair belongs in the route or layout behavior that owns the value.

Also review the state a new visitor receives. Do not let yesterday’s language selection stand in for the default experience. Record any visible preference or account condition that changes what is served. This turns the check into a reproducible observation rather than an unexplained screenshot of one session.

Handle mixed-language content deliberately

A translated article may retain a product name, a quoted phrase, or an original-language example. Those fragments do not necessarily change the predominant language of the document. Start with the main answer and consider what a reader is actually being asked to understand.

W3C’s guidance explains choosing the language used most when a page contains several languages, with the first used as the default when languages are used equally. Its related guidance addresses language changes within parts of a page. Keep document-level and passage-level labeling as separate review tasks.

For a practical handoff, identify the mixed-language passage and ask whether its treatment is intentional. A long untranslated warning is a different problem from a short product name. If a critical limitation remains in another language, adding a label does not substitute for translating the information the intended audience needs.

Use Google’s language guidance within its scope

Google’s localized-pages documentation says hreflang describes relationships among localized variations. It separately states that Google does not use hreflang or the HTML lang attribute to detect the language of a page. Avoid collapsing these jobs into a single “language tag” repair.

In the fictional site, fixing the English root label on the French page addresses a real mismatch. If search still shows an English version for a particular query, that is a separate observation. Inspect the actual result, relevant page content, and variant setup instead of repeatedly changing the root label.

The same caution applies to AI visibility. A correct lang value is not a documented universal requirement for being cited by ChatGPT, Claude, or Gemini. Do not generalize Google’s language-detection statement into a claim about every system either. State the engine, the behavior documented, and the limit of the evidence.

Review representative routes, not one successful screenshot

Build a small review set from the templates that can produce different language states. Include a directly loaded translated article, a page reached from another language, a fallback page, and an important error or access notice. Use the routes your product actually exposes.

For each case, record intended language, observed main-content language, declared root language, and relevant navigation state. Add whether the result was checked before and after client navigation. Keep expected and observed values in separate fields so the chosen implementation cannot quietly redefine the requirement.

Ask the responsible developer or localization owner to explain which component owns the value. A shared shell, server template, and route-level change can otherwise overwrite each other. The acceptance check should include the affected transitions, not just the single page used to discover the defect.

A representative sample still has limits. It does not prove that every route and language combination works. Record untested templates and prioritize ones that carry important buyer answers. The goal is a clear, bounded check that another person can repeat.

Verify the repair against the problem it was meant to solve

After the normal authorized release, reopen the public routes and repeat the recorded transitions. Confirm that the label agrees with the intended main-content language and that the content itself has not fallen back to an unexpected version. Keep evidence of the actual delivered state.

If the change also affects pronunciation or other assistive behavior, use an appropriate accessibility review rather than inferring the whole experience from one attribute. A corrected label is one part of a usable multilingual page.

Track search presentation and AI answers separately if those are part of the project. Save the question or query, surface, date, mode, and linked destination; repeat observations before claiming a stable change. The defensible immediate result is that a defined set of pages now declares the language it actually presents. That is useful technical work even when no discovery gain has yet been demonstrated.

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

robots.txt Wildcards: Test the URLs You Mean to Block

Uriel Bitton — Sun, 01 Nov 2026 04:28:15 +0000

For Google’s robots.txt interpretation, test a rule against actual URL examples before deploying it. A path prefix, a folder boundary, and an end-of-URL marker select different sets. The pattern can be valid while still blocking pages you intended to keep available.

The practical task is to compare two lists: the URLs your crawl policy should cover and the URLs the rule actually matches. This walkthrough uses a fictional documentation site. Its examples illustrate Google’s documented matching behavior; they are not a live crawler experiment or a claim about every AI crawler.

Write the intended URL set first

Imagine a public docs site with a working area at /draft/, a useful published guide at /draft-guide, a standalone page at /draft, and a mixed-case legacy path at /Draft. The team wants Googlebot to avoid the working area while retaining the public guide. Writing “block draft pages” in a ticket leaves too much room for interpretation.

Name representative URLs and expected outcomes before choosing a pattern. Include at least one child in the working folder, one public page with a similar prefix, the folder’s bare path, a query-string variant, and a case variant. Add examples from the site’s actual inventory rather than assuming all routes follow a naming convention.

Separate the business reason from the matcher result. “This contains unfinished material” is a policy decision. “This path starts with the selected prefix” is a mechanical condition. If the two sets do not line up, changing the label on the ticket will not fix the rule.

A prefix does not imply a directory boundary

Google’s robots.txt specification documents case-sensitive path matching and gives prefix examples. A rule starting /draft can match /draft-guide as well as /draft/notes. Adding a trailing slash narrows the boundary: /draft/ covers descendants of that folder but does not match the bare /draft path.

In the fictional inventory, the broad prefix would catch the useful public guide. The folder form better matches the stated policy, but leaves a separate question about the bare path. The team must inspect what that path actually serves. It may be a public overview, a redirect, or another working page.

Do not add an exception just to rescue a poorly understood pattern. First decide whether the folder structure expresses the intended policy. A short rule is only helpful when its selected set is clear. One extra character can change that set more than several lines of explanatory comments.

An end marker changes query-string coverage

The same specification defines * as matching zero or more valid characters and $ as marking the end of a URL. Its extension examples show that a pattern ending in .php$ excludes a URL continuing with a query string. Apply that distinction carefully when adapting an extension pattern to another fictional file type.

For example, compare /*.csv$ with inventory entries /exports/sample.csv and /exports/sample.csv?download=1. The first ends in .csv; the second continues beyond it. A team that writes “all CSV exports” but tests only the first form has not checked its actual policy. Also include an uppercase extension if the site produces one.

These examples are useful precisely because they expose assumptions. Do you want every export route, only a literal suffix, or a particular folder? The answer determines the rule. Do not keep broadening a wildcard until a few positive examples match while ignoring the public URLs it would also capture.

Read the complete applicable rule group

A pattern is not the whole decision. Google chooses the applicable user-agent group and resolves competing rules according to its documented specificity rules. Its specification describes using the longest matching path and choosing the less restrictive rule when equally specific rules conflict. Review the actual applicable group before interpreting a single line.

For the fictional docs site, an old specific crawler group could make a newly edited general group irrelevant to the crawler being checked. Equally, another matching line might explain why a URL remains allowed. Record the chosen group and matching rules beside the example outcome so someone else can follow the conclusion.

Keep this review scoped. The article is about Google’s interpretation, and another service’s crawler may document different behavior or support. A successful check for one named crawler is not evidence that every answer engine can retrieve the page. Identify the crawler and its current documentation whenever you extend the policy review.

Keep the site boundary visible

Google’s specification limits a robots.txt file to the relevant host, protocol, and port. That means reviewing a file on the marketing site does not establish the policy on a separate docs host. Make the complete origin part of the review record, even when the rule examples show only paths.

In the fictional project, the production docs host and a preview host might contain similar folders. A reviewer who checks the preview file can get a convincing result for the wrong destination. Record the exact public robots.txt URL and the complete example URL before evaluating the pattern.

Also distinguish a path rule from a security control. Confidential working content needs appropriate access protection. A crawler instruction is not permission enforcement. Google’s documentation also warns that a disallowed URL can still appear in search without a content snippet. Do not describe a crawl restriction as a guaranteed removal or confidentiality mechanism.

Build a review sheet with positive and negative examples

Use a small table or plain list with four fields: complete URL, intended crawl outcome, matching rule, and reason. Keep the expected outcome separate from the result. Otherwise a reviewer can unconsciously rewrite the expectation to match the pattern already chosen.

For the working folder, add a child page that should be excluded and the similar public guide that should remain available. Include the bare folder name, a nested path, and query variations observed on the site. For an extension rule, add both the clean suffix and a URL that continues beyond it.

Ask another reviewer to inspect the negative examples first. They reveal accidental expansion that an all-positive sample can miss. Mark any untested route family explicitly. A dozen carefully chosen examples will not prove coverage of an unlimited URL space, but they can expose an incorrect boundary before the change reaches production.

Validate the deployed file, then observe separately

After an authorized change through your normal release process, reopen the actual public file. Confirm the origin, contents, applicable group, and intended pattern. A correct local review is not enough if a stale file, deployment rule, or different host serves another version.

Recheck the same URL inventory against the deployed policy. Keep the before and after records. If a relevant native search diagnostic is available to the verified site owner, use it for the specific URL and distinguish the tool’s report from your manual matching analysis. Do not claim a live test was performed merely because you read the file.

Then observe crawler and search behavior with the reporting your team actually has. A newly deployed rule does not by itself prove that a crawler has fetched it or that search presentation has changed. Avoid promising a fixed update time. Those observations belong beside the rule review, with their dates and limits clearly stated.

Connect the repair to the discovery problem

A robots.txt wildcard review is most useful when tied to a specific discovery failure. If an important public answer sits inside an accidentally excluded prefix, correcting that policy can remove a documented obstacle for the named crawler. It cannot guarantee that the page will be indexed, cited, or recommended.

Conversely, an AI answer omitting your brand is not enough to diagnose a wildcard problem. You need the relevant URL, the applicable policy, and evidence that this access path matters to the surface being tested. Keep content quality, product relevance, and retrieval access as separate questions.

Finish with a short handoff: what the rule was meant to cover, which examples caught the mistake, which boundary was chosen, and how the deployed file was checked. That record helps the next release avoid repeating the assumption. The goal is a crawl policy whose meaning is reviewable, with evidence proportionate to the claim you make about it.

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: robots.txt specification and matching examples

Session Timeout UX: Show What Survives Sign-In in Your Public Demo

Uriel Bitton — Sat, 31 Oct 2026 23:12:50 +0000

A useful session timeout UX demo shows the work before expiry, the sign-in transition, and the exact state afterward. Make it clear which values were saved and which were still drafts. Returning to the same screen does not prove that unsaved work survived, and seeing text in a field does not prove it was stored successfully.

For a developer building a SaaS in public, that sequence gives peers a concrete continuity problem to review. It is more informative than a screenshot of a “Session expired” message or an unqualified claim that the app keeps everything safe.

The project-note editor below is fictional. All example values and states are prepared for explanation. This is a review workflow, not a report of testing a real app, and it does not recommend changing a production authentication policy for the sake of a recording.

Define the activity that should continue

Imagine a planning app with a project title and a longer meeting note. The user has saved the project title, then started editing the note without submitting the latest changes. Their authenticated session expires while that note is open.

There are several different things to inspect: the saved title, the unsaved note, the user's location in the task, and their permission to continue. Give each one an explicit expected state in your own review notes.

Do not use “restore the session” as a catch-all phrase. A new authenticated session, a restored page, and recovered draft data are separate results. A product can achieve one and fail another.

Keep the public demonstration scoped to the activity. You do not need to expose authentication tokens, internal account information, or a customer's workspace to show whether a prepared note remains available after sign-in.

Prepare a before-expiry record

Use distinctive, harmless sample values that a viewer can recognise later. The note might contain a short prepared agenda with an unfinished final line. A generic paragraph of filler makes an accidental reset harder to spot.

State whether the displayed note is already saved. If the interface has a save indicator, include it in the recording and check what that indicator actually means in the implementation. Do not call a value server-saved merely because a spinner stopped.

Record the expected outcome before triggering expiry. That prevents a successful-looking return from becoming the standard after the fact. The demonstration should answer a question you deliberately chose to inspect.

Keep a copy of the prepared values in your private review record. After sign-in, compare against that record rather than relying on memory or assuming that similar-looking text is identical.

Trigger expiry under known test conditions

Use a suitable test environment and a supported way to exercise the expired-session path. Describe the relevant conditions without publishing credentials or turning a temporary test configuration into advice for production.

Distinguish a real expiry from a mockup that displays the message. A simulated screen can help review wording, but it cannot establish that the application handles an expired credential, redirects correctly, or preserves a draft.

If you shorten a test session for the demonstration, say that the timing is a test condition. A recording with an edited pause should also say that the waiting period was compressed.

Do not claim that every expiry path behaves identically. Inactivity, an explicitly ended session, and an account change may have different consequences. Choose the path you intend to show and keep other cases in a separate check list.

Show what the person can do at the interruption

When the app asks the person to sign in again, record the available action and the explanation beside it. A viewer should be able to understand whether their work is still present, temporarily unavailable, or known to be lost.

Do not promise draft preservation in the message before the behavior supports it. If the system cannot recover a draft, the explanation needs to reflect that limit while the product team investigates the design.

Avoid replacing the whole flow with a still image of a warning. The transition matters: does the interruption cover the editor, replace it, or take the person to another page? Those choices affect what someone thinks has happened to the note.

Ask a peer to describe their next action from the visible state. Their answer can reveal unclear wording. It cannot verify the authentication or storage behavior behind the interface.

Compare the state after sign-in

Complete sign-in using a prepared test account through the normal supported flow. Return to the project and compare the saved title, unsaved note, and task location with the before-expiry record.

Show the full relevant note, including its unfinished final line. A restored first paragraph can hide lost edits farther down. Check whether the interface distinguishes a recovered draft from the last stored version.

If the note reappears, establish what that result means. It might still be an unsaved draft awaiting submission. The demo should not imply that recovery automatically completed the user's original action.

Then perform the intended save under the current authenticated state and check the supported confirmation. Treat that as a further step. Recovery, permission to save, and successful persistence each deserve their own observation.

Use accessibility guidance with its actual scope

The W3C explanation of re-authentication describes a Level AAA criterion: after an authenticated session expires, the person can continue their activity without losing data when they authenticate again. It explains why losing work can especially affect people who need more time.

That gives the review a useful goal. It does not mean a short clip proves that the whole application conforms to WCAG, or that one particular storage design is required in every system.

Review the interaction with the input methods and assistive technology relevant to your actual implementation. A pointer recording does not establish focus behavior, an accessible explanation, or a usable route back for a keyboard user.

State the checks performed and their limits. A public demo can show a specific continuity path while a separate implementation review addresses the rest of the criterion and the broader product requirements.

Keep recovered data tied to the right person

Preserving a note is not the only requirement. The application must also handle the identity and access under which that note can be viewed or submitted. Do not treat any successful sign-in as permission to attach previous work to the new account.

For the fictional editor, record an unresolved account-change case separately from the same-account demonstration. It may need a design decision about how to explain available drafts without exposing another person's content.

Do not improvise a storage workaround merely to make the public sequence look smooth. Local retention, shared devices, server storage and deletion have different implications that belong in the actual product's design and security review.

The public artifact should report what was observed under the stated conditions. A preserved sample note is useful evidence for one path, not a certificate that draft recovery is safe across every device, identity and failure condition.

Ask founder peers one continuity question

Buildside is the founder-community context for this review. Uriel Bitton builds and runs Buildside, which is this article's publisher relationship. A prepared demo gives peers a specific interaction to assess without asking them to inspect private customer work.

Choose one question: can they tell what survived, can they identify what still needs saving, or does the return location match their understanding of the task? Keep implementation findings separate from opinions about the message.

If you make a revision, repeat the relevant before-and-after sequence. A clearer sentence is a useful improvement, but it does not repair lost state by itself. Show the state comparison again when behavior changes.

Keep the version, conditions, prepared values and unresolved cases in your development notes. Your next build-in-public update can report one checked improvement and the boundary around it. That gives readers useful progress while preserving an honest account of the work still left to verify.

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 re-authentication without losing data

Buildside: about the product and its builder

Delete Confirmation Dialogs: Show the Exit Path in Your Public SaaS Demo

Uriel Bitton — Fri, 30 Oct 2026 14:16:05 +0000

A useful public demo of a delete confirmation dialog should show which item will be affected, what deletion means, and how someone leaves without deleting anything. Record the safe exit as well as the final action. A screenshot of a red button cannot show whether backing out preserves the work or whether the interface tells the truth about recovery.

For a developer building a SaaS in public, this gives founder peers a concrete interaction to review. It also exposes questions that belong in implementation checks rather than a discussion about button color. Use prepared data and a suitable test environment for the demonstration.

The project-deletion flow below is fictional. It is a review method, not a report of testing an actual product. No action in a demo should affect real customer work, and a simulated result should be labelled as simulated.

Define exactly what the delete action affects

Imagine a small planning app with projects and tasks. Its current design allows the owner to delete a project. Before asking anyone to review the dialog, the developer needs to know whether this also removes tasks, attachments, shared access, or references elsewhere in the app.

Write that behavior in ordinary language. If the implementation archives a project and permits restoration, describe that behavior. If it permanently removes the project, do not borrow reassuring language from an archive flow.

The interface and the underlying behavior must agree. A dialog that says “Remove from this view” creates a different expectation from one that says “Delete this project and its tasks.” Changing the label alone cannot resolve an uncertain backend operation.

Keep the review scoped to one action. Deleting a task, leaving a shared project, and deleting a whole workspace can have different consequences. A public demo becomes hard to assess when it switches between those operations without explaining the difference.

Start the recording before the dialog opens

Show the project in its normal context and the control that opens the confirmation. A viewer should be able to tell which project the action concerns before reading the dialog.

In the fictional app, use a prepared project with a neutral name and sample tasks. Say that the data is prepared for the demo. Don't include real project names or customer material merely to make the recording look realistic.

Open the dialog and pause long enough for someone to read it. Avoid editing out the transition if that hides where focus goes or makes it unclear whether the dialog has already performed the action.

Ask a reviewer what they think has happened so far. They may interpret opening the dialog as the deletion itself, especially if the background item disappears early. That is a specific point to investigate rather than a general verdict on whether the design looks modern.

Make the target and consequence visible together

A generic “Are you sure?” prompt asks the person to remember the action and its scope. In the example, the dialog can name the prepared project and explain the actual consequence beside the final button.

Use only information the application can support. If the dialog displays a task count, check that the count refers to the affected tasks under the current conditions. A convincing number that is stale or calculated from another scope can make the prompt less trustworthy.

Don't add a list of alarming consequences simply to make the interaction feel serious. Name the consequences that actually apply. The point is to help someone decide, not to create a dramatic warning around every small action.

A peer review question can be direct: “Which item do you think will be removed, and what else do you expect to happen?” The answer reveals the viewer's interpretation before you explain the intended one.

Record the path that keeps the project intact

First demonstrate backing out. Use the non-destructive control, then show the original project and its tasks still present. If the interface offers more than one way to dismiss the dialog, inspect those paths separately.

The label for leaving should fit the operation. A dialog about cancelling a scheduled job can make “Cancel” ambiguous. In your own flow, check whether a reader can distinguish cancelling the dialog from performing the action described in it.

A visible return to the project is stronger evidence for this one path than simply closing the modal. It still does not prove that every dismissal path is safe. Keyboard input, clicking outside, navigation, or a connection problem may exercise different behavior.

Keep those unresolved paths in the review notes. Public feedback can help identify the questions; implementation checks establish what the actual system does. Do not describe an untested path as safe because the main recording ended well.

Review keyboard and assistive-technology behavior separately

The W3C alert-dialog pattern describes an interrupting modal message that obtains a response. It explains the role, label and description relationships, and warns that marking a dialog modal must match how it actually behaves.

This guidance is useful when reviewing a confirmation, but a video of the screen cannot establish that its semantics work. Inspect the dialog's accessible name and description, focus behavior, available controls, and the return from dismissal in the actual implementation.

Use the appropriate dialog pattern for the interaction rather than adding an alert role for emphasis. A semantic label is not decoration. It communicates behavior to software and people using assistive technology.

Report the checks you performed and the ones you did not. A short public clip may show a keyboard path while leaving screen-reader behavior for a separate check. That is a useful bounded artifact without claiming that the whole application meets an accessibility standard.

Show completion without implying an undo that does not exist

Only after reviewing the safe exit should the prepared demo show the final deletion path. Reopen the dialog for the same prepared project, confirm the action, and show the resulting state.

If the system supports restoration, demonstrate the actual supported restoration route in another bounded sequence. If it does not, say that clearly. Do not put an “Undo” control into a mockup and present it as proof that recovery works.

Check what a person sees if completion is uncertain. A slow response, repeated click, or stale list can leave the interface out of step with the operation. Those questions may need a separate test rather than a longer public recording of the happy path.

The completion message should describe the operation you can verify. A disappearing card alone does not tell you whether related data was removed, access changed, or the backend accepted the action exactly once.

Ask peers one question about the decision

Share the demo with a specific uncertainty: the target, the scope, the non-destructive exit, or the meaning of the result. Asking “Any thoughts?” invites people to review a different problem from the one you need to resolve.

Buildside is the community context here. Uriel Bitton builds and runs Buildside, which is this article's publisher relationship. Wherever you request feedback, give peers enough task context to judge the interaction without assuming they know the implementation.

A peer may understand the dialog perfectly and still lack the customer's workflow. Another may point out a risk you had not considered. Treat each response as a scoped observation or suggestion, then decide which question needs further evidence.

Don't turn agreement about the wording into proof that accidental deletion will never occur. Clear communication and reliable behavior are both part of the interaction, and each needs appropriate checks.

Keep a review record that survives the next redesign

Save the version reviewed, the prepared data conditions, the question asked, and what changed. Attach the relevant recording or screenshots to your own development notes so a later visual redesign does not lose the reasoning.

For the fictional project flow, the record might say that the dialog now names the project and that the recorded safe exit returns to the intact task list. It should separately list any unresolved recovery or keyboard question.

A follow-up build-in-public update can show the specific revision and the behavior verified. Avoid claiming a drop in user mistakes unless you have measured that outcome under a suitable method.

The useful public artifact shows a real choice with an understandable consequence and exit. That gives other founders a precise way to help and gives the developer a concrete interaction to revisit as the product changes.

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: alert and message dialog pattern

Buildside: about the product and its builder

Googlebot's HTML Size Limit: Is the Answer Beyond the Cutoff?

Uriel Bitton — Fri, 30 Oct 2026 13:56:41 +0000

If an important answer sits beyond Googlebot's HTML fetch limit, inspect the size and order of the document response. A page can appear complete in your browser while the part containing the answer falls outside the fetched portion. Start with the returned HTML, rather than the combined weight of every resource.

As checked on October 30, 2026, Google's current explanation gives Googlebot a 2 MB limit per non-PDF URL, including response headers. The fetched portion goes forward for processing; the unfetched remainder does not. Referenced resources are fetched separately. This is specific guidance about Googlebot, not a universal limit for AI crawlers.

Most teams will never encounter this boundary. For a genuinely oversized document, however, the useful diagnosis is where the essential answer appears and what pushed it there.

Is the HTML response actually the large resource?

Consider a fictional public documentation page for a booking system. Its visible answer explains whether a team can move appointments between staff members. The browser displays the answer after loading a large page with navigation, embedded data and a long reference section.

The performance report shows a heavy page. That alone does not identify this problem. The total might include photographs or a separate script bundle rather than an oversized HTML response.

Ask an engineer to capture the document response for the exact public URL. Record the time, response status and relevant headers along with the body. Keep separate resource requests in a different part of the investigation.

Do not substitute a screenshot, the rendered DOM or an exported text file for this capture. Each can help answer another question, but none necessarily represents the response being assessed at the fetch boundary.

Find the answer's position before changing the template

In this fictional page, a large block of inline data precedes the section about staff reassignment. The visible layout places the answer near the top, but the underlying response puts it much later.

That difference matters to the diagnosis. A section's on-screen position does not tell you its position in the document bytes. A floating navigation element can also make a late section feel easy to reach without changing the response order.

Search the captured HTML for a distinctive phrase from the answer. Confirm the surrounding element belongs to the real content rather than an unrelated copy inside a script or navigation entry.

Then ask the engineer to locate that section against the applicable fetch boundary. Keep the method in the ticket. Avoid giving a byte-perfect conclusion based on a character count, a text editor's line number or the compressed transfer size shown in a network panel.

Keep the limit scoped to the right fetch

The same fictional page also references an external diagram and a stylesheet. Their bytes should not simply be added to the HTML body and called the document's size.

This is a useful point to verify with Google's current explanation of separate resource requests. It prevents the team from shrinking an external image while leaving the large inline payload untouched.

Likewise, avoid transferring a remembered limit from another crawler or file type into this ticket. Name the crawler, document type, source date and exact response you examined.

This article's example concerns Google Search discovery. It does not establish how ChatGPT, Claude or another answer surface retrieves the page. If your actual complaint concerns one of those systems, verify its documented behavior separately before applying this diagnosis.

A precise scope makes the work smaller. It stops a real Googlebot issue from turning into an unsupported claim that every AI engine is missing the same paragraph.

Choose a repair that preserves the reader's task

Suppose the capture confirms that an inline reference payload pushes the answer past the relevant boundary. The team now has a specific problem to solve.

One option is to remove data the public page does not need. Another is to move an appropriate shared resource out of the document. A long reference collection might also deserve separate pages with useful navigation.

Treat each option as an engineering decision with a reader consequence. Splitting content only helps if the resulting pages remain understandable and connected. Moving data can create new loading dependencies. Deleting a repeated explanation can remove context the buyer needs.

Write the intended result before choosing the implementation: the public response should contain a complete, accurate answer to the staff-reassignment question without carrying unnecessary inline material ahead of it.

That goal is more useful than “make the file smaller.” It explains what must survive the repair.

Inspect the shortened response as its own document

A smaller file is not enough if the answer loses its conditions. In the fictional booking example, moving only the sentence “appointments can be reassigned” would leave out the eligible roles and the restriction on completed bookings.

Review the answer with its heading, limits and supporting links together. Ask whether someone could understand the task from that section without reconstructing omitted context from a much later paragraph.

Also check that the document remains structurally coherent. A reduction that removes a closing element, breaks navigation or leaves a heading pointing to an absent section creates a new defect.

This review can be done with a bounded sample: the opening, the decisive answer, its conditions and the nearby links. Save the before and after response captures so the reviewer can see the actual change.

Do not treat a successful local preview as confirmation of the deployed response. Recheck the same public URL after the change reaches the site.

Verify delivery, rendering and indexing separately

After the repair, capture the public response again using the same method. Confirm that the required section is present in the intended part of the document and that the unnecessary payload has changed as expected.

Next, inspect the rendered page for a fresh visitor. The text should remain readable, links should work and the task should still make sense. This is a user-facing check, separate from the response-size finding.

An available native search inspection report can provide another observation about Google's processing. Record what it actually shows and when the inspection occurred. Do not turn an inspection request into a promise that the page will be indexed or rank for the buyer's query.

The repair's immediate evidence is that the public response changed and the complete answer remains usable. Search inclusion and later AI citations are further outcomes to observe, not facts supplied by the deployment.

Write an issue that another engineer can reproduce

A good ticket for this example names the public URL and the missing buyer question. It includes the captured response, the content location and the source used for the current limit.

Add the suspected cause in conditional language until it is confirmed. “The reassignment section appears after a large inline payload” is a useful observation. “Google ignores our site because it is heavy” reaches far beyond the evidence.

The acceptance criteria should name the full answer, its conditions and the verification method. Include a visual check so the repair does not quietly damage the documentation experience.

Assign the response inspection to someone who can explain the byte accounting. A marketer can identify the important answer and review its meaning without pretending to have measured the fetch themselves.

This division makes the evidence easier to trust and the work easier to review.

Stop when the evidence points elsewhere

If the HTML response is comfortably below the limit, close this particular hypothesis. Do not keep cutting useful content because a ranking or citation is disappointing.

The answer could be absent from the response for a different reason, or it could be present without being selected for a particular result. A size check cannot settle those questions.

Keep the negative finding in the audit: the examined response was not near the documented boundary under the recorded method. That prevents the same speculative diagnosis from returning every week.

For the fictional oversized page, success means the team can show a complete answer in the repaired response and a working page. For a normal-sized page, success means ruling out an irrelevant fix and returning attention to the evidence that actually bears on discovery.

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: Googlebot, file sizes and the 2 MB limit

Cookie-Dependent Content and SEO: Test the Page Without Yesterday's State

Uriel Bitton — Thu, 29 Oct 2026 14:24:20 +0000

To diagnose cookie-dependent content for SEO, inspect a public page as a fresh visitor and compare it with the returning visit your team normally sees. Check the initial response and rendered content separately. If the important answer appears only after remembered state is restored, the familiar browser view may be hiding a discovery problem.

Google documents a specific reason to make this check: its Web Rendering Service does not retain state across page loads, and storage and cookies are cleared across loads. That is documented Google behavior, not a claim about every AI engine. The workflow below investigates the page without bypassing consent, authentication or access controls.

Choose one public answer to trace

Use a concrete content target. Imagine a fictional scheduling product whose public integrations page should explain whether its calendar connection supports two-way updates. Returning visitors see the explanation. A fresh browser shows a short introduction and an empty space where the integration details should be.

The target is that public explanation, not every visual element on the page. Record its expected wording, the URL, the relevant preference state and how a person reaches it. This makes it possible to distinguish a missing buyer answer from a decorative component that merely loads later.

Keep the scope public. A customer's private calendar, account settings and paid application workspace are not material you should expose for SEO. If the answer belongs behind authentication, investigate the public documentation that describes the capability rather than trying to make the private workspace crawlable.

Separate the response from the rendered page

The initial HTML response and the browser's rendered document answer different questions. The response shows what the server sent for the request. The rendered document shows what exists after the browser has executed the page's permitted scripts and processed the resulting changes.

In the fictional example, the response might contain the integration heading but no capability explanation. The returning browser might later populate that explanation from an application component. That observation narrows the investigation; it does not prove a search engine failed to render it.

Use the browser's normal developer inspection tools to examine both views. Note whether the text is absent, present but hidden, or replaced after a preference is loaded. Avoid diagnosing the whole site from a screenshot. A screenshot establishes what was visible in that state, while the response and document help explain how the page reached it.

Compare fresh and returning visits deliberately

Open the public page in a clean browsing session using the site's normal access flow. Record what happens before any optional preference is chosen, then record the result of an appropriate normal choice. Separately inspect the returning session that originally looked correct.

Do not silently change the experiment halfway through. If language, region, consent or sign-in state differs, write that down. A fresh visitor in one locale and a returning visitor in another are not a controlled comparison of cookies alone.

The useful question is whether a prior visit is required for the public answer to exist. If the answer appears after an ordinary action, document that action. If it needs a preference stored during an earlier page load, identify that dependency. At this stage, describe the behavior you can reproduce rather than naming a cause you have not established.

Use Google's rendering evidence for the Google question

Google's JavaScript troubleshooting documentation describes its stateless rendering behavior. It also points to URL Inspection and the Rich Results Test for examining rendered output and related rendering problems. Use the available owner tools and permissions for the site you are auditing.

Compare the relevant text in that rendered evidence with the fresh and returning browser observations. Save the test date and tested URL. A difference deserves investigation; it does not by itself tell you whether cookies, blocked resources, timing or another condition caused it.

Keep this evidence tied to Google Search. A Google rendering test is not a measurement of what ChatGPT, Claude or another answer surface retrieved. It can reveal a public-page problem worth fixing, but engine-specific claims need engine-specific evidence. This boundary prevents a useful technical diagnosis from turning into an unsupported universal AI crawler rule.

Trace the dependency before choosing the repair

Ask the responsible developer where the public text comes from and what conditions allow it to render. In the fictional integration page, perhaps the application waits for a remembered display preference before mounting a component that contains both optional features and essential documentation.

If that dependency is confirmed, the design question becomes smaller: can the public explanation be delivered through the normal public page without requiring yesterday's state? The solution might involve separating essential documentation from an optional interactive component. The appropriate implementation depends on the actual system; this article does not prescribe a framework-specific patch.

Do not solve the problem by serving secret extra claims only to bots. Do not remove required consent protections, expose private data or make a paid feature public to create a successful test. The goal is consistent access to information the business already intends to publish.

Repair the user journey as well as the content dependency

A page can contain the right text and still leave a first-time visitor unable to use it. Check the visible route to the explanation. Does the heading describe the integration question? Does the page state the current support conditions? Can a person reach the relevant documentation without remembering a previous selection?

For the fictional calendar connection, a useful public answer might identify which direction of updates is supported and link to current setup limitations. Those product facts must be verified before publication. Adding a generic paragraph about integration benefits would not repair the missing capability answer.

Keep preference-specific variations understandable. If the site offers localized instructions, explain how a fresh visitor selects the applicable version. Avoid treating every variation as a bug. The issue is an unintended dependency that makes a public answer unavailable or misleading, not the mere existence of a preference.

Retest the same states after the change

Repeat the initial response check, the clean visit and the returning visit against the same content target. Also repeat the relevant Google inspection when available. Capture the text that matters, the URL, date, browser conditions and any actions required to reveal it.

A useful acceptance statement is specific: the public integration explanation is present for a fresh visitor under the intended conditions, and the returning experience still works. This is stronger than saying “SEO fixed,” because it names the behavior actually verified.

Google's technical requirements also make clear that meeting requirements does not guarantee indexing. A successful rendering repair is therefore not proof of an indexing gain, a ranking gain or an AI citation. Track those outcomes separately if they matter to the project.

Leave a diagnosis the next person can repeat

Write a short investigation note with the public question, expected text, tested states, observed differences, confirmed dependency and completed repair. Include what remains unknown. A small record with evidence is more useful than a ticket that says the page looked different in incognito mode.

If the problem cannot be reproduced, retain the original conditions rather than forcing a conclusion. A browser extension, an old session or another environmental difference may need further checking. Report an unresolved discrepancy as unresolved.

For search and AI visibility work, the practical payoff is a more dependable public source. Buyers and search systems still have to discover, interpret and choose that source. Testing without remembered state addresses one concrete failure mode: a team mistaking its familiar returning-user view for the page that a first-time visitor can actually read.

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

Loading State UX: Share the Wait in Your Public SaaS Demo

Uriel Bitton — Thu, 29 Oct 2026 14:09:21 +0000

To get useful feedback on loading state UX, show the wait in your public SaaS demo. Show what starts the request, what the interface says while work is pending, what the person can safely do next, and how completion appears. Ask reviewers to explain that sequence before asking whether the spinner looks good.

A polished recording can accidentally skip the part that needs review. The founder clicks a button, cuts the wait, and shows a finished report. Viewers see the result but have no way to judge whether the real interface would leave them wondering if the request worked.

The workflow below uses a fictional report-generation tool. It is a proposed review exercise for developers building in public, not a benchmark or a report of product testing. The aim is to make the pending experience inspectable without presenting simulated behavior as production performance.

Choose one request and name its states

Suppose a customer selects a date range and requests a report. Before recording anything, write down the states that actually exist in the implementation. A request might be accepted, wait in a queue, begin processing, and finish with a downloadable file.

Those distinctions should come from the product's behavior. If the system only knows that work is pending, don't add a “processing” label that suggests knowledge it does not have. If the frontend cannot tell whether the request was accepted, that uncertainty deserves attention before decorative animation.

For this hypothetical tool, assume the server supplies accepted, queued, running, and complete states. The developer can now ask whether the interface communicates those states accurately. That is a narrower and more useful question than whether the whole application feels fast.

Also identify the boundary with failure. This exercise concerns pending work. A failed request needs a separate response and recovery path. Don't leave an endless spinner in place simply because failure handling is outside today's recording.

Show what the first click actually means

Start the demo before the request. Include the selected date range and the button that begins report generation. The viewer needs enough context to know which job the pending message belongs to.

After the click, show an acknowledgment tied to that request. In the example, the interface could say that the report request was accepted and is waiting to start. Whether this exact wording is appropriate depends on what the backend can confirm.

Ask a reviewer what they think happened at that moment. Did the click save a request? Did it start downloading a file? Would they click again? Their answer can reveal a mismatch between the system's state and the meaning the interface communicates.

This is also a good place to inspect repeated actions. If the button becomes unavailable, make its state understandable. If another request is allowed, explain whether it creates separate work. Don't rely on a recording cut to hide a duplicate action that a real person could attempt.

Make the wait honest and reproducible

For a controlled demo, a developer may use a test environment or a simulated delay. Label it clearly in the public update and on the recording when possible. “Controlled demo with a simulated wait” is different from evidence of normal production latency.

Keep the chosen delay consistent between the versions you want peers to compare. The purpose is to inspect the messages and actions during a wait, not to prove a speed improvement from two recordings made under unknown conditions.

A real recording has limits too. One successful request does not establish typical response time or reliability. If you are sharing an actual run, describe it as that run and keep performance claims separate from the review question.

Avoid fake progress percentages. A rising number may look reassuring, but it communicates measurement. If the system cannot estimate completion, show a truthful state instead. A queue position, estimated time, or progress bar also needs a sound basis before it belongs in the demo.

Review what remains possible while work is pending

A waiting screen needs a clear answer to “What can I do now?” In the fictional tool, perhaps the report continues if the customer visits another page, but stopping the browser session changes how they can find the result. The interface should reflect the actual behavior.

Write the expected action beside each state. Can the person change the requested dates? Leave the page? Cancel the job? Submit another report? If an action is unsupported, don't suggest it in explanatory text just to make the screen feel more complete.

Record one safe action during the wait. For example, navigate to the report list and show that the pending job remains identifiable there. This gives peers an artifact they can inspect, rather than asking them to imagine what navigation might do.

If the current implementation requires staying on the page, be candid about that limitation. Then ask whether the message explains it clearly. A review can expose an awkward constraint without pretending the constraint has already been removed.

Check status messages beyond their visual appearance

The W3C explanation of status messages covers updates such as waiting, progress, results, and errors that appear without a change of context. It explains how relevant messages can be made available to assistive technology without moving focus.

That guidance makes a useful distinction for this demo: seeing a status update in a video does not establish that someone using a screen reader receives it appropriately. A visual recording cannot verify announcements, timing, or focus behavior by itself.

Keep an accessibility check alongside the public artifact. Inspect whether the pending and completion messages are exposed as intended, whether focus remains sensible, and whether updates become unnecessarily repetitive. Report only the checks you actually performed.

This is a focused review, not a claim that the whole product meets an accessibility standard. If the public demo omits keyboard or assistive-technology behavior, state that limit and leave the related question open for a suitable check.

Ask peers to describe the sequence

Post the demo with one concrete request: “After the report is accepted, what do you think is happening, and what would you do while waiting?” Add a second question only if it addresses a different uncertainty, such as finding the finished file after leaving the page.

Buildside is the founder-community context for this article. Its About page identifies Uriel Bitton as the builder and operator; that is the publisher relationship. Wherever the demo is shared, the request should give readers enough context to review the work without assuming they know the code.

Don't begin by teaching reviewers the intended answer. If the post explains every state before they watch, their response may reflect the explanation rather than the interface. Put essential demo limitations up front, then ask what the screen itself communicates.

A developer peer can inspect implementation choices. A prospective customer may be better placed to explain whether the waiting options fit their task. Keep those perspectives distinct in your notes.

Turn a response into a specific next check

Imagine a reviewer says they would press the button again because the first click seemed to do nothing. Record the point in the demo they mean. Check whether acknowledgment appeared, whether it named the request, and whether the button's state made sense.

That observation does not automatically prove you need a different spinner. The cause could be missing acknowledgment, unclear wording, a stale screen, or a misunderstanding of the task. Change the part for which you have a reason, then show the same sequence again.

If another reviewer expects an email on completion, inspect whether the interface implied one. Don't add a promise of email delivery unless the product supports it. You can instead clarify where the report will appear and ask whether that fits the customer's workflow.

Publish the revised wait with its limits

The follow-up update should show the original question, the changed state, and the behavior you verified. A concise explanation might say that accepted requests now remain visible in the report list while work is pending.

Keep the claim at that level. Clearer pending text is not evidence that customers will retain better or that reports finish faster. A controlled demo can help people understand and critique the interaction; it cannot answer every question about production use.

Save the demo conditions and reviewed version with your development notes. The next time report generation changes, you will have a concrete sequence to revisit: request, acknowledgment, waiting options, and completion. That makes public feedback part of maintaining the workflow, rather than a reaction to a spinner in isolation.

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: about the product and its builder

Content-Type and SEO: Check the Response Before Trusting the File Name

Uriel Bitton — Wed, 28 Oct 2026 14:37:32 +0000

When an HTML page has the wrong Content-Type header, inspect the actual returned response before changing the file name or rewriting the page. Match the response's declared media type to its body, then check which delivery layer supplied the mismatch. A familiar URL extension does not establish what a crawler received.

For SEO, this is a delivery diagnosis. The goal is to make the public document accurately described and usable, not to force a particular search result. Correcting a media type does not guarantee indexing, rankings, or AI citations.

The example below is hypothetical. It follows an HTML documentation page labeled as plain text and turns that observation into a focused investigation. It contains no live site measurements or implementation code.

Read the response header and body together

MDN's Content-Type reference explains that the header identifies the media type of returned data. It also distinguishes media type from content encoding. A compression label and a document-format label describe different things.

For an intended HTML document, inspect whether the response declares text/html and whether the returned body is actually the expected HTML. The body could instead be a plain-text error, an authentication response, a downloaded asset, or another representation. Do not classify it from the address alone.

Record the final URL, status, relevant response headers, and enough non-sensitive body content to identify the document. Keep those pieces from the same observation. A header from one response and a screenshot from another can produce a diagnosis that no single request supports.

This pairing is the starting point for every later decision in the investigation.

Do not treat the extension as the parser decision

Google's indexable-file-types documentation says it uses Content-Type to determine file type, while sometimes using an extension or another parser when the header is missing or incorrect. That documented flexibility is not a reason to rely on a mislabeled response.

It also means the diagnosis should avoid an exaggerated conclusion. A page labeled text/plain is not automatically proof that Google cannot index any of its text. The question is what was delivered, how it was described, and which processing or presentation problem is actually observed.

Keep Google-specific documentation within its scope. Do not assume every search crawler, browser, or answer-system retrieval tool makes the same fallback decision. Repair the incorrect response description because it is wrong, then verify the relevant consumer separately.

Renaming a route to end in .html would not, by itself, prove that the response header or delivery behavior changed.

Capture the document request rather than a visual impression

Use the browser's network inspection or an established HTTP inspection tool to capture the request for the document. Inspect the final response after redirects and identify the request method. The page's appearance alone does not show all of that information.

For the intended page body, inspect a GET response. If the first diagnostic used HEAD, make the method explicit and compare it with GET before assuming it represents the body-bearing request. This is a verification step, not a claim that the methods always differ.

Retain the relevant context, including whether the request was authenticated and whether an intermediary supplied a cached response. Do not publish private headers, session values, or full diagnostic files merely to illustrate the article.

The useful output is a small evidence record another engineer can understand: this URL, this request context, this declared type, and this returned document.

Follow a fictional mislabeled documentation page

Imagine a fictional SaaS documentation route, /guides/export. An observed response in this invented example has a successful status, a text/plain media type, and a body containing the intended HTML guide. Assume no claim has yet been established about indexing or crawler behavior.

An initial ticket says the page is missing because the URL has no .html suffix. That explanation goes beyond the observation. The evidence currently establishes a mismatch between the intended HTML representation and its declared media type.

Rewrite the ticket around that mismatch. Attach the non-sensitive response details and state which environment produced them. Keep the missing-search-result question as a separate symptom requiring its own evidence.

This makes the next investigation narrower. The team can trace the declaration through delivery without first rebuilding the route structure or revising an otherwise useful guide.

Locate the layer that changes the declaration

Identify the components that can set or replace response headers in the actual system. They might include the application, static-file configuration, a proxy, or an edge delivery rule. Treat that list as a map of possibilities until observations establish the responsible component.

Where authorized access permits it, compare equivalent observations at the available boundaries. If the origin declares HTML and the public response declares plain text, investigate the path between them. If both declare plain text, the evidence points earlier, but it still does not identify a particular configuration line.

Change one suspected cause at a time through the project's normal process. Keep the original observation so the repair can be compared with the same document and request context.

Avoid broad rules that label every response HTML. A site may legitimately serve PDFs, images, JSON, or text files. The repair should describe each intended resource accurately.

Check successful pages and error paths separately

A normal document route and an error response need not have identical bodies or formats. Inspect the cases the system actually serves rather than validating one successful screenshot and declaring the whole template fixed.

For the fictional guide, useful follow-up cases include the public document, a missing guide, a redirected address, and an authentication boundary if one exists. These are proposed checks, not a report that those cases were run here.

For each case, keep status, media type, and body aligned. A correct HTML label cannot make a successful status appropriate for a genuinely missing page. Likewise, a legitimate JSON response should not be relabeled HTML just because the main documentation pages use it.

This separation keeps a narrow header correction from hiding a different delivery problem. It also helps the reviewer see which routes the evidence covers and which remain unchecked.

Verify public delivery after the repair

Repeat the observation through the public path a reader or crawler can reach. Compare the final URL, status, declared media type, and returned body with the original record. Confirm that the expected guide still appears and that its important content is present.

Check the relevant delivery variants when the system has them, such as a refreshed edge copy and an ordinary repeat request. Do not infer broad consistency from an origin-only check if public responses take another route.

Use the relevant search engine's inspection tools where available to investigate its view. Distinguish a live fetch from an earlier indexed copy and retain the observation date. A successful repair verification is evidence about delivery at that time, not an instant indexing outcome.

If the original symptom remains, continue with its actual evidence. Do not keep changing Content-Type after the mismatch is resolved simply because rankings have not moved.

Close the ticket with a bounded explanation

State the original mismatch, the responsible layer that was established, the change made, and the public cases rechecked. Name any routes or consumers that remain outside the verification.

Keep downstream outcomes separate. Correct response labeling, successful rendering, index inclusion, organic visits, linked AI citations, and product recommendations are different observations. A delivery fix can support discovery without proving every later result.

When monitoring AI visibility, retain the exact prompt, engine, date, mode, answer, and cited URL. An answer change after the repair may have other explanations. Avoid turning sequence in time into proof that the header alone caused it.

Choose one intended HTML page and inspect its actual response. If the media type and body disagree, repair that specific mismatch and verify the public path before changing the content that readers came to find.

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

MDN: Content-Type header

Google: File types indexable by Google

SaaS Time Zone Testing: Make Your Public Demo Explain the Clock

Uriel Bitton — Wed, 28 Oct 2026 13:59:26 +0000

A useful public demo for a scheduling feature should explain which clock owns the promise. Show the intended local time, the relevant time zone, the saved event, and what another viewer sees. Then ask peers to test a specific boundary rather than judging a calendar screenshot that happens to look correct on your machine.

SaaS time zone testing has two jobs here. The product must preserve the intended scheduling meaning, and the public update must give readers enough evidence to assess that meaning. A successful demo in one browser does not establish that reminders, recurring events, and other viewers all agree.

Name the scheduling promise before testing it

Start with the user's task. “Send a reminder three hours from now” describes elapsed time. “Send a reminder at nine each weekday in the customer's city” describes a recurring local schedule. “Show this appointment in the viewer's time zone” describes presentation. Treat these as separate requirements.

Write the promise beside the demo. Include whether the schedule is a one-time event or a recurrence, whose time zone applies, and what happens if that setting changes. The developer and the peer reviewer should be working from the same interpretation before either starts checking a result.

This is especially important when building in public. A reply that says “the time is wrong” may mean the displayed hour is wrong, the saved instant is wrong, or the user expected a different zone. A clear promise turns that reply into a diagnosable observation instead of a debate about what the feature should have meant.

Keep an instant separate from a local clock reading

An instant identifies a point in time. A local clock reading needs additional context to identify when something happens. The date and time zone matter, and an offset alone is not a complete rule for future local schedules.

MDN's ZonedDateTime documentation explains the distinction between exact time and local time, including gaps and repeated local times around daylight-saving changes. It also describes cases where time-zone rules change. Those are reasons to test the product's interpretation, not just its formatting.

You do not need to adopt a particular API to communicate that distinction. MDN currently marks Temporal.ZonedDateTime as having limited browser availability. Check the compatibility and behavior of the actual library or runtime your product uses before recommending implementation details to readers.

Build a small public evidence card

For each demonstrated case, record the entered value, the chosen time zone, the scheduling promise, and the expected result. Add the app version or test environment and the observed result. Use fictional accounts and events so the artifact can be shared without exposing customers' calendars.

A useful card might describe a fictional consultation booked for a particular local date and hour in America/Toronto. The promise is one appointment at that local time, displayed appropriately to another viewer. The card should show the saved appointment after reopening, not only the value before pressing Save.

Do not put real email addresses, invitation tokens, customer names, or private calendar links in the public card. You can show a sanitized delivery record or a test inbox if it supports the question, but explain what was replaced and what evidence remains genuine. Synthetic data should be labelled as synthetic throughout the demonstration.

Follow one fictional reminder through the product

Imagine a small maintenance app that lets an operator schedule a reminder for a site manager. The operator chooses a site, enters a date and hour, and selects the site's time zone. A second person views the reminder from another location. This is a worked example, not a claim about a tested product.

First, decide whether the reminder belongs to the site or to the operator. If the intended rule is “nine in the site's local time,” changing the operator's display preference should not quietly redefine the site's schedule. Show that rule in the creation screen or supporting text so testers know what to expect.

Next, save the reminder and leave the page. Reopen the exact record and inspect the date, zone, and local hour. A correct input screen can hide a conversion or persistence error that appears only after retrieval. Keep the reopened result next to the original expectation in the evidence card.

Then view the same record as the second person. Ask them to explain when the reminder will occur and which zone the label refers to. Their answer tests communication as well as conversion. An unlabeled time that the founder understands may still be ambiguous to someone arriving from a public demo.

Finally, inspect the test reminder's actual execution or delivery record if the feature sends anything. Creation, display, and execution are distinct checkpoints. If you have only verified the first two, say that delivery remains untested. Avoid using a successful save toast as proof that the eventual notification happened correctly.

Choose boundary cases from the promise

A one-time appointment and a repeating local reminder need different cases. For the appointment, include viewers whose local dates differ at that instant. For recurrence, include occurrences on both sides of a relevant clock change. Check the expected result against the intended product rule before comparing it with the output.

Include a local time that does not exist and one that occurs twice where the selected zone has such transitions. The interface should make the product's policy understandable. It might reject an ambiguous entry or ask the user to choose. Whatever the policy is, show and test it rather than leaving the behavior accidental.

Also check what happens when a user changes the event's time zone after entering the hour. Does the product preserve the instant or the local reading? Both behaviors can serve different tasks. The requirement must say which one applies. A visible before-and-after example is more useful than claiming the app “supports every time zone.”

Keep date-only fields separate in the review. A maintenance due date may mean a calendar day rather than an appointment instant. Converting it through a time zone without considering that meaning can produce a different displayed day. Ask the product owner which task the field represents before treating every date as a timestamp.

Ask peers to test the missing perspective

Share the evidence card with one bounded request: “Can you tell which time zone owns this reminder after reopening it?” Or ask a developer familiar with scheduling to propose the next boundary case. A general request to “try the calendar” gives less guidance about what would help.

Buildside's About page describes public product progress and useful founder connections. The author, Uriel Bitton, builds and runs Buildside. A founder community can supply a different perspective on this workflow; its replies do not replace a product test suite or establish correctness across all supported environments.

Separate a usability observation from a reproducible defect. If a peer cannot identify the zone, improve the label and review the task again. If an event moves after reopening, capture the sanitized inputs and environment needed to reproduce that behavior. Do not combine those findings into a vague report that time zones are broken.

Publish the result at the scope you checked

A useful follow-up names the cases, the outcome of each, and the remaining gaps. “The saved appointment kept its intended instant in these two viewer settings” is narrower and more informative than “Time zones solved.” Include a failing case if it explains the next decision, without exposing private operational details.

Keep the public artifact small enough to maintain. Update its status when the test version changes, and link a follow-up rather than letting an old demo imply current behavior. Before asking anyone else to review the feature, make sure your own evidence card states what the clock is supposed to mean.

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: ZonedDateTime, time zones and ambiguous local times

About Buildside and its founder

SaaS Export Testing: Show What Leaves the Product

Uriel Bitton — Tue, 27 Oct 2026 13:51:09 +0000

A public SaaS export demo should finish with someone using the exported information outside your app. Show the selected records, explain what the file includes, and ask a reader to complete a small task from it. A successful download is one checkpoint; it doesn't show that the exported information keeps its meaning.

This is a useful build-in-public topic because the result can be inspected. Instead of announcing that export support has shipped, share a safe sample and a specific question about what a person can understand from it. Keep the example separate from customer data and avoid presenting one file as proof that every export works.

Define the outside task before recording the demo

Choose a task that explains why the file exists. In a fictional maintenance-log SaaS, a workshop manager wants to review completed repairs for a selected month without opening the original app. That task requires more than a list of record identifiers.

Write a short acceptance note: the reader should identify each completed repair, understand its completion date, and connect it to the correct sample machine. The example doesn't need billing, contact information or internal staff comments. Name those exclusions before the walkthrough so the missing fields don't look accidental.

This is a demonstration plan, not a claim about a real product. The task, records and observations in this article are hypothetical. Apply the method to your own product only after checking what its current exporter actually does.

Build a sample that can reveal a mismatch

Use invented records with a small known set of expected results. Give two machines clearly different names. Include a completed repair, an unfinished repair, and a repair outside the selected month. Add a note with punctuation that someone would reasonably enter.

The point is not to create a spectacular edge-case collection. It is to make the selection boundary visible. If the filter says completed repairs in April, you should be able to explain why each included row belongs and why the other rows don't.

Keep a private expected-record list before you export. Otherwise, you may look at the file and accept whatever it contains because you no longer remember the starting state. Record identifiers can help compare the app and the file, but they don't replace readable descriptions.

State what one row represents

An export needs a clear unit. Does one row represent a repair, a machine, or an individual maintenance action? A reader cannot safely count repairs when one repair can occupy several rows and the file doesn't explain that relationship.

For the fictional demo, choose one row per repair. Include a stable repair identifier, a machine identifier, a readable machine name, a repair description, status and completion date. Explain whether an empty completion date means unfinished, unknown or unavailable. Don't leave the reader to infer that meaning from a blank cell.

A short accompanying field note can do this work. Keep the note close to the file and version it with the sample. If you later rename a field, an older public file should still be understandable from the explanation that accompanied it.

Check the file format without confusing it with correctness

For CSV, RFC 4180 documents common formatting conventions, including consistent field counts and quoting fields containing commas, line breaks or double quotes. It is an informational RFC, not a guarantee that every spreadsheet interprets every value the same way.

Use those conventions as one part of the inspection. Check a description containing a comma, a quoted phrase and a line break. Confirm that the description stays in the intended field when the file is read. A visually neat table can still hide a shifted column if you only inspect the easiest row.

Then return to meaning. Correct CSV quoting won't tell you whether the right repair was exported, whether a displayed date has the intended meaning, or whether a status code is understandable. Formatting and product correctness need separate notes.

Show the selection before showing the download

Record the product state that determines the export: selected dates, status filter, scope and any relevant options. Use your safe sample account. Explain whether the export follows the visible selection or uses another rule.

In the hypothetical walkthrough, the founder selects April and completed repairs, then exports. The expected-record list says which repair should appear. The recording follows that record into the file and checks that the unfinished repair is absent.

Don't crop out the selection just to make the download button larger. Readers need the starting context to evaluate the result. If a screen contains material you cannot safely share, recreate the task in a deliberately prepared sample environment rather than trying to hide a live customer workspace during recording.

Ask a peer to read the file without narrating the answer

Give a reviewer the safe file, its field note and the outside task. Ask them to identify which machine had the completed repair and when it was completed. Let them explain where they found the answer.

If you guide them to every column, you are checking whether they can follow your directions. You are learning less about whether the file stands on its own. Save explanations until after their first attempt, then note which missing context required help.

Buildside describes its community as a place for SaaS founders to share work and seek help with concrete problems. It is built and run by Uriel Bitton, this article's publisher. An export sample gives a relevant peer something specific to inspect. It doesn't make that peer representative of your customers or turn a review into a security assessment.

Keep a mismatch note that leads to an action

Write down expected behavior, observed behavior and the smallest useful follow-up. For example: the reader should identify the machine; the file contains only an internal code; add a readable machine name beside the identifier and repeat the task.

Another hypothetical mismatch might involve the date field. The reviewer interprets it as the date the repair was reported, while the exporter intended completion. Renaming a vague date column and documenting its meaning is a more direct response than adding a general help paragraph about exports.

If the sample passes, say exactly what passed. The reader completed this task with this file and these instructions. Don't extend that statement to other time zones, large exports, permissions, attachments, restore behavior or every destination tool. Those require their own checks.

Publish the learning and preserve the sample's limits

A useful public update can show the initial selection, the safe file, one mismatch and the revised field explanation. State the sample size plainly and identify any manual steps. If you haven't tested a second reader or a different file, leave that boundary visible.

The next public artifact should answer the same outside task after the change. Keep the original question and the result together so readers can see why the revision matters. A screenshot of a download success message doesn't explain that reasoning.

You should also decide who will keep the shared sample current. When the real exporter changes, an outdated example can send readers toward behavior that no longer exists. Add a dated note or replace the sample with a clearly identified revision. The purpose of building in public is useful inspection of the work, and that depends on readers knowing which work they are seeing.

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

IETF RFC 4180: common CSV format conventions

About Buildside and its founder

Sitemap Lastmod: Publish the Content Change, Not the Build Time

Uriel Bitton — Tue, 27 Oct 2026 13:36:51 +0000

A sitemap's lastmod value should describe the page's last significant update, not the time your build job ran. To audit it, compare the published page and sitemap across a rebuild with no content change, a meaningful update, and a rollback. The date should follow the relevant content event under a documented rule.

This matters when a site rebuilds many unchanged pages together. If every deployment stamps every URL with the current time, the sitemap stops distinguishing which public answers actually changed. Replacing those timestamps with guesses is not a reliable repair either.

The workflow here is an artifact-level test design for a fictional documentation site. It contains no production implementation or claim of measured ranking improvement.

Confirm what Google says the field means

Google's current sitemap documentation says it uses lastmod when the value is consistently and verifiably accurate. The date should reflect the last significant page update. Its examples include main content, structured data, and links; changing a copyright date is not the same kind of update.

Treat that as a meaning to preserve, rather than a tactic for making every page look new. A sitemap submission is a hint and does not guarantee that Google downloads it or crawls the listed URLs. An accurate timestamp also does not guarantee indexing, a particular rank, or an AI citation.

The useful engineering question is therefore specific: can the published value be traced to the event the team intends it to describe? Answer that before debating whether to include seconds or how frequently to rebuild the XML file.

Trace the date back to its source

Find the field or process that supplies lastmod. It may be an editorial update field, a database timestamp, a file-change record, or a build-time default. Each source can represent a different event, even when the output has the same valid date format.

An internal save time may change when an editor corrects a draft that has not been published. A deployment time may change when the application dependency graph changes. Neither necessarily tells you when the public answer changed significantly.

Record the source and its limitations. Do not assume a field called updated_at has the right meaning without checking what writes to it. For a representative URL, compare the stored event, the rendered page, and the final sitemap entry. That small trace often reveals whether the problem begins in content storage or in export.

Define significant changes for each template

Write a short rule for the page types you maintain. A product limit changing from one verified allowance to another changes the buyer's answer. A new supported platform can change a compatibility page. A correction to an important source link can also matter.

By contrast, a global footer rebuild may leave that answer untouched. Do not reduce significance to a raw byte comparison: the generated HTML can change because asset identifiers, navigation, or unrelated components changed. Identical byte counts do not establish identical meaning either.

Use examples reviewed by the people responsible for the content. The rule should help the publishing pipeline distinguish a meaningful public change from routine regeneration. It does not need to predict how a search engine will assess every edit, and it should not encourage editors to make trivial changes just to refresh a date.

Test a rebuild without a content change

Choose a fictional URL representing a maintained API guide. Save the published body and its lastmod entry as the starting artifacts. Run the project's established preview or staging build without changing the guide's significant content.

Compare the resulting public answer and sitemap entry. If the answer remains the same but the timestamp advances to build time, the pipeline is likely describing regeneration rather than the intended content event. Inspect the timestamp source before changing the test expectation.

Keep the comparison focused. Record the URL, content revision, build identifier, relevant rendered passage, and emitted date. A screenshot alone may not expose the sitemap value; an XML file alone cannot establish that the page's meaning stayed unchanged.

This is a proposed controlled test. Do not report a successful result unless someone actually runs it against the service and retains the evidence.

Test a substantive update and a delayed publication

Next, change a fact that materially affects the guide's answer in the test environment. For example, update a supported operation and its explanation after the product owner confirms the behavior. Record when that significant revision becomes public, not merely when the draft was saved.

Inspect both artifacts after publication. The rendered page should contain the intended revision, and the sitemap date should follow the team's documented public-update rule. A correct timestamp beside stale page content is still a failed release.

Include a delay between editing and publishing in the test. This catches systems that stamp the draft save time or a scheduled job's creation time without considering the actual published content. Keep time zones explicit when a timestamp is used, so a formatting conversion is not mistaken for a different event.

The goal is a traceable relationship, not matching the clock at the moment someone checks the page.

Decide how a rollback is represented

A rollback can restore older text at a new public event. Decide how the content system records that significant change, and retain the earlier revision history. Do not quietly pretend the restored page has never changed since its first publication.

Test the rollback using the same URL and artifacts. Confirm which body is now served and which date the export emits. If cached HTML still contains the newer version, the sitemap's date cannot resolve that delivery mismatch. Fix and verify the page delivery separately.

Be explicit about this rule in the content model. Otherwise one part of the system may reuse an old revision timestamp while another records the rollback event. That inconsistency is an engineering issue to investigate, not a reason to invent a more recent date everywhere.

Retain enough history for another maintainer to explain the emitted value without reconstructing the whole deployment from memory.

Correct unknown dates without manufacturing freshness

Some older pages have no trustworthy modification history. Mark that limitation during the audit rather than assigning today's date to the entire archive. Check what the current sitemap format and publishing system permit, and choose a supported representation that does not assert an event you cannot establish.

For new work, store a meaningful content-change event so the uncertainty does not keep growing. A clearly defined source is easier to maintain than repeatedly inferring change from build artifacts after the fact.

Google's earlier XML sitemap and feed guidance also ties modification times to changes intended to be visible in search. Use the current documentation for present behavior, while recognizing the durable distinction between a changed answer and a regenerated file.

Verify the exported artifact and monitor the later outcome

After a repair, inspect the actual sitemap delivered to crawlers, rather than only the generator's local output. Compare several representative templates and repeat the no-change rebuild. The meaningful-update test should still advance the appropriate date under the documented rule.

Record the result and the remaining limitations. Successful export establishes that the artifact reflects the intended event; it does not establish that a search engine has fetched, indexed, or shown the new version. Monitor those later observations using the relevant search tools.

For AI visibility, separately inspect the answer and cited URL under repeated, recorded prompts. Do not attribute a citation change to one sitemap field without evidence. Start with one maintained public answer and prove that its date remains honest through a rebuild, a revision, and a rollback.

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: Build and submit a sitemap

Google: Meaningful changes in sitemaps and feeds (2014)

Vary Headers and SEO: Test Which HTML the Cache Reuses

Uriel Bitton — Mon, 26 Oct 2026 13:36:07 +0000

When a public page changes according to request headers, test which HTML your cache reuses before treating a search mismatch as a content problem. Compare the origin response with repeated edge requests, then reverse the order in which the variants arrive. An order-dependent result is a useful clue that the cache is mixing responses.

The Vary header describes request fields that influenced a response. It is not an instruction to create a special page for a crawler, and adding it without checking the delivery configuration is not a complete fix. The important question is whether each request receives the intended public content through the whole delivery path.

The method below uses a fictional documentation site. It is a diagnostic design, not a report of a test performed on a real service.

Define the content difference before testing the header

Choose one URL with a concrete discrepancy. For example, a product's desktop help page contains a compatibility warning while the mobile response does not. Write down the exact sentence, link, or directive that differs. “The pages look different” is too broad to diagnose.

Separate layout differences from missing information. Responsive styling can rearrange the same HTML without creating a separate server response. Dynamic serving can return different HTML at the same URL. Google's mobile-first indexing guide distinguishes those configurations and describes the use of Vary: User-Agent for dynamic serving.

Record which request property is meant to select the response. If nobody can name it, investigate the application before editing cache rules. A cookie, language header, device classification, or deployment version can each point toward a different cause.

Understand what Vary actually tells a cache

The protocol rule is about selecting stored responses. Under RFC 9111, section 4.1, a cache must account for the request fields named by Vary before reusing a response. Matching the URL alone is insufficient when the stored response declares additional selection fields.

MDN's Vary reference explains the header's role in separating cached responses and calls for consistent values across responses for the same URL, including validation responses. Read the actual header, rather than inferring it from a framework setting.

That still leaves implementation work. A CDN may have its own cache eligibility rules, custom cache keys, or configuration requirements. Verify the current documentation for the service in your delivery path. Do not assume that a header copied from an example changes every cache layer in the way you intend.

Create a small request matrix

For the fictional site, define request A as an anonymous desktop request and request B as an anonymous mobile request. Keep the URL, language preference, authentication state, and other relevant fields unchanged. Change only the property under investigation.

For each response, retain the status, relevant request headers, response headers, and the body section containing the compatibility warning. Record time and the observed cache-status information when the service exposes it. A body digest can help compare responses, but keep the meaningful text difference alongside it.

Do not use a personalized session as your public baseline. A signed-in page may legitimately contain different material. Keep secrets, cookies, and private content out of shared test notes. The purpose is to compare public representations under controlled conditions.

This small matrix is easier to interpret than a large crawl that changes geography, language, cookies, and device type at once.

Reverse which request warms the cache

Assume the intended origin behavior is that both variants contain the warning, despite different layout markup. First check that assumption through an authorized staging or origin diagnostic route. Do not expose a protected origin to make testing easier.

Using the project's established cache-testing controls, begin with a known empty or isolated test cache. Send A, repeat A, then send B. Record the warning and the available cache signal each time. Repeat the experiment from a fresh test state, this time sending B before A.

Suppose the first sequence gives both requests the desktop body, while the reversed sequence gives both the mobile body. That fictional pattern suggests the first stored response is being reused across requests that should remain distinguishable. It does not by itself identify the exact layer or configuration error.

If the response changes even without a shared cache, the origin's selection logic deserves attention first. The order reversal helps distinguish these possibilities instead of assuming every mismatch is a Vary problem.

Trace the first layer where the body becomes wrong

Compare the same meaningful body section at the application, the edge, and the final browser view where those observations are available. Retain the request conditions at every point. A correct origin response and incorrect edge response narrow the investigation; an incorrect origin response calls for a different repair.

Check whether the cache key includes the intended selection property or a documented normalized version of it. Inspect rules that remove headers, rewrite the URL, bypass storage, or serve an older object. Make one change at a time so the next result remains interpretable.

Avoid broad fixes such as varying every page by every cookie. Those changes can create many stored combinations and make the system harder to reason about. The right selection rule follows the actual public content difference and the service's supported configuration.

When the content does not need to vary, serving equivalent primary information is often a simpler design than maintaining two independent content versions.

Check the SEO consequence separately

A cache defect becomes a discovery problem when the wrong response omits or changes information a search system needs. Inspect the main answer, important links, title, canonical, and indexing directives. A successful status alone does not establish that the intended page arrived.

Google states that it uses the mobile version of content for indexing and ranking. Its mobile-first guidance also calls for equivalent primary content across desktop and mobile versions. That makes a missing mobile warning or important answer worth fixing even when a desktop screenshot looks correct.

Keep the claim engine-specific. Google's documented rendering and indexing behavior does not establish how every AI search crawler handles the same site. For another engine, consult its current documentation and examine actual delivery evidence.

Changing a browser's user-agent string is a diagnostic input, not proof that the request came from a real crawler. Use verified request records when identifying actual crawler traffic.

Verify the repair with the same sequences

After the approved change, repeat both warm-up orders using the same controlled inputs. Both A-then-B and B-then-A should now produce the intended body for each request. Record the configuration version and any narrowly scoped purge performed through the project's normal process.

Recheck the response after a cache hit, not only after a fresh origin fetch. A fix that works only on the first request can leave the original problem unresolved. Also check an ordinary anonymous visit to ensure the repair did not create a new user-facing discrepancy.

Retain a compact evidence bundle: request definition, response headers, meaningful body comparison, and test order. That is enough for another developer to assess the conclusion without publishing sensitive request logs.

If the result remains inconsistent, mark it unresolved. Do not convert a few correct responses into a claim that indexing or AI visibility has recovered.

Keep delivery tests tied to useful public answers

For a SaaS team, prioritize templates whose public answers affect evaluation: supported platforms, API capability, product limits, and implementation requirements. A delivery test is most useful when it protects information buyers actually rely on.

After the delivery behavior is stable, monitor the affected URL through the relevant search tools. Separate successful fetching from indexing, search appearance, linked AI citations, and recommendations. Those are later observations, each with its own limits.

The durable improvement is a repeatable check that proves the intended public answer survives a warm cache. Begin with one URL, one meaningful content difference, and two request orders. Expand the test only when the first result gives you a reason to do so.

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 9111: Selecting cached responses using Vary

MDN Vary header reference

Google mobile-first indexing guidance