Index design / Supplied records

Search indexdesign.

Build search from your own source records. Yondexy is a small digital studio in Austin, Texas. Our website indexing service defines which fields belong in a result and how each record gets there.

Pricing basis: source records and fields, with source condition documented. No published rate or automatic cleanup modifier. A service inquiry establishes the scope before pricing.

Send a service inquiry

Source fields aligned with their corresponding index fields — Source → IndexIllustrative field mapping, not a deployed client index.

01 / Defined structure

Index design starts with a stable unit.

A spreadsheet row is not automatically a search record. Decide what the record represents before counting it.

An index design is a set of instructions for turning a stated source into retrievable records. It names the source identifier, assigns field types and describes what happens when a record changes. It suits a project with information to search but no settled agreement about how that information should be represented.

A company entry can contain several locations. A document can contain several sections. Either may be indexed as one unit or split into related units, but those choices produce different counts and different search behaviour. We scope the unit explicitly rather than treat a file total as an implementation brief.

Service item: Index design for a supplied source set, not a bulk external search-engine submission.
Working material: Source field definitions and an authorized sample, with the format and known inconsistencies described.
Structure to define: Record identity, field mapping, exclusions and the rules for subsequent changes.
Unit of scope: Source records and fields. State separately whether relationships or document sections produce additional indexed units.
Price basis: The defined record count and field scope, with source condition recorded for review. No fixed rate is offered on this page.

A structure you can inspect

The worksheet below shows the decisions an index brief needs. It is a working outline, not a claim about a finished product. You can judge the proposed approach by whether each source value has a destination and each exception has a stated outcome.

02 / Schema worksheet

Give each field one declared job.

Structured data indexing depends on meaning, not just matching column names. A number used as an identifier should not become a measurement. A blank date should not quietly become the current date. Keep the original value available for inspection where the agreed source handling allows it, and define the normalized value separately.

Use this worksheet to separate the source fact from the index decision. The field names are suggested technical labels. They are not records from a customer, nor do they imply that a live index is available here.

Index schema worksheet

Design reference / No live data

record_id / Identity

Choose a stable source key. State whether it is unique within one source or across the whole index. Do not derive identity from a title that can change.

source_ref / Provenance

Keep the source reference distinct from the public result link. A source reference can be internal and must not become a public URL by default.

display_label / Presentation

Declare the field used for a readable result heading and the approved fallback when it is absent. Do not manufacture a company name or document title.

search_text / Retrieval

Name the fields that contribute searchable text. Exclude private notes and fields supplied only to explain an import problem.

record_type / Classification

Define accepted values and how an unknown value is handled. Unrecognized categories should remain visible to review, not be silently reassigned.

source_updated / Freshness

Record what the timestamp measures. A time observed during intake is not evidence that the source itself was updated at that moment.

visibility / Inclusion

Set an explicit inclusion rule. A field being present in the supplied source is not permission to make it searchable or public.

record_state / Change

Distinguish an active record from a withdrawn one. Describe whether withdrawal removes the result or produces an agreed unavailable state.

Mapping rules to settle before source intake
Decision	What the worksheet records	Failure to avoid
Type	Text, number, date or a defined set of values; repeated values identified separately.	Dropping leading zeros from a text identifier because its characters look numeric.
Required value	The minimum fields for a usable indexed record and the route for incomplete records.	Publishing an empty heading because the import completed without a technical error.
Normalization	The exact changes allowed to spacing, case or source formatting.	Replacing meaningful differences with one cleaned value and losing the original distinction.
Search role	Whether a field contributes to matching, filtering, sorting or display.	Making an internal field searchable when it was intended only for source tracing.
Missing value	Keep empty, exclude, or send for review according to the field's purpose.	Treating zero, an empty string and a missing field as the same statement.

A wide worksheet scrolls within its own frame. The same decisions can be sent as ordinary text in the inquiry; no special file format is required to start.

03 / Intake to handoff

Resolve exceptions before the full source set.

A large import can repeat a small mistake across every record. The useful sequence is to examine an authorized sample, agree the conversion rules and then define how the rest of the source set will be handled. Implementation work and its timing depend on the accepted scope; submitting this page does not book a delivery slot.

Describe the source boundary
Start with the source format, approximate record count and intended use. Identify which part you control and which part comes from an external provider. Access rights need to be settled before a full transfer, not inferred from possession of a file.
Compare fields against intended results
Use a representative sample that includes incomplete and changed records, not only the cleanest rows. Identify what must be searchable and what belongs solely in the source trace. Field mapping follows that distinction.
Agree exception and update rules
Define duplicate handling and exclusions before setting the final indexed-unit scope. State what should happen on a missing source key, an invalid value or a source withdrawal. Unresolved questions remain decisions to make, not hidden defaults.
Confirm the implementation boundary
The proposed scope separates index design from ingestion work and from the search interface. Review the deliverables and pricing before proceeding. A usable handoff explains the schema and the source rules; it does not rely on someone remembering an import conversation.

Need result filters or query behaviour as well? Those are defined in the website search setup scope. The index supplies fields; the search interface decides how a visitor can use them.

04 / Duplicate and exclusion review

A similar record is not always a duplicate.

