Export URL Discovery Evidence From LLMIC
Give each discovery finding its source, evidence and acceptance condition.
A developer receives a file called missing-pages.csv. It contains twenty URLs but no source pages, input dates or explanation of what “missing” means. The developer cannot tell whether to repair navigation, update a sitemap or investigate a failed request.
Export URL discovery evidence from LLMIC as a set of traceable observations. Keep the recorded crawl, the relevant row export and a working sheet that explains each URL’s source. The purpose is to make the proposed repair reproducible without turning an uncertain classification into a fact.
Decide Who Will Use the Export
A navigation developer needs the source page and the destination that should be linked. A publishing editor needs the expected sitemap membership or CMS record. A reviewer needs the evidence dates, settings and unresolved cases. These recipients may share a workbook, but they need different columns to act on it.
Write the handoff’s purpose at the top of the working sheet. “Review sitemap-only tutorial URLs from this comparison” is more useful than “fix orphan pages” when internal-link coverage has not been established. The title should describe what the evidence supports.
Agree the expected output as well. The recipient might return corrected href values, a revised sitemap inventory or an explanation of intentional exclusions. A file without a requested decision tends to become another report that nobody closes.
Preserve the Crawl and the Input Inventories
Use More, then Crawl File (.llmic), then Save Crawl File to preserve the recorded investigation. Give the file a name containing the site or section, date and purpose. Keep the original input list or sitemap snapshot beside it where appropriate.
For a row-based handoff, export the relevant Pages results and inspect the saved file. Active filters can change the population being exported. Record the filter and confirm known included and excluded URLs before labeling the output as complete.
Keep the sitemap inventory separately from the linked-crawl rows. If you combine them for analysis, retain membership columns and source filenames. A merged list without provenance cannot show whether a URL came from navigation, a sitemap or a manually supplied expectation.
Build a Relationship Sheet Instead of a Bare URL List
Create the following columns in a working copy or a separate spreadsheet. Fill them from recorded evidence and direct inspection; leave unavailable facts explicitly unresolved. These are suggested handoff fields, not a claim that LLMIC automatically exports all of them in one file.
| Field | Example of the information required | How it supports a repair |
|---|---|---|
| Destination URL | Exact public address being investigated | Identifies the page without a guessed normalization |
| Expected discovery source | Hub link, sitemap or approved input list | Names the mechanism being tested |
| Source URL or file | The referring page or inventory filename | Tells the owner where to inspect |
| Observed relationship | Missing entry, old href or unverified route | Separates observation from proposed action |
| Direct-check outcome | Intended content, redirect, failure or unchecked | Shows whether destination availability was tested |
| Evidence date | Collection time and timezone | Helps explain later differences |
| Acceptance condition | The route or entry that must work afterward | Makes closure testable |
Add owner and status columns only after the evidence columns are populated. A priority label should not stand in for a missing diagnosis. If you use a confidence label, explain what it means and which observation would resolve the uncertainty.
Keep Original Values Alongside Interpretations
Preserve the exported URL exactly as recorded. If the working sheet groups variants, add a separate comparison key and document the rule. Keep redirected addresses and known final destinations in different fields so a stale source reference remains visible.
Do not enter a guessed HTTP status for a URL absent from a linked result. “No matching observation” is different from a failed request. Do not replace “source not inspected” with “no internal links,” because those statements require different evidence.
Maintain an untouched copy of the original export. Put analyst comments, proposed destinations and owners in the working version. This gives the team a way to distinguish what was observed during the crawl from decisions made later in a meeting.
Verify That the Package Is Usable
Open the CSV or spreadsheet you intend to share. Check that URLs remain complete, text has not shifted across columns and the data-row count excludes the header. Inspect a known case from each classification rather than reviewing only the first row.
Confirm that the saved crawl and source files correspond to the dates in the worksheet. A current sitemap paired with an older crawl can be a valid comparison, but the timing difference must be explicit. Do not rename newer evidence to make it look contemporaneous with the original run.
Review the package for private paths, tokens and unrelated information. Share the minimum evidence the recipient needs through the team’s approved location. If redaction is necessary, label the shared copy and preserve the distinction between removed information and genuinely missing evidence.
Worked Example: Assign Three Different Discovery Problems
This is an illustrative handoff. A documentation review identifies three cases. One guide is absent from the current sitemap. Another guide’s hub links to an old address. A third appears missing from a linked run whose relevant source page was never inspected.
The first row names the sitemap and asks the publishing owner to check its inclusion rule. The second row names the hub, the old href and the approved target, giving the navigation owner an exact edit to review. The third row remains an investigation task and requests a focused route check; it is not assigned as a confirmed orphan-page repair.
Each row includes a different acceptance condition. The sitemap case needs the intended entry in a fresh inventory. The link case needs the corrected relationship in a repeat of the linked route. The unresolved case needs evidence before a repair can be selected.
This package is more useful than three destinations with a shared “missing” label. It prevents one team from implementing unnecessary changes while the real source of a discrepancy remains unknown.
Carry the Evidence Into Verification
Keep the original package after implementation. Create a new dated result for the retest and connect it to the original row. Record whether the acceptance condition passed, failed or remains unestablished, with a link to the supporting evidence.
Avoid closing a row because the destination now loads when pasted into a browser. That may be relevant to availability, but it does not confirm a sitemap entry or a repaired internal route. Match the fresh check to the discovery mechanism named in the ticket.
Use Verify Changes to URL Discovery in LLMIC for the retest design. If the original classification is still uncertain, return to Review URL Discovery Results in LLMIC before presenting the handoff as a confirmed repair list.
Questions About Discovery Handoffs
Which files should I send with the working sheet?
Include the relevant export and enough input context to reproduce the comparison. A saved crawl helps a colleague using LLMIC inspect the recorded evidence. Avoid sending unrelated data merely because it is available.
Does the Pages export include every discovery source?
Do not assume it does. Inspect the actual headers and populate missing provenance in a separate analyst sheet from verified sources. Label unavailable relationships rather than inventing them.
Should every missing destination have a source URL?
Include a source when one is known or expected. If you have not identified it, say so. An unknown source is a diagnostic gap, not proof that the destination has no internal links.
Can I remove URL parameters to simplify the file?
Keep the original value. Add a separate comparison key only when the normalization rule is appropriate and documented. Some parameters change the resource being investigated.
What should the owner return after making a change?
Ask for the changed source, the intended new relationship and the deployment time. Then collect fresh evidence against the acceptance condition rather than treating the implementation note as proof of success.
How do I label an incomplete linked crawl?
State that it is partial and identify the relevant limit or interruption when known. Keep classifications scoped to that evidence set so recipients do not read missing rows as confirmed site-wide absences.
Is a screenshot enough for a link repair ticket?
It can help locate the interface element, but include the source URL and actual or expected destination as text. The image alone may not reveal the href that needs to change.
Sources, Statistics and Measurement Notes
The crawl-file menu was verified in the installed LLMIC interface on 5 October 2026. Pages export behavior was checked against the application’s CSV implementation. Validate the saved output in your installed release before sharing it.
The three-case handoff is illustrative. The relationship sheet, ownership fields and acceptance labels are recommended working practices, not additional automated product features or measured customer outcomes.