Compare identity before content. Two entries can share a label and still represent different things.

Repeated names are a poor merge rule. A branch can share a company name with its parent. A newer document may reuse an older title. Conversely, two rows with different formatting may refer to the same source key. The schema must explain which evidence is strong enough to merge and which evidence only raises a review question.

Two source records compared during an illustrative duplicate review — Compare / Retain contextIllustrative duplicate review. No customer records are shown.

Exclusions worksheet

Decision before import

Duplicate candidate: name the matching key and preserve the source references. If a merge is accepted, define which value wins when fields conflict.

Incomplete record: specify the missing requirement. A record excluded for a missing title needs a different remedy from one excluded because it lacks publication permission.

Restricted content: identify the excluded field or record class. Private notes do not belong in a public index just because the export includes them.

Withdrawn source: state how removal is signalled and how the index should respond. Absence from a partial export is not enough evidence of withdrawal.

Unresolved conflict: keep it in review until the owner makes a decision. Do not turn uncertain data into a confident result through formatting alone.

Count the exceptions separately.

A source total and a publishable index total answer different questions. The first describes incoming material. The second reflects the agreed inclusion rules. Recording exclusions separately makes the difference explainable without implying that a smaller index is a failed import.

For pricing discussions, distinguish unique source records from repeated export rows. Also identify fields that need a rule rather than a direct copy. Source condition is part of the scope discussion, not a hidden percentage added to an online estimate.

An index needs a stated scope before it needs more entries.
Yondexy / Working principle

05 / Updates and ownership

Define what a changed source means.

A website indexing service needs more than a first import. Record which source owns each field and how a changed value reaches the index. A corrected label and a withdrawn record should not follow the same path. Nor should an incomplete transfer erase records that are still valid.

Full source replacement

A complete source snapshot can be compared with the previous accepted snapshot. Before treating missing records as removals, establish that the new source is complete. A truncated file must not become a mass withdrawal instruction.

Incremental changes

A change feed needs stable identifiers and explicit operations. Define how repeated events are handled and how a missing prior record is resolved. An update time alone may not distinguish an edit from a deletion.

Update decisions for the scoped index
Source event	Rule to agree
Field corrected	Identify the authoritative source value and whether derived fields need to be rebuilt.
Identifier changed	Decide whether it is the same record with a new key or a genuinely new record; preserve the relationship where required.
Source unavailable	Define the acceptable result state and how stale records are labelled. Do not silently claim a successful refresh.
Record withdrawn	Distinguish removal from search from any separately agreed retention of a source trace.
Schema revised	Record the new mapping and whether existing records need reprocessing before the revised fields can be used.

Place relationships require their own identifiers and freshness notes. See the place data service for that model. Company reference fields belong in the company catalogue record scope rather than being treated as unrestricted text.

Keep retrieval separate from publication.

An index can support search without exposing every stored field. The agreed output should state which fields are public, which support filters and which are used only to maintain the record. That separation matters when a source later gains a new column.

Send a service inquiry

Fit / Limits

Check the scope before committing.

This is for a defined source-to-index project. It is not a service for buying search rankings or submitting unrelated websites in bulk.

Does this put my website in Google or Bing?

No. This service concerns a defined index for your own search project. Google and Bing decide how their external search systems crawl and present pages. Yondexy does not promise external inclusion, ranking or traffic.

Can we start with inconsistent source records?

Yes, the inquiry can start there. Describe the source condition and known gaps. A sample review establishes which normalization rules can be specified and which missing values require a decision from the source owner. You do not need to conceal the difficult rows to send a brief.

Will every source row become an indexed unit?

Not necessarily. A row might be a duplicate, a relationship or an excluded record. The scope defines a source unit and the rule that turns it into an indexed record before counts are used for pricing. State whether your count comes before or after deduplication.

Can an existing index be changed without rebuilding everything?

That depends on the field change and the current system. A display label may be changed without changing stored values, while a type or identity change can require reprocessing the source. Describe the current structure in the inquiry. Correction boundaries are explained in the service corrections and guarantee limits.

Indexed-unit scope request

Put the source boundary in the brief.

Tell us what one source record represents and how many fields need mapping. An approximate count is useful if it is labelled as approximate. Describe the source condition instead of sending a private dataset through this form.

Inquiry, not an order

The form opens a scope conversation. It does not accept payment or produce a binding quote. Pricing depends on the agreed source records and fields; no standard rate is implied by a count.

After submission, the recorded inquiry number identifies your request. Questions about access or sample handling can be settled before any source transfer. A reply time is not promised here.

Index design inquiry

Your name and agreement are required. Add either an email address or a phone number so we can reply; neither contact field is required on its own.

Reply details

Your name

Email (optional)

Phone (optional)

Project address (optional)

Only add an address if it is relevant to the project.

Source and indexed units

Service

Record count and field scope (optional)

Describe one indexed unit, the approximate source count, fields to map and known exclusions. Say whether updates replace the full source or arrive as changes.

What needs to change? (optional)

Describe duplicates, missing fields or the current index problem. Do not include passwords, access tokens or private source records.

I agree to Yondexy using these details to handle my inquiry, as described in the Privacy statement, and acknowledge the Terms.

A scope request only. No purchase or payment.